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

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

moving some packages back to bookworm stable

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

Contents

  moving some packages back to bookworm stable Michael Grant <mgrant@grant.org> - 2024-05-27 16:10 +0200
    Re: moving some packages back to bookworm stable Michael Grant <mgrant@grant.org> - 2024-05-27 16:30 +0200
      Re: moving some packages back to bookworm stable Greg Wooledge <greg@wooledge.org> - 2024-05-27 16:40 +0200
      Re: moving some packages back to bookworm stable Max Nikulin <manikulin@gmail.com> - 2024-05-27 17:20 +0200
    Re: moving some packages back to bookworm stable Greg Wooledge <greg@wooledge.org> - 2024-05-27 16:30 +0200
    Re: moving some packages back to bookworm stable David Wright <deblis@lionunicorn.co.uk> - 2024-05-27 17:00 +0200
    Re: moving some packages back to bookworm stable Stefan Monnier <monnier@iro.umontreal.ca> - 2024-05-27 17:10 +0200
      Re: moving some packages back to bookworm stable Dan Ritter <dsr@randomstring.org> - 2024-05-27 19:10 +0200
        Re: moving some packages back to bookworm stable Stefan Monnier <monnier@iro.umontreal.ca> - 2024-05-27 20:10 +0200
          Re: moving some packages back to bookworm stable David Wright <deblis@lionunicorn.co.uk> - 2024-05-27 20:50 +0200
          Re: moving some packages back to bookworm stable Detlef Vollmann <dv@vollmann.ch> - 2024-05-27 22:00 +0200
            Re: moving some packages back to bookworm stable David Wright <deblis@lionunicorn.co.uk> - 2024-05-28 01:30 +0200
          Re: moving some packages back to bookworm stable Max Nikulin <manikulin@gmail.com> - 2024-05-28 05:10 +0200
          Re: moving some packages back to bookworm stable <tomas@tuxteam.de> - 2024-05-28 06:30 +0200
            Re: moving some packages back to bookworm stable Dan Ritter <dsr@randomstring.org> - 2024-05-28 14:40 +0200
    Re: moving some packages back to bookworm stable Hans <hans.ullrich@loop.de> - 2024-05-27 17:40 +0200
      Re: moving some packages back to bookworm stable Michael Grant <mgrant@grant.org> - 2024-05-27 18:30 +0200
        Re: moving some packages back to bookworm stable David Wright <deblis@lionunicorn.co.uk> - 2024-05-27 20:10 +0200
          Re: moving some packages back to bookworm stable Michael Grant <mgrant@grant.org> - 2024-05-28 12:20 +0200
            Re: moving some packages back to bookworm stable Greg Wooledge <greg@wooledge.org> - 2024-05-28 13:10 +0200
              Re: moving some packages back to bookworm stable Michael Grant <mgrant@grant.org> - 2024-05-28 13:10 +0200
                Re: moving some packages back to bookworm stable Greg Wooledge <greg@wooledge.org> - 2024-05-28 14:10 +0200
                  Re: moving some packages back to bookworm stable Michael Grant <mgrant@grant.org> - 2024-05-28 15:20 +0200
                    Re: moving some packages back to bookworm stable Greg Wooledge <greg@wooledge.org> - 2024-05-28 16:30 +0200
                      Re: moving some packages back to bookworm stable Michael Grant <mgrant@grant.org> - 2024-05-28 19:10 +0200
                        Re: moving some packages back to bookworm stable Greg Wooledge <greg@wooledge.org> - 2024-05-28 19:20 +0200
                        Re: moving some packages back to bookworm stable Max Nikulin <manikulin@gmail.com> - 2024-05-28 19:30 +0200
                          Re: moving some packages back to bookworm stable Michael Grant <mgrant@grant.org> - 2024-05-28 20:00 +0200
                            Re: moving some packages back to bookworm stable Max Nikulin <manikulin@gmail.com> - 2024-05-29 06:10 +0200
            Re: moving some packages back to bookworm stable fxkl47BF@protonmail.com - 2024-05-28 15:00 +0200
        Re: moving some packages back to bookworm stable Michael Kjörling <2695bd53d63c@ewoof.net> - 2024-05-27 22:30 +0200

