I am aware of #1140029 and the assertion that this is a libpam0g problem. See
https://lists.debian.org/debian-devel/2023/09/msg00183.html for context.                                                                                                                                Regardless of whether this is changed in libpam0g, the removal of /etc/pam.d
conf files must be reverted in login because other programs (e.g., i3lock)
depend on /etc/pam.d/login and make it currently impossible to unlock the
screen. The change cannot be reintroduced until there is a version of libpam0g
that can be pre-depended to avoid breaking, and potentially Breaks:
relationships added. There may be a seperate argument over whether programs
relying on /etc/pam.d/login or other util-linux-provided conf files should have
an explicit dependency.

Control: block -1 by 1140029

That's from 2023, and apparently the stance was changed, given
dh_installpam now defaults to /usr/lib/pam.d. If that was not the
case, I doubt dh_installpam would have changed the install location.

I expect more packages will switch to debhelper compat 14 soon, thus
I expect the PAM maintainers to react soon. Otherwise the breakage
will be even more wide-spread. Then login and u-l can Pre-Depend on
the fixed libpam0g.

i3lock can be trivially fixed by including the Debian-recommended
common-* files, which continue to reside in /etc/pam.d and thus can
be found by PAM.

In the meantime login/u-l should not migrate to testing, indeed.

Best,
Chris

* Chris Hofstaedtler <zeha@debian.org> [260615 17:33]:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1140068#10

br,c

u-l 2.42.1-6 in accordance with debhelper installs the files again
in /etc/pam.d.