Hi! On Mon, 2026-06-15 at 23:19:35 +0200, Chris Hofstaedtler wrote: > On Mon, Jun 15, 2026 at 12:57:03PM -0600, Sam Hartman wrote: > > control: tags -1 patch > > > > >>>>> "Chris" == Chris Hofstaedtler <[email protected]> writes: > > Chris> So what you are saying is that libpam0g's code for "include" > > Chris> is broken, or at least inconsistent with the support for > > Chris> /usr/lib/pam.d. > > > > I don't think pam in Debian cliams to (or does) support /usr/lib/pam.d. > > So, I think that moving files there is broken. > > Well, dh_installpam in debhelper compat 14 does now install the > files into /usr/lib/pam.d. It's not that util-linux actively chose > to do this.
But this behavior was "accepted" when the packaging for util-linux got bumped to compat level 14. So while I think the problem is with debhelper, part of the point for the compat levels is so that maintainers can change behavior and check whether that breaks those packages at their convenience. Given the kind of regression this has caused, I think this should be reverted in util-linux now, either with a global compat downgrade or perhaps a targeted one for just the dh_installpam invocation (via DH_COMPAT for example). > Without the patch, /usr/lib/pam.d DOES work; except as a source for > include files. So, Debian's PAM does half-support it, courtesy of > upstream. Even if there's some partial support, this is still a severe regression. > > See https://lists.debian.org/[email protected] > > for my rationale for not supporting /usr/lib/pam.d > > >From a really quick look at PAM earlier today, it seems PAM supports > libeconf. Per my understanding of things, libeconf is what provides > the support for "systemd-style" configs. Not sure how the > integration looks like. > > If you don't want Debian to support /usr/lib/pam.d, then I think you > should at least revert all upstream commits that try to support > /usr/lib/pam.d; get dh_installpam to put the files into /etc/pam.d, > and get these packages fixed: > > account-utils: /usr/lib/pam.d/{passwd,pwupd-chfn,pwupd-chsh,pwupd-passwd} > libkscreenlocker6: /usr/lib/pam.d/{kde,kde-fingerprint,kde-smartcard} > polkitd: /usr/lib/pam.d/polkit-1 > systemd: /usr/lib/pam.d/systemd-user > util-linux: /usr/lib/pam.d/{login,remote,runuser,runuser-l,su,su-l} > > A lintian error would also be in order. I don't think it's fair to put pressure on Sam / the pam maintainer, for something that had been clearly stated previously was not supported. IMO, util-linux should revert the specific breaking change, and this report should be reassigned to debhelper. Thanks, Guillem