Page 2 of 2 — ← Prev page 1 [2]

#269631

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

On Tue, May 28, 2024 at 06:59:50AM -0400, Greg Wooledge wrote:
> On Tue, May 28, 2024 at 06:10:11AM -0400, Michael Grant wrote:
> > The following packages will be REMOVED:
> >   [...] libdb5.3t64 [...]
> 
> You've *clearly* still got testing packages installed.

YES.  As I originally said, I created this mess by installing sendmail
from testing.  And then, a month or so later, I did an
apt-get upgrade (to do updates, not a full upgrade) which pulled in
some more things from testing.  I'm trying to get back to all being
from stable.

Unless this is somehow easily fixable, I am leaning towards reverting
to my backup before the apt-get upgrade which has just sendmail from
testing.  I can more easily remove that and reinstall that before
doing the update.

The more I futz with this live machine, the deeper I seem to dig
myself into a hole.

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

#269636

On Tue, May 28, 2024 at 07:09:16AM -0400, Michael Grant wrote:
> On Tue, May 28, 2024 at 06:59:50AM -0400, Greg Wooledge wrote:
> > On Tue, May 28, 2024 at 06:10:11AM -0400, Michael Grant wrote:
> > > The following packages will be REMOVED:
> > >   [...] libdb5.3t64 [...]
> > 
> > You've *clearly* still got testing packages installed.
> 
> YES.  As I originally said, I created this mess by installing sendmail
> from testing.  And then, a month or so later, I did an
> apt-get upgrade (to do updates, not a full upgrade) which pulled in
> some more things from testing.  I'm trying to get back to all being
> from stable.

So, which part are you confused about?  Did you think there was some
easy way to FIX a frankendebian?  Are you confused because you keep
thinking "there must be some single apt command that will do all the
work for me"?

There's not.  You get to do all the work by hand.

You will most likely need to remove the testing versions of these packages
(apache2, git and so on) and then install the bookworm versions afterward.

The things to watch out for are config files (hence your backup), and
any crazy dependency situations.  In the ideal case, you'll simply be
able to remove all the packages that aren't libs, then downgrade the
libs, then reinstall the packages.  And make sure you have sensible
config files.  If you get stuck, there's always the big hammer
(dpkg --force-depends and so on).

If/when it breaks, you get to reinstall from scratch.

This is why we tell people DO NOT MIX BINARY PACKAGES FROM MULTIPLE
RELEASES.

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

#269642

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

> So, which part are you confused about?  Did you think there was some
> easy way to FIX a frankendebian?  Are you confused because you keep
> thinking "there must be some single apt command that will do all the
> work for me"?
> 
> There's not.  You get to do all the work by hand.

I am trying to do it by hand.  There's not many packages to deal
with at this point, doing this by hand looks like 10 or so packages.

> You will most likely need to remove the testing versions of these packages
> (apache2, git and so on) and then install the bookworm versions afterward.

Those dependent packages (most if not all) are not from testing.
apache2, perl, they are all installed from bookworm or
bookworm-security.

That db5.3 from testing is uninstalled and reinstalling from stable is
causing these other packages from stable to be uninstalled.  I find
that confusing.

But what about libc6?  That one really worries me.

# apt remove -s libc6
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
....a few pages of dependicies...

> The things to watch out for are config files (hence your backup), and
> any crazy dependency situations.  In the ideal case, you'll simply be
> able to remove all the packages that aren't libs, then downgrade the
> libs, then reinstall the packages.  And make sure you have sensible
> config files.  If you get stuck, there's always the big hammer
> (dpkg --force-depends and so on).
> 
> If/when it breaks, you get to reinstall from scratch.

I have a running second week old version of the same vm.  I'm rapidly
moving to abandon this and just swapping the instances around.

