It looks like emerge @preserved-rebuild loops on rebuild of shadow and util-linux: # emerge @preserved-rebuild -pv These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] sys-apps/shadow-4.6::gentoo USE="acl cracklib nls pam (split-usr) xattr (-audit) (-selinux) (-skey)" 0 KiB [ebuild R ] sys-apps/util-linux-2.33.2::gentoo USE="cramfs ncurses nls pam readline (split-usr) suid unicode -build -caps -fdformat -kill -python (-selinux) -slang -static-libs -systemd -test -tty-helpers -udev" PYTHON_TARGETS="python3_6 (-python3_7)" 0 KiB # portageq list_preserved_libs / sys-libs/pam-1.3.1-r1 /lib64/libpam_misc.so.0.82.1 I reproduced the issue on two different systems.
How do the symlinks look? Here's what I've got locally: > # ls -l /lib64/libpam_misc.so* > lrwxrwxrwx 1 root root 16 Jan 5 20:52 /lib64/libpam_misc.so -> libpam_misc.so.0 > lrwxrwxrwx 1 root root 21 Jan 5 20:51 /lib64/libpam_misc.so.0 -> libpam_misc.so.0.82.1 > -rwxr-xr-x 1 root root 14360 Jan 5 20:52 /lib64/libpam_misc.so.0.82.1
Which version of Portage? Maybe old version, before fix for bug #692698?
Y(In reply to Arfrever Frehtes Taifersar Arahesis from comment #2) > Which version of Portage? > Maybe old version, before fix for bug #692698? If the pam upgrade happened before the portage upgrade then that do it, and we can check emerge.log to confirm.
(In reply to Zac Medico from comment #1) > How do the symlinks look? Here's what I've got locally: lrwxrwxrwx 1 root root 21 Mar 9 12:55 /lib64/libpam_misc.so.0 -> libpam_misc.so.0.82.1 -rwxr-xr-x 1 root root 14392 Mar 9 12:56 /lib64/libpam_misc.so.0.82.1 (In reply to Arfrever Frehtes Taifersar Arahesis from comment #2) > Which version of Portage? 2.3.79 (In reply to Zac Medico from comment #3) > If the pam upgrade happened before the portage upgrade then that do it, and > we can check emerge.log to confirm. # qlop -mv | grep -E '(sys-libs/pam|sys-apps/portage)' 2019-06-06T16:46:16 >>> sys-apps/portage-2.3.66-r1 2019-06-06T16:55:21 >>> sys-libs/pam-1.3.0-r2 2019-09-12T14:58:52 >>> sys-libs/pam-1.3.0-r2 2019-09-12T15:23:42 >>> sys-apps/portage-2.3.69 2020-03-09T12:51:30 >>> sys-libs/pam-1.3.1-r1 2020-03-09T13:45:36 >>> sys-apps/portage-2.3.79
(In reply to Agostino Sarubbo from comment #4) > # qlop -mv | grep -E '(sys-libs/pam|sys-apps/portage)' > 2019-06-06T16:46:16 >>> sys-apps/portage-2.3.66-r1 > 2019-06-06T16:55:21 >>> sys-libs/pam-1.3.0-r2 > 2019-09-12T14:58:52 >>> sys-libs/pam-1.3.0-r2 > 2019-09-12T15:23:42 >>> sys-apps/portage- > 2020-03-09T12:51:30 >>> sys-libs/pam-1.3.1-r1 > 2020-03-09T13:45:36 >>> sys-apps/portage-2.3.79 First version of Portage with fix for bug #692698 was 2.3.73. Your output shows that Portage 2.3.69 was used when your problem occurred. You should rebuild sys-libs/pam. *** This bug has been marked as a duplicate of bug 692698 ***
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #5) > First version of Portage with fix for bug #692698 was 2.3.73. > Your output shows that Portage 2.3.69 was used when your problem occurred. > You should rebuild sys-libs/pam. > > *** This bug has been marked as a duplicate of bug 692698 *** I guess that this problem happens when you try to update a bit ancient system. So, from the user side, what was done to avoid this issue instead of make a bugreport and get it as a dupe?
Zlogene: Would you be interested in adding !!<sys-apps/portage-2.3.73 blocker to RDEPEND of sys-libs/pam ebuilds? (Blocker should start with '!!', not single '!' which would not be effective for working around this problem.)
