Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #256379 > unrolled thread

Buster => Bullseye: packages kept back

Back to article view | Back to linux.debian.user

Contents

  Buster => Bullseye: packages kept back Jesper Dybdal <jd-debian-user@dybdal.dk> - 2023-03-26 11:20 +0200
    Re: Buster => Bullseye: packages kept back Jeffrey Walton <noloader@gmail.com> - 2023-03-26 11:30 +0200
    Re: Buster => Bullseye: packages kept back davidson <davidson@freevolt.org> - 2023-03-26 13:20 +0200
      Re: Buster => Bullseye: packages kept back Jesper Dybdal <jd-debian-user@dybdal.dk> - 2023-03-26 15:00 +0200
        Re: Buster => Bullseye: packages kept back davidson <davidson@freevolt.org> - 2023-03-27 11:10 +0200
          Re: Buster => Bullseye: packages kept back Jesper Dybdal <jd-debian-user@dybdal.dk> - 2023-03-27 11:30 +0200
            Re: Buster => Bullseye: packages kept back David Wright <deblis@lionunicorn.co.uk> - 2023-03-27 16:50 +0200
            Re: Buster => Bullseye: packages kept back davidson <davidson@freevolt.org> - 2023-03-28 11:00 +0200
              Re: Buster => Bullseye: packages kept back Jesper Dybdal <jd-debian-user@dybdal.dk> - 2023-03-28 12:30 +0200
          Re: Buster => Bullseye: packages kept back Jesper Dybdal <jd-debian-user@dybdal.dk> - 2023-03-27 16:50 +0200
    Re: Buster => Bullseye: packages kept back Cindy Sue Causey <butterflybytes@gmail.com> - 2023-03-26 17:40 +0200
      Re: Buster => Bullseye: packages kept back Jesper Dybdal <jd-debian-user@dybdal.dk> - 2023-03-26 19:30 +0200
    Re: Buster => Bullseye: packages kept back David Wright <deblis@lionunicorn.co.uk> - 2023-03-26 20:20 +0200
      Re: Buster => Bullseye: packages kept back Jesper Dybdal <jd-debian-user@dybdal.dk> - 2023-03-27 00:30 +0200
    Re: Buster => Bullseye: packages kept back Jeffrey Walton <noloader@gmail.com> - 2023-03-26 23:20 +0200
      Re: Buster => Bullseye: packages kept back Jesper Dybdal <jd-debian-user@dybdal.dk> - 2023-03-27 00:30 +0200
        Re: Buster => Bullseye: packages kept back Vincent Lefevre <vincent@vinc17.net> - 2023-03-27 13:30 +0200
          Re: Buster => Bullseye: packages kept back Greg Wooledge <greg@wooledge.org> - 2023-03-27 13:50 +0200
            Re: Buster => Bullseye: packages kept back Vincent Lefevre <vincent@vinc17.net> - 2023-03-27 14:20 +0200
              Re: Buster => Bullseye: packages kept back Greg Wooledge <greg@wooledge.org> - 2023-03-27 14:30 +0200
            Re: Buster => Bullseye: packages kept back Dan Ritter <dsr@randomstring.org> - 2023-03-27 15:10 +0200
              Re: Buster => Bullseye: packages kept back Nicolas George <george@nsup.org> - 2023-03-27 15:20 +0200
                Re: Buster => Bullseye: packages kept back gene heskett <gheskett@shentel.net> - 2023-03-27 16:10 +0200
                  Re: Buster => Bullseye: packages kept back <tomas@tuxteam.de> - 2023-03-27 17:40 +0200
                    Re: Buster => Bullseye: packages kept back gene heskett <gheskett@shentel.net> - 2023-03-27 20:10 +0200
                      Re: Buster => Bullseye: packages kept back <tomas@tuxteam.de> - 2023-03-28 07:10 +0200
                        Re: Buster => Bullseye: packages kept back gene heskett <gheskett@shentel.net> - 2023-03-28 17:10 +0200
                  alternative views of PNG (was Re: Buster => Bullseye: packages kept  back) davidson <davidson@freevolt.org> - 2023-03-28 13:00 +0200
                    Re: alternative views of PNG (was Re: Buster => Bullseye: packages  keptback) gene heskett <gheskett@shentel.net> - 2023-03-28 17:40 +0200
                    Re: alternative views of PNG (was Re: Buster => Bullseye: packages  keptback) gene heskett <gheskett@shentel.net> - 2023-03-28 18:50 +0200
                      Re: alternative views of PNG (was Re: Buster => Bullseye: packages  keptback) <tomas@tuxteam.de> - 2023-03-28 20:00 +0200
                      Re: alternative views of PNG (was Re: Buster => Bullseye: packages  keptback) <tomas@tuxteam.de> - 2023-03-28 20:00 +0200
                      Re: alternative views of PNG (was Re: Buster => Bullseye: packages  keptback) davidson <davidson@freevolt.org> - 2023-03-29 09:30 +0200
                Re: Buster => Bullseye: packages kept back Vincent Lefevre <vincent@vinc17.net> - 2023-04-03 13:50 +0200
              Re: Buster => Bullseye: packages kept back Greg Wooledge <greg@wooledge.org> - 2023-03-27 16:10 +0200
                Re: Buster => Bullseye: packages kept back davidson <davidson@freevolt.org> - 2023-03-28 08:30 +0200
                  apt colored output (was Re: Buster => Bullseye: packages kept  back) davidson <davidson@freevolt.org> - 2023-04-03 08:00 +0200
        Re: Buster => Bullseye: packages kept back Anssi Saari <as@sci.fi> - 2023-03-28 11:30 +0200

Page 1 of 2  [1] 2  Next page →

#256379 — Buster => Bullseye: packages kept back

Yesterday, I upgraded Buster => Bullseye.

This morning, I got a mail from unattended-upgrades, which said:

> Packages with upgradable origin but kept back:
>   Debian stable:
>    guile-2.2-libs w3m

and
> Package guile-2.2-libs is kept back because a related package is kept back or due to local apt_preferences(5).
> Package w3m is kept back because a related package is kept back or due to local apt_preferences(5).
What does this mean?  I have what I believe to be a clean install, I 
have never used apt_preferences, and until now, I had never heard of 
guile or w3m.  And I don't quite understand why I have them installed at 
all.  My sources.list contains only bullseye and bullseye-backports.

What do I do?

apt list says:
> guile-2.2-libs/stable 2.2.7+1-6 amd64 [upgradable from: 2.2.4+1-2+deb10u1]
> guile-2.2-libs/now 2.2.4+1-2+deb10u1 amd64 [installed,upgradable to: 
> 2.2.7+1-6]
>
> w3m/stable 0.5.3+git20210102-6 amd64 [upgradable from: 0.5.3-37]
> w3m/now 0.5.3-37 amd64 [installed,upgradable to: 0.5.3+git20210102-6]
>
Thanks,
Jesper

-- 
Jesper Dybdal
https://www.dybdal.dk

[toc] | [next] | [standalone]

#256380