> This is why we tell people DO NOT MIX BINARY PACKAGES FROM MULTIPLE
> RELEASES.

Yup.  But this whole experience does make me wonder if there are
situations where it is safe.  For instance, if the thing you're
installing from a different release does not cause an update anything
from the current release to a new release.  It feels like apt might be
able to suss that out and if so, pop an "Are you sure??? (y/N)" in the
terminal.

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

#269645

On Tue, May 28, 2024 at 09:12:18AM -0400, Michael Grant wrote:
> > You will most likely need to remove the testing versions of these packages
> > (apache2, git and so on) and then install the bookworm versions afterward.
> 
> Those dependent packages (most if not all) are not from testing.
> apache2, perl, they are all installed from bookworm or
> bookworm-security.

I am skeptical of this.

> That db5.3 from testing is uninstalled and reinstalling from stable is
> causing these other packages from stable to be uninstalled.  I find
> that confusing.

Let's say that you're right.  You actually *did* download and downgrade
these packages (and just didn't show us the details for some reason), but
the packaging system is unhappy about what you're telling it to do,
and it gets overly aggressive and wants to remove some things that you
feel could remain in place.

You could just *let it remove them*, and then reinstall them.  If you've
already downloaded and downgraded them to bookworm versions, then you
probably still have the .deb files, so it wouldn't even require another
download.

> But what about libc6?  That one really worries me.

As it should!

> # apt remove -s libc6

DO NOT do this.

Downgrade it.  DO NOT remove it and then hope to reinstall it later.
Removing libc6 will break everything.

You seem to be flailing, so let me spell this out as explicitly as
possible.  When I say "downgrade a library package", I mean:

1) Download the .deb file for the bookworm(-security) version of the
   library package.

2) Run "dpkg -i libc6_whatever.deb".

3) When you inevitably get dependency conflicts, download the additional
   library packages that need to be downgraded at the same time, and add
   them to the list.

4) dpkg -i libc6_whatever.deb libwhomever.deb ....

5) Repeat until it works.

6) Helpful post-mess cleanup commands include "dpkg --configure -a" and
   "apt-get -f install".  (Yes, that last one has install with no package
   names.)

Apt is NOT built for downgrading.  If you happen to get any positive
results from an apt command that involves downgrading, you can consider
that a pleasant surprise.  Usually you need to invoke dpkg directly.

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

#269650

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

> > # apt remove -s libc6
> 
> DO NOT do this.
> 
> Downgrade it.  DO NOT remove it and then hope to reinstall it later.
> Removing libc6 will break everything.
> 
> You seem to be flailing, so let me spell this out as explicitly as
> possible.  When I say "downgrade a library package", I mean:
> 
> 1) Download the .deb file for the bookworm(-security) version of the
>    library package.
> 
> 2) Run "dpkg -i libc6_whatever.deb".
> 
> 3) When you inevitably get dependency conflicts, download the additional
>    library packages that need to be downgraded at the same time, and add
>    them to the list.
> 
> 4) dpkg -i libc6_whatever.deb libwhomever.deb ....
> 
> 5) Repeat until it works.
> 
> 6) Helpful post-mess cleanup commands include "dpkg --configure -a" and
>    "apt-get -f install".  (Yes, that last one has install with no package
>    names.)
> 
> Apt is NOT built for downgrading.  If you happen to get any positive
> results from an apt command that involves downgrading, you can consider
> that a pleasant surprise.  Usually you need to invoke dpkg directly.

Ah I see, I did not realise that's what you meant by downgrading it,
thanks.

So once I've done this dpkg -i to install a package, I can do that
without removing the old one first?

And, once I've hammered a package into place with dpkg, in the future,
will apt take it into account as a dependency of things already
installed even though apt itself didn't install or rather downgrade
the package itself?  The fact that I am dpkg installing it over a
package that apt itself installed, perhaps this keeps apt happy?

