Hey. During upgrade to 1.5.3-4 I got: Removing libpam0g:amd64 (1.5.2-9.1+b1) ... runuser: error while loading shared libraries: libpam.so.0: cannot open shared object file: No such file or directory Guess there may be some timing issue, when libpam0g is already gone but hasn't been replaced by libpam0t64 yet? That happened only a bit later: … Unpacking libpam0t64:amd64 (1.5.3-4) ... Setting up libpam0t64:amd64 (1.5.3-4) ... Thanks, Chris.
Control: severity -1 serious From what you write here, it is difficult to reproduce the problem. A minimal upgrade does not reproduce this. Given that apt and aptitude use the very same solver, it is very likely that this is not an aptitude-specific problem. Can you locate a more complete upgrade log? Ideally, we'd get a reproducer using mmdebstrap SOMERELEASE /dev/null --variant=apt --include=SOMEPACKAGES --customize-hook='echo SOURCES_LIST_LINE > "$1/etc/apt/sources.list"' --chrooted-customize-hook="apt-get update" --chrooted-customize-hook="aptitude dist-upgrade" Technically speaking, I believe this is a Debian policy 3.8 violation. runuser is essential and removing libpam0g causes runuser to no longer work. I'm tentatively upgrading severity hoping that we don't get into a severity pingpong. Julian Andres Klode also thinks that it is likely to affect apt. I very much think that we're in the same spot as with libselinux here and really need to revert the pam one and replace it with ABI duality just like we will be doing with libselinux. Helmut
mmdebstrap trixie /dev/null --variant=apt --include debian-security-support --customize-hook='sed -i -e s/trixie/sid/ "$1/etc/apt/sources.list"' --chrooted-customize-hook="apt-get update && apt-get install debian-security-support libpam0t64" debian-security-support installs a dpkg.cfg.d snipped that configures a post-invoke action which calls out to runuser. I think what it does is policy-compliant. Yes, it does affect apt as we can see above. While the consequences are not really fatal in this case, we still have an essential runuser that happens to not work briefly. I believe pam will have to be reverted and implemented as dual ABI instead. And I really expect the same to hold for libtirpc. We just haven't seen the user reports for that yet as it hasn't built. Helmut
Helmut> I believe pam will have to be reverted and implemented as
Helmut> dual ABI instead.
I'm not very comfortable with this approach.
The tentative patch did not fill me with confidence; my gut is that it
was not as robust as an approach that libraries like libc6 took, and
unfortunately I do not have enough experience with the internals of
libc6 and various multi-ABI approaches across the years to have
confidence either way.
I could use some help from someone who has approached this sort of issue
and deployed changes like this in production.
Steve and I agreed to revert the rename on IRC, effectively accepting
the ABI break because it doesn't matter for the archive.
We may look at better solutions when we have a bit of time.
We believe that the bug you reported is fixed in the latest version of
pam, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 1065017@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Sam Hartman <hartmans@debian.org> (supplier of updated pam package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Thu, 29 Feb 2024 09:46:54 -0700
Source: pam
Architecture: source
Version: 1.5.3-5
Distribution: unstable
Urgency: medium
Maintainer: Sam Hartman <hartmans@debian.org>
Changed-By: Sam Hartman <hartmans@debian.org>
Closes: 1065017
Changes:
pam (1.5.3-5) unstable; urgency=medium
.
* Revert renaming libpam0g to libpam0t64 for time_t transition: apt
sometimes removes libpam0g rather than simply letting libpam0t64
replace libpam0g (and deconfiguring libpam0g), leaving a system where
essential packages are broken, Closes: #1065017
* Since libpam0t64 is going away, we do not need dpkg-diversions for it.
* As a consequence libpam_misc has an ABI break without a package name
change. We believe nothing in the archive depends on this ABI, and at
least until we come up with a better solution this is the least bad option.
* For now remove libdb-dev so that libdb-dev can undergo time_t
transition. That means this version of pam does not include
pam_userdb, which makes pam unsuitable for release.
* Replace/break libpam0t64
Checksums-Sha1:
8c45da3949f350d00d6000ca7dbbc468b26bd30f 2238 pam_1.5.3-5.dsc
55121e5b670c27ff7f02a5cdf108bfe07decb391 139740 pam_1.5.3-5.debian.tar.xz
Checksums-Sha256:
8e0bcec3d45a68b3825be8daa4960f3318b31a1edb2db8253c8fc62f4969d3aa 2238 pam_1.5.3-5.dsc
d5fe6c66fa894c3738998a18029eafbf1d5aee121f68441b160f29f64e374c9b 139740 pam_1.5.3-5.debian.tar.xz
Files:
e9a89a9990b8c1eb43091f8d6fda033f 2238 libs optional pam_1.5.3-5.dsc
1760abb0660bc1d75024f2cf7cf3cc27 139740 libs optional pam_1.5.3-5.debian.tar.xz
-----BEGIN PGP SIGNATURE-----
iHQEARYIAB0WIQSj2jRwbAdKzGY/4uAsbEw8qDeGdAUCZeC18gAKCRAsbEw8qDeG
dHqTAQCH72iEE8pChlu0c48aebgr7879Odovevlz05+b+mBo1wD2KLaq4eBpZn8H
3As0iP7hUDzcIU9C5X6nxR+ryr41AA==
=jc3I
-----END PGP SIGNATURE-----
Do you happen to know whether there's anything needed in terms of clean up for people who had already upgraded now? Like manually doing whatever was done via the runuser? From the log it looked to me as this would have happened during removal of libpam0g, that doesn't call it (at least no directly). Cheers, Chris.
Attached is the excerpt from APT's term.log, if that helps. Cheers, Chris.
Christoph> Do you happen to know whether there's anything needed in
Christoph> terms of clean up for people who had already upgraded
Christoph> now? Like manually doing whatever was done via the
Christoph> runuser?
I think that so long as libpam0g 1.5.3-5 installs cleanly, it will be
fine.
I think that the runuser is from debian-security-support and is run on
every upgrade, so you should be good there.
I tried to make the revert work either if you didn't have libpam0t64 at
all or if you did, but we're more focused on people who never upgraded.
If you do run into breakage, we'll work with you to find a solution.
I guess right now going back isn't anyway possible yet, as e.g. util- linux and some others have already depended on the t64 package, and't I'd assume those haven't been rebuilt yet with the reversion. Means however also, that possibly more and more people (on unstable) get the libpam0t64 installed, unless they completely wait until the transition is over. Cheers, Chris.