On Sun, Mar 26, 2023 at 5:16 AM Jesper Dybdal <jd-debian-user@dybdal.dk> wrote:
>
> Yesterday, I upgraded Buster => Bullseye.
>
> This morning, I got a mail from unattended-upgrades, which said:
>
> > Packages with upgradable origin but kept back:
> >   Debian stable:
> >    guile-2.2-libs w3m
>
> and
> > Package guile-2.2-libs is kept back because a related package is kept back or due to local apt_preferences(5).
> > Package w3m is kept back because a related package is kept back or due to local apt_preferences(5).
> What does this mean?  I have what I believe to be a clean install, I
> have never used apt_preferences, and until now, I had never heard of
> guile or w3m.  And I don't quite understand why I have them installed at
> all.  My sources.list contains only bullseye and bullseye-backports.
>
> What do I do?
>
> apt list says:
> > guile-2.2-libs/stable 2.2.7+1-6 amd64 [upgradable from: 2.2.4+1-2+deb10u1]
> > guile-2.2-libs/now 2.2.4+1-2+deb10u1 amd64 [installed,upgradable to:
> > 2.2.7+1-6]
> >
> > w3m/stable 0.5.3+git20210102-6 amd64 [upgradable from: 0.5.3-37]
> > w3m/now 0.5.3-37 amd64 [installed,upgradable to: 0.5.3+git20210102-6]

I would install aptitude, and then run `aptitude safe-upgrade`.
Aptitude's solver can usually determine the upgrade path that avoids
breaking the machine.

Jeff

[toc] | [prev] | [next] | [standalone]

#256382

[Multipart message — attachments visible in raw view] — view raw

On Sun, 26 Mar 2023 Jesper Dybdal wrote:
> Yesterday, I upgraded Buster => Bullseye.

   Release notes for Debian 11 (bullseye)
   Upgrades from Debian 10 (buster) :: section 4.8 Obsolete Packages
   https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html#obsolete

> This morning, I got a mail from unattended-upgrades, which said:
>
>> Packages with upgradable origin but kept back:
>>   Debian stable:
>>    guile-2.2-libs w3m
>
> and
>
>> Package guile-2.2-libs is kept back because a related package is
>> kept back or due to local apt_preferences(5).
>>
>> Package w3m is kept back because a related package is kept back or
>> due to local apt_preferences(5).
>
> What does this mean?

My guess is that you have packages from Buster still installed, which
are now obsolete (ie, not packaged for Bullseye). I speculate that
these obsolete packages depend on guile-2.2-libs and w3m, and that
this somehow (*waves hands around vaguely*) causes guile-2.2-libs and
w3m to be held back.

I "guess" and "speculate", and I confess I don't really know.

(But in the remainder of my reply, I foolishly pretend that I do.)

> I have what I believe to be a clean install, I have never used
> apt_preferences,

The message says

   ...because a related package is kept back OR due to local
   apt_preferences(5).

That is, kept back (for whatever reason), OR because of
apt_preferences. It need not have anything to do with apt_preferences.

> and until now, I had never heard of guile or w3m.

  $ apt-cache show guile-2.2-libs w3m

> And I don't quite understand why I have them installed at all.

  $ apt-mark showauto | grep -xE 'guile-2.2-libs|w3m'

If they show up in the output of "apt-mark showauto", they were
automatically installed (I'd guess in order to satisfy dependencies,
recommends, etc)

> My sources.list contains only bullseye and bullseye-backports.

Today it does.

But the day before yesterday, I gather it was Buster's Last Stand.

> What do I do?

Two options come to mind.

FIRST OPTION:

>From the section of the Bullseye release notes I linked above...

   Some package management front-ends provide easy ways of finding
   installed packages that are no longer available from any known
   repository. The aptitude textual user interface lists them in the
   category “Obsolete and Locally Created Packages”, and they can be
   listed and purged from the commandline with:

      # aptitude search '~o'
      # aptitude purge '~o'

I guess you could try that search command above, first. And then if
you don't care about purging the obsolete packages it lists, then I
guess you could purge them, to see if that permits you to upgrade
these two packages that you never knew you had installed, and never
explicitly asked for.

SECOND OPTION:

Since you have no explicit desire for either w3m or guile-2.2-libs,
you could pretend to remove them, and see what your package manager
thinks that entails.

With apt-get, I would do

  $ apt-get -Vs remove w3m

and

  $ apt-get -Vs guile-2.2-libs

The -s makes it just for pretend, and the -V makes the packages apt
threatens to remove show up in a nice column, instead jammed into one
long hard-to-read row.

If the removals don't look threatening to you, you know what to do.

And if they do look threatening to you, then don't do it for real!

> apt list says:
>> guile-2.2-libs/stable 2.2.7+1-6 amd64 [upgradable from: 2.2.4+1-2+deb10u1]
>> guile-2.2-libs/now 2.2.4+1-2+deb10u1 amd64 [installed,upgradable to: 
>> 2.2.7+1-6]
>> 
>> w3m/stable 0.5.3+git20210102-6 amd64 [upgradable from: 0.5.3-37]
>> w3m/now 0.5.3-37 amd64 [installed,upgradable to: 0.5.3+git20210102-6]

I notice that the installed versions listed above are in buster. This
seems consistent with them being dependencies of buster packages that
are now obsolete in bullseye.

-- 
It is wisdom to recognize necessity, when all other courses have been
weighed, though as folly it may appear to those who cling to false hope.
-- Gandalf

[toc] | [prev] | [next] | [standalone]

#256383

Thanks a lot for the responses.  I'm still in doubt as to what to do.

One thing I forgot to mention yesterday, but which I now think may be 
correlated with this problem, is that yesterday's upgrade mysteriously 
removed roundcube.  I have no idea why, and I want it back, but that is 
not particularly urgent.  I wonder if roundcube could have some 
dependencies that influence the other problem.

I have saved the responses to some of your suggested commands; they may 
not be interesting, but just in case, they are available at
     https://www.dybdal.dk/bullseye
with links in the text below.

On 2023-03-26 13:17, davidson wrote:
> On Sun, 26 Mar 2023 Jesper Dybdal wrote:
>> Yesterday, I upgraded Buster => Bullseye.
>
>   Release notes for Debian 11 (bullseye)
>   Upgrades from Debian 10 (buster) :: section 4.8 Obsolete Packages
> https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html#obsolete
>
>> This morning, I got a mail from unattended-upgrades, which said:
>>
>>> Packages with upgradable origin but kept back:
>>>   Debian stable:
>>>    guile-2.2-libs w3m
>>
>> and
>>
>>> Package guile-2.2-libs is kept back because a related package is
>>> kept back or due to local apt_preferences(5).
>>>
>>> Package w3m is kept back because a related package is kept back or
>>> due to local apt_preferences(5).
>>
>> What does this mean?
>
> My guess is that you have packages from Buster still installed, which
> are now obsolete (ie, not packaged for Bullseye). I speculate that
> these obsolete packages depend on guile-2.2-libs and w3m, and that
> this somehow (*waves hands around vaguely*) causes guile-2.2-libs and
> w3m to be held back.
>
> I "guess" and "speculate", and I confess I don't really know.
>
> (But in the remainder of my reply, I foolishly pretend that I do.)
>
>> I have what I believe to be a clean install, I have never used
>> apt_preferences,
>
> The message says
>
>   ...because a related package is kept back OR due to local
>   apt_preferences(5).
>
> That is, kept back (for whatever reason), OR because of
> apt_preferences. It need not have anything to do with apt_preferences.
>
>> and until now, I had never heard of guile or w3m.
>
>  $ apt-cache show guile-2.2-libs w3m
>
>> And I don't quite understand why I have them installed at all.
>
>  $ apt-mark showauto | grep -xE 'guile-2.2-libs|w3m'
>
> If they show up in the output of "apt-mark showauto", they were
> automatically installed (I'd guess in order to satisfy dependencies,
> recommends, etc)