Thanks for your help.  I use apt all the time to do upgrades but
rarely do I ever need to get into weeds with it.  It's a bit of a
black box to me.

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

#269652

On Tue, May 28, 2024 at 01:00:24PM -0400, Michael Grant wrote:
> So once I've done this dpkg -i to install a package, I can do that
> without removing the old one first?

Yes, dpkg will upgrade or downgrade the existing package.

> And, once I've hammered a package into place with dpkg, in the future,
> will apt take it into account as a dependency of things already
> installed even though apt itself didn't install or rather downgrade
> the package itself?

Yes.  Dpkg is the lower level tool.  Apt is the higher level tool.
The set of installed packages is tracked by dpkg (it's in the file
/var/lib/dpkg/status which you can read if you like).  Apt calls dpkg
to do all of the installing, removing, etc.  Apt just calculates the
dependency tree and downloads the .deb files for dpkg to use.

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

#269653

On 29/05/2024 00:00, Michael Grant wrote:
>>
>> 4) dpkg -i libc6_whatever.deb libwhomever.deb ....
>>
>> 5) Repeat until it works.
>>
>> Apt is NOT built for downgrading.

Agree.

> Ah I see, I did not realise that's what you meant by downgrading it,
> thanks.

The thread is becoming excessively long. Have you posted output of "apt 
policy" to figure out what is your current configuration? You must have 
either additional config or pinning besides sources list for testing.

Out of curiosity I have tried to install sendmail and openssh-server 
from testing. I removed testing from sources list, dropped the following 
file

/etc/apt/preferences.d/80-downgrade.pref
Package: *
Pin: release n=bookworm
Pin-Priority: 1001

and after

      apt upgrade

only a couple of packages from testing survived:

libdb5.3t64/now 5.3.28+dfsg2-7 amd64 [installed,local]
libssl3t64/now 3.2.1-3 amd64 [installed,local]

I have no idea if all sendmail state and spool files have compatible 
format. So arbitrary failures may be expected.

Before downgrade it was:

libc-bin/testing,now 2.38-11 amd64 [installed]
libc-l10n/testing,now 2.38-11 all [installed,automatic]
libc6/testing,now 2.38-11 amd64 [installed]
libdb5.3t64/testing,now 5.3.28+dfsg2-7 amd64 [installed,automatic]
libsasl2-2/testing,now 2.1.28+dfsg1-6 amd64 [installed,automatic]
libsasl2-modules-db/testing,now 2.1.28+dfsg1-6 amd64 [installed,automatic]
libsasl2-modules/testing,now 2.1.28+dfsg1-6 amd64 [installed,automatic]
libssl3t64/testing,now 3.2.1-3 amd64 [installed,automatic]
libzstd1/testing,now 1.5.5+dfsg2-2 amd64 [installed]
locales/testing,now 2.38-11 all [installed]
openssh-client/testing,now 1:9.7p1-5 amd64 [installed]
openssh-server/testing,now 1:9.7p1-5 amd64 [installed]
openssh-sftp-server/testing,now 1:9.7p1-5 amd64 [installed,automatic]
openssl/testing,now 3.2.1-3 amd64 [installed,automatic]
sendmail-base/testing,now 8.18.1-3 all [installed,automatic]
sendmail-bin/testing,now 8.18.1-3 amd64 [installed,automatic]
sendmail-cf/testing,now 8.18.1-3 all [installed,automatic]
sendmail/testing,now 8.18.1-3 all [installed]
sensible-mda/testing,now 8.18.1-3 amd64 [installed,automatic]

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

#269660

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

Max, your list looks very similiar to what I'm seeing.

I seem to have suceeded in removing all of the testing packages from
my backup instance, now, just need to flip the ips around and see if
the ship still floats.

The culprits that seemed to be causing the massive dependencies were
libsasl2-2 and libsasl2-modules-db.  Though not libsasl2-modules which
i also have installed.

Using apt to try and remove the first 2 were causing this:

