Control: severity -1 serious On Thu, Feb 29, 2024 at 02:36:12AM +0100, Christoph Anton Mitterer wrote: > 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) ...
>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