guile-2.2-libs do show up, w3m does not.
Response in https://www.dybdal.dk/bullseye/apt-mark-show-auto.txt

>
>> My sources.list contains only bullseye and bullseye-backports.
>
> Today it does.
>
> But the day before yesterday, I gather it was Buster's Last Stand.
Indeed.  And at that time, sources.list contained just buster and 
buster-backports.

>
>> What do I do?
>
> Two options come to mind.
>
> FIRST OPTION:
>
>> From the section of the Bullseye release notes I linked above...
>
>   Some package management front-ends provide easy ways of finding
>   installed packages that are no longer available from any known
>   repository. The aptitude textual user interface lists them in the
>   category “Obsolete and Locally Created Packages”, and they can be
>   listed and purged from the commandline with:
>
>      # aptitude search '~o'
>      # aptitude purge '~o'
>
> I guess you could try that search command above, first. And then if
> you don't care about purging the obsolete packages it lists, then I
> guess you could purge them, to see if that permits you to upgrade
> these two packages that you never knew you had installed, and never
> explicitly asked for.
The search command gives a list of 108 packages, which I'm somewhat 
reluctant to purge.
Output in https://www.dybdal.dk/bullseye/aptitude-search-obsolete.txt

>
> SECOND OPTION:
>
> Since you have no explicit desire for either w3m or guile-2.2-libs,
> you could pretend to remove them, and see what your package manager
> thinks that entails.
>
> With apt-get, I would do
>
>  $ apt-get -Vs remove w3m

That gives a list of 129 packages that "were automatically installed and 
are no longer required" but  as I understand it, it will remove only 
w3m, not those 129 packages.
Output in https://www.dybdal.dk/bullseye/apt-get-Vs-remove-w3m.txt

> and
>
>  $ apt-get -Vs guile-2.2-libs
That gives first a list of 134 packages, and then:
The following packages will be REMOVED:
    guile-2.2-libs (2.2.7+1-6)
    libmailutils7 (1:3.10-3+b1)
    mailutils (1:3.10-3+b1)

I am not quite certain that I do not use or will use mailutils.
Output in https://www.dybdal.dk/bullseye/apt-get-Vs-remove-guile.txt

>
> The -s makes it just for pretend, and the -V makes the packages apt
> threatens to remove show up in a nice column, instead jammed into one
> long hard-to-read row.
>
> If the removals don't look threatening to you, you know what to do.
>
> And if they do look threatening to you, then don't do it for real!
>
>> apt list says:
>>> guile-2.2-libs/stable 2.2.7+1-6 amd64 [upgradable from: 
>>> 2.2.4+1-2+deb10u1]
>>> guile-2.2-libs/now 2.2.4+1-2+deb10u1 amd64 [installed,upgradable to: 
>>> 2.2.7+1-6]
>>>
>>> w3m/stable 0.5.3+git20210102-6 amd64 [upgradable from: 0.5.3-37]
>>> w3m/now 0.5.3-37 amd64 [installed,upgradable to: 0.5.3+git20210102-6]
>
> I notice that the installed versions listed above are in buster. This
> seems consistent with them being dependencies of buster packages that
> are now obsolete in bullseye.
>

I'm leaning towards removing those packages.  And when I lose mailutils, 
then I can reinstall it when I need it.
But perhaps I will try to install the lost roundcube again first, and 
see if it changes the state.

Does that sound sensible?

Again thanks for your help,
Jesper

-- 
Jesper Dybdal
https://www.dybdal.dk

[toc] | [prev] | [next] | [standalone]

#256403

[Multipart message — attachments visible in raw view] — view raw

On Sun, 26 Mar 2023 Jesper Dybdal wrote:
> Thanks a lot for the responses.

It is a confusing mystery!

> I'm still in doubt as to what to do.

I notice that according to your posted output from the commands,

   apt-get -Vs remove {w3m,guile-2.2-libs}

that both packages now appear to be up-to-date, relative to the
versions current in bullseye:

   https://www.dybdal.dk/bullseye/apt-get-Vs-remove-w3m.txt
   [...]
   The following packages will be REMOVED:
      w3m (0.5.3+git20210102-6)

   https://www.dybdal.dk/bullseye/apt-get-Vs-remove-guile.txt
   [...]
   The following packages will be REMOVED:
      guile-2.2-libs (2.2.7+1-6)
      libmailutils7 (1:3.10-3+b1)
      mailutils (1:3.10-3+b1)

> One thing I forgot to mention yesterday, but which I now think may
> be correlated with this problem, is that yesterday's upgrade
> mysteriously removed roundcube.  I have no idea why, and I want it
> back, but that is not particularly urgent.  I wonder if roundcube
> could have some dependencies that influence the other problem.

Even on my good days, your guess is probably better than mine. And in
my present state of confusion, I will decline to speculate. :D

> I have saved the responses to some of your suggested commands; they
> may not be interesting,

They were.

> but just in case, they are available at
>     https://www.dybdal.dk/bullseye
> with links in the text below.

Yes, I was curious. Thank you.

> On 2023-03-26 13:17, davidson wrote:
>> On Sun, 26 Mar 2023 Jesper Dybdal wrote:
[trimmed]
>>  $ apt-mark showauto | grep -xE 'guile-2.2-libs|w3m'

By the way, I learned today that the same output can be had more
simply with

   $ apt-mark showauto guile-2.2-libs w3m

[trimmed]
>>> My sources.list contains only bullseye and bullseye-backports.
>> 
>> Today it does.
>> 
>> But the day before yesterday, I gather it was Buster's Last Stand.
>
> Indeed.  And at that time, sources.list contained just buster and 
> buster-backports.

By the way, does your sources.list really have no line for security
updates? Nothing like this one?

   deb http://security.debian.org/debian-security bullseye-security main non-free

[trimmed]
>> FIRST OPTION:
[trimmed]
>>      # aptitude search '~o'
>>      # aptitude purge '~o'
>> 
>> I guess you could try that search command above, first. And then if
>> you don't care about purging the obsolete packages it lists, then I
>> guess you could purge them, to see if that permits you to upgrade
>> these two packages that you never knew you had installed, and never
>> explicitly asked for.
>
> The search command gives a list of 108 packages, which I'm somewhat
> reluctant to purge.
>
> Output in https://www.dybdal.dk/bullseye/aptitude-search-obsolete.txt

I do not use aptitude at all, and therefore know nothing about it. So
do not construe the next bit as advice.