The following packages will be REMOVED:
  apache2 apache2-bin clamav clamav-daemon clamav-freshclam clamav-milter clamav-unofficial-sigs clamdscan colord curl dirmngr git gnupg gnupg2 gpg-wks-client
  libapache2-mod-php8.2 libapache2-mod-ruid2 libaprutil1-ldap libclamav11 libcurl3-gnutls libcurl4 libgphoto2-6 libldap-2.5-0 libmailutils9 libmemcached11 libpq5 libsane1
  libsasl2-2 mailutils mongo-tools opendkim opendkim-tools python-apt python3-certbot-apache python3-debianbts python3-pycurl python3-pysimplesoap python3-reportbug reportbug
  sane-utils sendmail sendmail-bin sensible-mda

I sucked down those 3 packages and downgraded them via 'dpkg -i' and
was able to uninstall and reinstall sendmail by apt and now, no more
packages from testing.

Whew, I won't do that again.  But it's good to know how these things work!

Thanks all for your help.

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

#269683

On 29/05/2024 00:51, Michael Grant wrote:
> The culprits that seemed to be causing the massive dependencies were
> libsasl2-2 and libsasl2-modules-db.  Though not libsasl2-modules which
> i also have installed.

With adjusted priorities these packages are not an issue for "apt upgrade".

More serious concern may be whether data written by newer versions are 
readable by older applications or whether some command in package 
scripts can fail due to downgrade of libc or some other library. That is 
why I consider downgrade as a last resort option. Trying it you should 
be prepared to a severe failure and clean reinstall.

Actually the config I posted is incomplete. There is a pitfall similar 
to APT::Default-Release (and -t option). Besides bookworm (or stable) it 
is necessary to explicitly specify bookworm-security and 
bookworm-updates (stable-security, stable-updates). Anyway it can be 
easily spotted in

     apt policy

output that has to be run to check effect of changed config files.

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

#269640

On Tue, 28 May 2024, Michael Grant wrote:

> On Mon, May 27, 2024 at 12:59:34PM -0500, David Wright wrote:
>> So what did it say after that?
>
> Sorry, here's the entire output of one of the tries:
>
> [bottom /etc/mail #1168] apt install libdb5.3/bookworm db5.3-util/bookworm db-util/bookworm
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> Selected version '5.3.28+dfsg2-1' (Debian:12.5/stable [amd64]) for 'libdb5.3'
> Selected version '5.3.28+dfsg2-1' (Debian:12.5/stable [amd64]) for 'db5.3-util'
> Selected version '5.3.2' (Debian:12.5/stable [all]) for 'db-util'
> The following packages were automatically installed and are no longer required:
>  acl apache2-data apache2-utils augeas-lenses avahi-daemon clamav-base colord-data git-man gnupg-l10n gnupg-utils gpg-wks-server guile-3.0-libs ipp-usb libapr1 libaprutil1
>  libaprutil1-dbd-sqlite3 libaugeas0 libavahi-core7 libcolorhug2 libdaemon0 libexif12 libgphoto2-l10n libgphoto2-port12 libgudev-1.0-0 libgusb2 libhashkit2 libieee1284-3 libldap-common
>  liblua5.3-0 libnspr4 libnss-mdns libnss3 libopendbx1 libopendbx1-sqlite3 libopendkim11 libpoppler-glib8 libpoppler126 libpython2-stdlib libpython3.11 librbl1 librtmp1 libsane-common
>  libsnmp-base libsnmp40 libssh2-1 libvbr2 mailutils-common python2 python2-minimal python3-augeas sane-airscan update-inetd usb.ids
> Use 'apt autoremove' to remove them.
> The following additional packages will be installed:
>  php8.2-fpm
> Suggested packages:
>  php-pear
> The following packages will be REMOVED:
>  apache2 apache2-bin clamav clamav-daemon clamav-freshclam clamav-milter clamav-unofficial-sigs clamdscan colord curl dirmngr git gnupg gnupg2 gpg-wks-client libapache2-mod-php8.2
>  libapache2-mod-ruid2 libaprutil1-ldap libclamav11 libcurl3-gnutls libcurl4 libdb5.3t64 libgphoto2-6 libldap-2.5-0 libmailutils9 libmemcached11 libpq5 libsane1 libsasl2-2
>  libsasl2-modules-db mailutils mongo-tools opendkim opendkim-tools python-apt python3-certbot-apache python3-debianbts python3-pycurl python3-pysimplesoap python3-reportbug reportbug
>  sane-utils sasl2-bin sendmail sendmail-bin sensible-mda
> The following NEW packages will be installed:
>  libdb5.3 php8.2-fpm
> The following packages will be DOWNGRADED:
>  db-util db5.3-util
> 0 upgraded, 2 newly installed, 2 downgraded, 46 to remove and 0 not upgraded.
> Need to get 1,743 kB/2,507 kB of archives.
> After this operation, 234 MB disk space will be freed.
> Do you want to continue? [Y/n] n
> Abort.
>
>>> Is there some way to get apt to reinstall a package such that it does
>>> not think it has to uninstall things which depend on it because it's
>>> being immediatly reinstalled?
>>
>> That is the idea behind reinstall, though downgrading is always
>> a test of its ability to succeed.
>
> What it says it's going to do is actually remove those 46 packages and
> not reinstall them.  I believe it!  Clearly apt is unwinding the
> dependencies.  It seems like it's not taking into account the
> downgraded libdb5.3 is a valid dependency for all the things it's
> about to uninstall so it doesn't need to uninstall those things.  I
> thought it should do that, but for some reason, it's not doing that
> for me.
>
>

i ran into exactly this same situation
apt and apt-get wanted to remove a passel of packages
i tried aptitude and it removed only the package i wanted
the system still works fine
just my experience

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

#269600

On 27 May 2024 12:23 -0400, from mgrant@grant.org (Michael Grant):
> so I thought I'd try the same process with db5.3, but removing db5.3
> wants to remove a slew of packages:
> 
> # apt reinstall -s libdb5.3/bookworm
> ...
> Selected version '5.3.28+dfsg2-1' (Debian:12.5/stable [amd64]) for 'libdb5.3'
> The following packages were automatically installed and are no longer required:
>   acl apache2-data apache2-utils augeas-lenses avahi-daemon clamav-base colord-data git-man gnupg-l10n gnupg-utils gpg-wks-server guile-3.0-libs ipp-usb libapr1 libaprutil1
>   libaprutil1-dbd-sqlite3 libaugeas0 libavahi-core7 libcolorhug2 libdaemon0 libexif12 libgphoto2-l10n libgphoto2-port12 libgudev-1.0-0 libgusb2 libhashkit2 libieee1284-3 libldap-common
>   liblua5.3-0 libnspr4 libnss-mdns libnss3 libopendbx1 libopendbx1-sqlite3 libopendkim11 libpoppler-glib8 libpoppler126 libpython2-stdlib libpython3.11 librbl1 librtmp1 libsane-common
>   libsnmp-base libsnmp40 libssh2-1 libvbr2 mailutils-common python2 python2-minimal python3-augeas sane-airscan update-inetd usb.ids
> Use 'apt autoremove' to remove them

"removing db5.3 wants to remove a slew of packages"

No, that's very likely not what apt is telling you. Rather, it's
telling you that the _current_ state of the system is that those
packages were automatically installed (very likely pulled in as
dependencies for other packages) and with the packages _currently_
installed, they are no longer needed as dependencies of anything.
Therefore, apt concludes that they would be safe to remove. I'd say
that that's a dubious conclusion, though; certainly blindly
uninstalling something like libnss3 or libpython* seems unlikely to be
a good idea.

You can confirm this with a bare for example: apt-get --simulate autoremove

I'd also suggest using -V/--verbose-versions/APT::Get::Show-Versions
while you're trying to sort this out, as which specific versions of
each package is involved may very well be very relevant information.

-- 
Michael Kjörling                     🔗 https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web