In the absence of a particular reason to keep around a package which
won't receive updates (security or otherwise) during a system
release's lifetime, I am personally inclined to purge it, one way or
another. (Not with aptitude, though, because I don't know the first
thing about how to keep it from doing things I don't want done.)

Sometimes there are reasons to keep them, of course.

And I hear that some people don't even need reasons, if you can
believe this. They just do whatever they want!

>> SECOND OPTION:
[trim]
>> 
>>  $ apt-get -Vs remove w3m
>
> That gives a list of 129 packages that "were automatically installed
> and are no longer required" but  as I understand it, it will remove
> only w3m, not those 129 packages.

True. APT is just keeping you informed.

> Output in https://www.dybdal.dk/bullseye/apt-get-Vs-remove-w3m.txt

Comparing the autoremoval list in the output above to your list of
obsolete packages

   https://www.dybdal.dk/bullseye/aptitude-search-obsolete.txt

it looks like among those 129 packages, that

   # apt-get autoremove

would remove many (about 46?) of the obsolete packages.

You can use

   # apt-mark manual favorite-package1 favorite-package2 ...

to keep favorite-packages from being autoremoved.

>> and
>> 
>>  $ apt-get -Vs guile-2.2-libs

I have resisted the compulsion to correct my own typo in the above
command.

> That gives first a list of 134 packages, and then:

It baffles me that the number of packages suggested for autoremoval is
different, between guile-2.2-libs and w3m.

> The following packages will be REMOVED:
>    guile-2.2-libs (2.2.7+1-6)
>    libmailutils7 (1:3.10-3+b1)
>    mailutils (1:3.10-3+b1)
>
> I am not quite certain that I do not use or will use mailutils.

To me, those mailutils package versions look up-to-date for bullseye
now, as does guile-2.2-libs!

[trim]
>>> apt list says:
>>>> guile-2.2-libs/stable 2.2.7+1-6 amd64 [upgradable from: 
>>>> 2.2.4+1-2+deb10u1]
>>>> guile-2.2-libs/now 2.2.4+1-2+deb10u1 amd64 [installed,upgradable to: 
>>>> 2.2.7+1-6]
>>>> 
>>>> w3m/stable 0.5.3+git20210102-6 amd64 [upgradable from: 0.5.3-37]
>>>> w3m/now 0.5.3-37 amd64 [installed,upgradable to: 0.5.3+git20210102-6]

(Above excerpt left untrimmed for easy comparison with more recent output.)

[trimmed discussion of mailutils]
> But perhaps I will try to install the lost roundcube again first,
> and see if it changes the state.
>
> Does that sound sensible?

Sure.

> Again thanks for your help,

It's been very interesting. Have a good week.

-- 
Hackers are free people. They are like artists. If they are in a good
mood, they get up in the morning and begin painting their pictures.
-- Vladimir Putin

[toc] | [prev] | [next] | [standalone]

#256404

On 2023-03-27 10:59, davidson wrote:
>
> By the way, does your sources.list really have no line for security
> updates? Nothing like this one?
>
>   deb http://security.debian.org/debian-security bullseye-security 
> main non-free

Yes, it does: https://www.dybdal.dk/bullseye/sources.list

I currently do not use contrib, non-free, or backports, but I like to 
have them in sources.list when I may some day need them.  But only the 
Bullseye (or backport) versions.

> # apt-get autoremove
> would remove many (about 46?) of the obsolete packages.
>
> You can use
>
>   # apt-mark manual favorite-package1 favorite-package2 ...
>
> to keep favorite-packages from being autoremoved.

I will probably do an autoremove when everything seems stable and I have 
a few backups.

>
> It baffles me that the number of packages suggested for autoremoval is
> different, between guile-2.2-libs and w3m.
Me too.
>
> [trim]
>>>> apt list says:
>>>>> guile-2.2-libs/stable 2.2.7+1-6 amd64 [upgradable from: 
>>>>> 2.2.4+1-2+deb10u1]
>>>>> guile-2.2-libs/now 2.2.4+1-2+deb10u1 amd64 [installed,upgradable 
>>>>> to: 2.2.7+1-6]
>>>>>
>>>>> w3m/stable 0.5.3+git20210102-6 amd64 [upgradable from: 0.5.3-37]
>>>>> w3m/now 0.5.3-37 amd64 [installed,upgradable to: 0.5.3+git20210102-6]
>
> (Above excerpt left untrimmed for easy comparison with more recent 
> output.)
>
> [trimmed discussion of mailutils]
>> But perhaps I will try to install the lost roundcube again first,
>> and see if it changes the state.
>>
>> Does that sound sensible?
>
> Sure.
>
>> Again thanks for your help,
>
> It's been very interesting. Have a good week.
Thanks!
Jesper

-- 
Jesper Dybdal
https://www.dybdal.dk

[toc] | [prev] | [next] | [standalone]

#256422

On Mon 27 Mar 2023 at 07:49:13 (-0400), Greg Wooledge wrote:
> On Mon, Mar 27, 2023 at 01:20:32PM +0200, Vincent Lefevre wrote:
> > On 2023-03-27 00:21:18 +0200, Jesper Dybdal wrote:
> > > On 2023-03-26 23:12, Jeffrey Walton wrote:
> > > > On Sun, Mar 26, 2023 at 5:16 AM Jesper Dybdal <jd-debian-user@dybdal.dk> wrote:
> > > > > Yesterday, I upgraded Buster => Bullseye.
> > > > For completeness, here is the Debian procedure for a release upgrade:
> > > > https://wiki.debian.org/DebianUpgrade .
> > > Thanks.  Interesting that the Wiki recommends using apt-get, while the
> > > Bullseye release notes recommend apt.
> > 
> > Probably because "apt" is newer and the wiki hasn't been updated yet.
> > It seems that they are very similar. The only difference I could see
> > is that apt adds coloring.
> 
> >From an end user's point of view, the three main differences between
> "apt-get" and "apt" are:

A fourth is that apt-get is recommended for scripting as its CLI
is stable, whereas apt's may well change.

> For actually configuring apt/apt-get, the options are somewhat hard to
> find.

Most, but not all, are in /usr/share/doc/apt/examples/configure-index.
Those ANSI colours haven't yet made it in, for example.

> The configuration element for --with-new-pkgs is identified in apt-get(8)
> at the end of the description of --with-new-pkgs.  This element does not
> appear AT ALL in apt.conf(5).

AIUI you're expected to add a file, say, 90-my-opts into apt.conf.d/
with   Upgrade-Allow-New "true";   in it.

On Sun 26 Mar 2023 at 14:50:45 (+0200), Jesper Dybdal wrote:
> Thanks a lot for the responses.  I'm still in doubt as to what to do.
> 
> One thing I forgot to mention yesterday, but which I now think may be
> correlated with this problem, is that yesterday's upgrade mysteriously
> removed roundcube.  I have no idea why, and I want it back, but that
> is not particularly urgent.  I wonder if roundcube could have some
> dependencies that influence the other problem.
[ … ]
> I'm leaning towards removing those packages.  And when I lose
> mailutils, then I can reinstall it when I need it.
> But perhaps I will try to install the lost roundcube again first, and
> see if it changes the state.
> 
> Does that sound sensible?

The downside is the more high-level packages you have installed,
the more dependencies, and a more difficult path to resolution.

On Mon 27 Mar 2023 at 11:27:31 (+0200), Jesper Dybdal wrote:
> On 2023-03-27 10:59, davidson wrote:
> > It baffles me that the number of packages suggested for autoremoval is
> > different, between guile-2.2-libs and w3m.
> Me too.

On my system, w3m is only Recommended for installation, so it's
effectively top-level. It has few dependencies, and those it has
are the sort used by many packages. So removing w3m has liitle
effect on the rest of the system:

  $ apt-get -s purge w3m 
  [ … ]
  The following packages will be REMOVED:
    w3m*
  0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
  Purg w3m [0.5.3+git20210102-6]
  $ 

OTOH, if you remove guile-2.2-libs, you must also lose mailutils and
libmailutils7, which depend on it. Having removed them, apt finds
that there were other packages only installed to satisfy mailutils,
so these are no longer necessary either:

  $ aptitude why gsasl-common
  i   emacs-gtk        Depends    emacs-bin-common (= 1:27.1+1-3.1+deb11u2)
  i A emacs-bin-common Recommends mailutils
  i A mailutils        Depends    libgsasl7 (>= 1.1)
  i A libgsasl7        Depends    gsasl-common (= 1.10.0-4+deb11u1)
  $ aptitude why libntlm0
  i   emacs-gtk        Depends    emacs-bin-common (= 1:27.1+1-3.1+deb11u2)
  i A emacs-bin-common Recommends mailutils
  i A mailutils        Depends    libgsasl7 (>= 1.1)
  i A libgsasl7        Depends    libntlm0 (>= 1.2)
  $ 

So it can get rid of the lot:

  $ apt-get -s purge guile-2.2-libs 
  [ … ]
  The following packages were automatically installed and are no longer required:
    gsasl-common libgsasl7 libntlm0 mailutils-common
  Use 'apt autoremove' to remove them.
  The following packages will be REMOVED:
    guile-2.2-libs* libmailutils7* mailutils*
  0 upgraded, 0 newly installed, 3 to remove and 0 not upgraded.
  Purg mailutils [1:3.10-3+b1]
  Purg libmailutils7 [1:3.10-3+b1]
  Purg guile-2.2-libs [2.2.7+1-6]
  $ apt-get --purge autoremove
  [ … check the list carefully … ]

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#256457

On Mon, 27 Mar 2023 Jesper Dybdal wrote:
> On 2023-03-27 10:59, davidson wrote:
>> It baffles me that the number of packages suggested for autoremoval is
>> different, between guile-2.2-libs and w3m.
> Me too.

The two packages depend on different collections of supporting
packages.

And so, depending on which package you remove --- guile-2.2-libs or
w3m --- a different set of automatically-installed packages will be
left installed for no apparent purpose (because the package they were
installed to support is now gone), and eligible for autoremoval.

This mostly obvious fact (which wasn't obvious to me yesterday) is
obscured by the sheer number of packages *already* eligible for
autoremoval on the system, before removing either of the two packages
in question.

-- 
MS CLINTON: If you google up what the Chinese claim is, it's the entire South China sea.
MR BLANKFEIN: An unfortunate name.
MS CLINTON: Which one?
MR BLANKFEIN: The South China sea.

[toc] | [prev] | [next] | [standalone]

#256464

On 2023-03-28 10:56, davidson wrote:
> On Mon, 27 Mar 2023 Jesper Dybdal wrote:
>> On 2023-03-27 10:59, davidson wrote:
>>> It baffles me that the number of packages suggested for autoremoval is
>>> different, between guile-2.2-libs and w3m.
>> Me too.
>
> The two packages depend on different collections of supporting
> packages.
>
> And so, depending on which package you remove --- guile-2.2-libs or
> w3m --- a different set of automatically-installed packages will be
> left installed for no apparent purpose (because the package they were
> installed to support is now gone), and eligible for autoremoval.
>
> This mostly obvious fact (which wasn't obvious to me yesterday) is
> obscured by the sheer number of packages *already* eligible for
> autoremoval on the system, before removing either of the two packages
> in question.
>
The large number is probably primarily packages that roundcube depends 
upon - but roundcube disappeared during the upgrade.  When I've seen the 
system being stable for a while, I'll reinstall roundcube - and it that 
goes well, do an autoremove.

Thanks,
Jesper

-- 
Jesper Dybdal
https://www.dybdal.dk

[toc] | [prev] | [next] | [standalone]

#256421

On 2023-03-27 10:59, davidson wrote:
>
>>>> apt list says:
>>>>> guile-2.2-libs/stable 2.2.7+1-6 amd64 [upgradable from: 
>>>>> 2.2.4+1-2+deb10u1]
>>>>> guile-2.2-libs/now 2.2.4+1-2+deb10u1 amd64 [installed,upgradable 
>>>>> to: 2.2.7+1-6]
>>>>>
>>>>> w3m/stable 0.5.3+git20210102-6 amd64 [upgradable from: 0.5.3-37]
>>>>> w3m/now 0.5.3-37 amd64 [installed,upgradable to: 0.5.3+git20210102-6]
>
> (Above excerpt left untrimmed for easy comparison with more recent 
> output.)

I decided to try "apt-get  upgrade guile-2.2-libs".  That seems to have 
worked.  Now the situation is:
> root@nuser:~# apt list guile-2.2-libs w3m -a
> Listing... Done
> guile-2.2-libs/stable,now 2.2.7+1-6 amd64 [installed,automatic]
> w3m/stable,now 0.5.3+git20210102-6 amd64 [installed]

So now I suspect everything is ok.

Again: thanks! to all the many helpful participants in this thread.
Jesper

-- 
Jesper Dybdal
https://www.dybdal.dk

[toc] | [prev] | [next] | [standalone]

#256384

On 3/26/23, Jesper Dybdal <jd-debian-user@dybdal.dk> wrote:
> Yesterday, I upgraded Buster => Bullseye.
>
> This morning, I got a mail from unattended-upgrades, which said:
>
>> Packages with upgradable origin but kept back:
>>   Debian stable:
>>    guile-2.2-libs w3m
>
> and
>> Package guile-2.2-libs is kept back because a related package is kept back
>> or due to local apt_preferences(5).
>> Package w3m is kept back because a related package is kept back or due to
>> local apt_preferences(5).
> What does this mean?  I have what I believe to be a clean install, I
> have never used apt_preferences, and until now, I had never heard of
> guile or w3m.  And I don't quite understand why I have them installed at
> all.  My sources.list contains only bullseye and bullseye-backports.
>
> What do I do?
>
> apt list says:
>> guile-2.2-libs/stable 2.2.7+1-6 amd64 [upgradable from:
>> 2.2.4+1-2+deb10u1]
>> guile-2.2-libs/now 2.2.4+1-2+deb10u1 amd64 [installed,upgradable to:
>> 2.2.7+1-6]
>>
>> w3m/stable 0.5.3+git20210102-6 amd64 [upgradable from: 0.5.3-37]
>> w3m/now 0.5.3-37 amd64 [installed,upgradable to: 0.5.3+git20210102-6]

DISCLAIMER: The subject line indicates a distribution upgrade, but it
looks like your sources.list is only Bullseye. My response is based on
a stabilized single

Hi.. There's a long response attached below, but first I'm wondering
if this is an appropriate instance for using:

apt-get dist-upgrade

I just searched the standing emails and didn't see it mentioned yet.
It comes to mind to ask because of the subject line here.

The rest of what I wrote.........

If this had been my upgrade, my now several years long method of
attack is to try:

apt-get upgrade guile-2.2-libs

I changed to that method after seeing it mentioned on Debian-User.
Prior to that, I *used to* do "apt-get install <held-package-name>".
Don't do that. That messes with how apt labels packages as "manual"
and "auto" with respect to how they came to be installed.

The following might work if one is nervous about the outcome, but I
don't have a way to test it to prove as fact right now:

apt-get upgrade -s guile-2.2-libs

That's a simulated upgrade that theoretically shows most of what will
occur if the user decides to follow through.

Every time I've ever chosen to upgrade a package that's been held, the
situation has been one or more of the following:

1) A package's numbering sequence has been raised a significant step
2) One or more new packages will be installed as part of the newest upgrade
3) One or more old packages will be removed as part of the newest upgrade.

Step 1 usually runs in tandem with Step 3. Not always, though. Python2
and Python3 come to mind as an exception. They can both be installed
together in cases of dire necessity. I'm not totally comfortable
highlighting Python as an example, but I am seeing them called
"different versions of" instead of "different programs based on"
Python out on the Net.

The kernel is an example of where holds occur on regular occasion. The
kernel affects almost everything else. Developers keeping it on hold
helps system administrators manually address its upgrade. That gives
sysadmins the opportunity to review the kernel's changelog and verify
that their production machines will continue to work as flawlessly as
possible after each upgrade.

For my usage of Sid, I would look at:

https://metadata.ftp-master.debian.org/changelogs//main/l/linux-signed-amd64/linux-signed-amd64_6.1.20+1_changelog

That was found by following a path starting at:

https://packages.debian.org/search?keywords=linux-image-amd64

Cindy :)

Side Note: I say "kernel affects _almost_ everything else" because
installation of the kernel is not the first step in the debootstrap
process. The kernel's installation occurs a few steps in after e.g.
the time settings, HOSTNAME, keyboard configuration, apt's
personalized repositories, limited sysadmin type package
installations, and /dev's base ("generic") devices have been
established. The steps to perform those actions operate successfully
with no kernel on board yet.

-- 
Talking Rock, Pickens County, Georgia, USA
* runs with birdseed *

[toc] | [prev] | [next] | [standalone]

#256386

On 2023-03-26 17:37, Cindy Sue Causey wrote:
> On 3/26/23, Jesper Dybdal <jd-debian-user@dybdal.dk> wrote:
>
>>> Packages with upgradable origin but kept back:
>>>    Debian stable:
>>>     guile-2.2-libs w3m
>>
> DISCLAIMER: The subject line indicates a distribution upgrade, but it
> looks like your sources.list is only Bullseye. My response is based on
> a stabilized single
It was a clean Buster with a few backports, and I upgraded it following 
the instructions in the Bullseye release notes. Basically:

* apt update
* apt upgrade --without-new-pkgs
* apt full-upgrade

>
> Hi.. There's a long response attached below, but first I'm wondering
> if this is an appropriate instance for using:
>
> apt-get dist-upgrade
>
> I just searched the standing emails and didn't see it mentioned yet.
> It comes to mind to ask because of the subject line here.
>
> The rest of what I wrote.........
>
> If this had been my upgrade, my now several years long method of
> attack is to try:
>
> apt-get upgrade guile-2.2-libs
> I changed to that method after seeing it mentioned on Debian-User.
> Prior to that, I *used to* do "apt-get install <held-package-name>".
> Don't do that. That messes with how apt labels packages as "manual"
> and "auto" with respect to how they came to be installed.
>
> The following might work if one is nervous about the outcome, but I
> don't have a way to test it to prove as fact right now:
>
> apt-get upgrade -s guile-2.2-libs

Doing that gives:
The following packages will be REMOVED:
   libgc1c2
The following NEW packages will be installed:
   libgc1
The following packages will be upgraded:
   guile-2.2-libs libdatetime-timezone-perl tzdata w3m

I think I will either do that or try to remove them

If I try "apt-get -s upgrade" (i.e., without the package name) it says:
The following packages have been kept back:
   guile-2.2-libs w3m
The following packages will be upgraded:
   libdatetime-timezone-perl tzdata

So I'm beginning to suspect that the libgc1/libgc1gc2 packages have 
something to do with it.

Thanks a lot! - also for the more general information quoted below.
Jesper

> That's a simulated upgrade that theoretically shows most of what will
> occur if the user decides to follow through.
>
> Every time I've ever chosen to upgrade a package that's been held, the
> situation has been one or more of the following:
>
> 1) A package's numbering sequence has been raised a significant step
> 2) One or more new packages will be installed as part of the newest upgrade
> 3) One or more old packages will be removed as part of the newest upgrade.
>
> Step 1 usually runs in tandem with Step 3. Not always, though. Python2
> and Python3 come to mind as an exception. They can both be installed
> together in cases of dire necessity. I'm not totally comfortable
> highlighting Python as an example, but I am seeing them called
> "different versions of" instead of "different programs based on"
> Python out on the Net.
>
> The kernel is an example of where holds occur on regular occasion. The
> kernel affects almost everything else. Developers keeping it on hold
> helps system administrators manually address its upgrade. That gives
> sysadmins the opportunity to review the kernel's changelog and verify
> that their production machines will continue to work as flawlessly as
> possible after each upgrade.
>
> For my usage of Sid, I would look at:
>
> https://metadata.ftp-master.debian.org/changelogs//main/l/linux-signed-amd64/linux-signed-amd64_6.1.20+1_changelog
>
> That was found by following a path starting at:
>
> https://packages.debian.org/search?keywords=linux-image-amd64
>
> Cindy :)
>
> Side Note: I say "kernel affects _almost_ everything else" because
> installation of the kernel is not the first step in the debootstrap
> process. The kernel's installation occurs a few steps in after e.g.
> the time settings, HOSTNAME, keyboard configuration, apt's
> personalized repositories, limited sysadmin type package
> installations, and /dev's base ("generic") devices have been
> established. The steps to perform those actions operate successfully
> with no kernel on board yet.
>

-- 
Jesper Dybdal
https://www.dybdal.dk

[toc] | [prev] | [next] | [standalone]

#256387

On Sun 26 Mar 2023 at 11:16:21 (+0200), Jesper Dybdal wrote:
> Yesterday, I upgraded Buster => Bullseye.
> 
> This morning, I got a mail from unattended-upgrades, which said:
> 
> > Packages with upgradable origin but kept back:
> >   Debian stable:
> >    guile-2.2-libs w3m
> 
> and
> > Package guile-2.2-libs is kept back because a related package is kept back or due to local apt_preferences(5).
> > Package w3m is kept back because a related package is kept back or due to local apt_preferences(5).
> What does this mean?  I have what I believe to be a clean install, I
> have never used apt_preferences, and until now, I had never heard of
> guile or w3m.  And I don't quite understand why I have them installed
> at all.  My sources.list contains only bullseye and
> bullseye-backports.

It's a little odd that, the day after upgrading releases, you
already have backports in your sources list. Is there a specific
reason for that?

Your system seems to have some old packages on it; for example,
heirloom-mailx and ripole are both from stretch. If you need them,
check trhat you still have access to local copies of those packages
and then try removing them to see whether they're causing a logjam.

> apt list says:
> > guile-2.2-libs/stable 2.2.7+1-6 amd64 [upgradable from: 2.2.4+1-2+deb10u1]
> > guile-2.2-libs/now 2.2.4+1-2+deb10u1 amd64 [installed,upgradable
> > to: 2.2.7+1-6]
> > 
> > w3m/stable 0.5.3+git20210102-6 amd64 [upgradable from: 0.5.3-37]
> > w3m/now 0.5.3-37 amd64 [installed,upgradable to: 0.5.3+git20210102-6]

If you read the Release Notes that come with each release, you'll
find instructions on "cleaning" a system before upgrading. A useful
tool to help with that is, for example:

$ aptitude why w3m
i   imagemagick-6-doc Recommends www-browser
i   w3m               Provides   www-browser
$ 

which would mean, on my system in similar circumstances, that I could
remove w3m without ill effects, and then reinstall it later, after
things have unjammed. Similarly:

$ aptitude why guile-2.2-libs 
i   emacs-gtk        Depends    emacs-bin-common (= 1:27.1+1-3.1+deb11u2)
i A emacs-bin-common Recommends mailutils
i A mailutils        Depends    libmailutils7
i A libmailutils7    Depends    guile-2.2-libs
$ 

Here I could remove mailutils, though in this case certain commands
could temporarily fail, eg a cron job that sends an email.

$ apt-get -s purge mailutils
[ … ]
The following packages were automatically installed and are no longer required:
  gsasl-common guile-2.2-libs libgsasl7 libmailutils7 libntlm0 mailutils-common
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
  mailutils*
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
Purg mailutils [1:3.10-3+b1]
$ 

One of those no longer required packages may be what's causing the
problem. They can be reinstalled after you get a clean upgrade.

If things don't turn out as simple as that, then I would have an
in-depth read of   man aptitude   which can test (aptitude -s)
various paths for fixing the problem. It has the patience to
figure out all the dependency/recommendation chains for any
package on the system. (My system has 56 reasons to install
guile-2.2-libs though, as we know, none is entirely based on
dependencies.)
  $ aptitude -v --show-summary=all-packages why guile-2.2-libs | less

Not /every/ package on a system has to come from the same release
version, but you should know which are the exceptions, why they're
installed, and what their dependencies are. So, for example, I have
squeeze's xtoolwait, whose dependencies, libc6 (>= 2.2.5), libx11-6,
and libxext6, are straightforward to satisfy.

One configuration change I always make is:

  $ cat /etc/logrotate.d/apt
  /var/log/apt/term.log {
    rotate -1
    monthly
    compress
    missingok
    notifempty
  }
  /var/log/apt/history.log {
    rotate -1
    monthly
    compress
    missingok
    notifempty
  }
$ 

which keeps a perpetual log of what gets installed on a system, when,
and hints as to why. This helps to answer the questions implied in
your opening paragraphs. (I don't install with aptitude, but that
has a similar configuration parameter.)

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#256394

On 2023-03-26 20:15, David Wright wrote:
> On Sun 26 Mar 2023 at 11:16:21 (+0200), Jesper Dybdal wrote:
>> Yesterday, I upgraded Buster => Bullseye.
>>
>> This morning, I got a mail from unattended-upgrades, which said:
>>
>>> Packages with upgradable origin but kept back:
>>>    Debian stable:
>>>     guile-2.2-libs w3m
>> and
>>> Package guile-2.2-libs is kept back because a related package is kept back or due to local apt_preferences(5).
>>> Package w3m is kept back because a related package is kept back or due to local apt_preferences(5).
>> What does this mean?  I have what I believe to be a clean install, I
>> have never used apt_preferences, and until now, I had never heard of
>> guile or w3m.  And I don't quite understand why I have them installed
>> at all.  My sources.list contains only bullseye and
>> bullseye-backports.
> It's a little odd that, the day after upgrading releases, you
> already have backports in your sources list. Is there a specific
> reason for that?

No.  The reason is only that experience shows that during the lifetime 
of a stable release, I will install a few backports.  So the list might 
just as well be ready from start.  And currently, there is no backported 
packages installed.

>
> Your system seems to have some old packages on it; for example,
> heirloom-mailx and ripole are both from stretch. If you need them,
> check trhat you still have access to local copies of those packages
> and then try removing them to see whether they're causing a logjam.
>
>> apt list says:
>>> guile-2.2-libs/stable 2.2.7+1-6 amd64 [upgradable from: 2.2.4+1-2+deb10u1]
>>> guile-2.2-libs/now 2.2.4+1-2+deb10u1 amd64 [installed,upgradable
>>> to: 2.2.7+1-6]
>>>
>>> w3m/stable 0.5.3+git20210102-6 amd64 [upgradable from: 0.5.3-37]
>>> w3m/now 0.5.3-37 amd64 [installed,upgradable to: 0.5.3+git20210102-6]
> If you read the Release Notes that come with each release, you'll
> find instructions on "cleaning" a system before upgrading. A useful
> tool to help with that is, for example:
>
> $ aptitude why w3m
> i   imagemagick-6-doc Recommends www-browser
> i   w3m               Provides   www-browser
> $
Thanks.  The release notes do not mention aptitude why, which seems a 
good tool.
> which would mean, on my system in similar circumstances, that I could
> remove w3m without ill effects, and then reinstall it later, after
> things have unjammed. Similarly:
>
> $ aptitude why guile-2.2-libs
> i   emacs-gtk        Depends    emacs-bin-common (= 1:27.1+1-3.1+deb11u2)
> i A emacs-bin-common Recommends mailutils
> i A mailutils        Depends    libmailutils7
> i A libmailutils7    Depends    guile-2.2-libs
> $
>
> Here I could remove mailutils, though in this case certain commands
> could temporarily fail, eg a cron job that sends an email.
>
> $ apt-get -s purge mailutils
> [ … ]
> The following packages were automatically installed and are no longer required:
>    gsasl-common guile-2.2-libs libgsasl7 libmailutils7 libntlm0 mailutils-common
> Use 'apt autoremove' to remove them.
> The following packages will be REMOVED:
>    mailutils*
> 0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
> Purg mailutils [1:3.10-3+b1]
> $
>
> One of those no longer required packages may be what's causing the
> problem. They can be reinstalled after you get a clean upgrade.
>
> If things don't turn out as simple as that, then I would have an
> in-depth read of   man aptitude   which can test (aptitude -s)
> various paths for fixing the problem. It has the patience to
> figure out all the dependency/recommendation chains for any
> package on the system. (My system has 56 reasons to install
> guile-2.2-libs though, as we know, none is entirely based on
> dependencies.)
>    $ aptitude -v --show-summary=all-packages why guile-2.2-libs | less
>
> Not /every/ package on a system has to come from the same release
> version, but you should know which are the exceptions, why they're
> installed, and what their dependencies are. So, for example, I have
> squeeze's xtoolwait, whose dependencies, libc6 (>= 2.2.5), libx11-6,
> and libxext6, are straightforward to satisfy.
>
> One configuration change I always make is:
>
>    $ cat /etc/logrotate.d/apt
>    /var/log/apt/term.log {
>      rotate -1
>      monthly
>      compress
>      missingok
>      notifempty
>    }
>    /var/log/apt/history.log {
>      rotate -1
>      monthly
>      compress
>      missingok
>      notifempty
>    }
> $
>
> which keeps a perpetual log of what gets installed on a system, when,
> and hints as to why. This helps to answer the questions implied in
> your opening paragraphs. (I don't install with aptitude, but that
> has a similar configuration parameter.)
>
> Cheers,
> David.

I have not yet decided exactly what I'll do, but each answer to my 
original post has significantly improved my understanding of the install 
system.
Many thanks to everybody who answered!

-- 

Jesper Dybdal
https://www.dybdal.dk

[toc] | [prev] | [next] | [standalone]

#256390

On Sun, Mar 26, 2023 at 5:16 AM Jesper Dybdal <jd-debian-user@dybdal.dk> wrote:
>
> Yesterday, I upgraded Buster => Bullseye.

For completeness, here is the Debian procedure for a release upgrade:
https://wiki.debian.org/DebianUpgrade .

Jeff

[toc] | [prev] | [next] | [standalone]

#256393

On 2023-03-26 23:12, Jeffrey Walton wrote:
> On Sun, Mar 26, 2023 at 5:16 AM Jesper Dybdal <jd-debian-user@dybdal.dk> wrote:
>> Yesterday, I upgraded Buster => Bullseye.
> For completeness, here is the Debian procedure for a release upgrade:
> https://wiki.debian.org/DebianUpgrade .
Thanks.  Interesting that the Wiki recommends using apt-get, while the 
Bullseye release notes recommend apt.

-- 
Jesper Dybdal
https://www.dybdal.dk

[toc] | [prev] | [next] | [standalone]

#256405

On 2023-03-27 00:21:18 +0200, Jesper Dybdal wrote:
> On 2023-03-26 23:12, Jeffrey Walton wrote:
> > On Sun, Mar 26, 2023 at 5:16 AM Jesper Dybdal <jd-debian-user@dybdal.dk> wrote:
> > > Yesterday, I upgraded Buster => Bullseye.
> > For completeness, here is the Debian procedure for a release upgrade:
> > https://wiki.debian.org/DebianUpgrade .
> Thanks.  Interesting that the Wiki recommends using apt-get, while the
> Bullseye release notes recommend apt.

Probably because "apt" is newer and the wiki hasn't been updated yet.
It seems that they are very similar. The only difference I could see
is that apt adds coloring.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[toc] | [prev] | [next] | [standalone]

#256408

On Mon, Mar 27, 2023 at 01:20:32PM +0200, Vincent Lefevre wrote:
> On 2023-03-27 00:21:18 +0200, Jesper Dybdal wrote:
> > On 2023-03-26 23:12, Jeffrey Walton wrote:
> > > On Sun, Mar 26, 2023 at 5:16 AM Jesper Dybdal <jd-debian-user@dybdal.dk> wrote:
> > > > Yesterday, I upgraded Buster => Bullseye.
> > > For completeness, here is the Debian procedure for a release upgrade:
> > > https://wiki.debian.org/DebianUpgrade .
> > Thanks.  Interesting that the Wiki recommends using apt-get, while the
> > Bullseye release notes recommend apt.
> 
> Probably because "apt" is newer and the wiki hasn't been updated yet.
> It seems that they are very similar. The only difference I could see
> is that apt adds coloring.

>From an end user's point of view, the three main differences between
"apt-get" and "apt" are:

1) Upgrades done with apt-get retain the .deb files in
   /var/cache/apt/archives by default, whereas apt removes these .deb
   files by default.  (This is configurable.)

2) "apt-get upgrade" does not install new packages unless you supply the
   --with-new-pkgs option.  "apt upgrade" acts as if you had supplied it.
   (This is configurable.)

3) apt uses a horrible yellow color that is nigh-unreadable on a white
   background.  (This is not configurable.)

In terms of package conflict resolution and so on, they both call the
same library routines, so they both "work" the same way.  It's just
these front-end issues that change.

For actually configuring apt/apt-get, the options are somewhat hard to
find.  The configuration element for removing the .deb files appears to
be named "Clean" in apt.conf(5) (do not confuse it with Clean-Installed).

The configuration element for --with-new-pkgs is identified in apt-get(8)
at the end of the description of --with-new-pkgs.  This element does not
appear AT ALL in apt.conf(5).

Finally, there's one obscure but important difference that only arises in
specific situations.  Quoting from <https://wiki.debian.org/NewInBuster>:

    If you previously ran buster during its time as "testing", you may
    see this error when you run apt-get update:

    E: Repository 'http://ftp.us.debian.org/debian buster InRelease' changed
    its 'Suite' value from 'testing' to 'stable'
    N: This must be accepted explicitly before updates for this repository
    can be applied. See apt-secure(8) manpage for details.

    In order to accept this change, you should run apt update instead,
    at least one time. apt will prompt you for confirmation, and then
    everything proceeds normally.

I.e. there are some situations where apt will prompt you for something
whereas apt-get will just fail without prompting you (and gives you a
bogus reference to lead you on a wild goose chase).  I don't know what
all those possible situations are, but the above is one of them.

[toc] | [prev] | [next] | [standalone]

#256414

On 2023-03-27 07:49:13 -0400, Greg Wooledge wrote:
> 2) "apt-get upgrade" does not install new packages unless you supply the
>    --with-new-pkgs option.  "apt upgrade" acts as if you had supplied it.
>    (This is configurable.)

FYI, I prefer to do the upgrades of my Debian/unstable machines with
aptitude (via its TUI): that way, new packages are automatically
installed when needed, and automatically installed packages are
removed when they are no longer used (but if one wants to keep such
a package, one can mark it as manually installed). This seems to be
what makes most sense.

[...]
> Finally, there's one obscure but important difference that only arises in
> specific situations.  Quoting from <https://wiki.debian.org/NewInBuster>:
> 
>     If you previously ran buster during its time as "testing", you may
>     see this error when you run apt-get update:
> 
>     E: Repository 'http://ftp.us.debian.org/debian buster InRelease' changed
>     its 'Suite' value from 'testing' to 'stable'
>     N: This must be accepted explicitly before updates for this repository
>     can be applied. See apt-secure(8) manpage for details.
> 
>     In order to accept this change, you should run apt update instead,
>     at least one time. apt will prompt you for confirmation, and then
>     everything proceeds normally.
> 
> I.e. there are some situations where apt will prompt you for something
> whereas apt-get will just fail without prompting you (and gives you a
> bogus reference to lead you on a wild goose chase).  I don't know what
> all those possible situations are, but the above is one of them.

This seems similar to aptitude:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033359

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[toc] | [prev] | [next] | [standalone]

#256415

On Mon, Mar 27, 2023 at 02:17:11PM +0200, Vincent Lefevre wrote:
> FYI, I prefer to do the upgrades of my Debian/unstable machines with
> aptitude

aptitude is VERY different from apt/apt-get.  It uses an entirely
different pacakge conflict resolution.

Using aptitude for release upgrades (in place of "apt full-upgrade"
or "apt-get dist-upgrade") is not supported.  It can get stuck, or do
weird things.  This is why the release notes never say to use it.

Since you're on unstable, you're on your own anyway, so do whatever
works for you.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web