package: debhelper severity: critical version: 14.0.0 justification: Breaks unrelated packages
In debhelper compatibility version 14, Debhelper starts installing pam files in /usr/lib/pam.d. This change was made with no consultation with the pam maintainer. I checked my mail for messages containing both pam and debhelper and didn't find any relevant messages. This breaks things; see for example https://bugs.ebian.org/1140029 and https://bugs.debian.org/1140083 More over, I announced in 2023 that Debian would not be supporting /usr/lib/pam.d: https://lists.debian.org/[email protected] In addition, the Debian PAM mini-policy [/usr/share/doc/libpam0g/Debian-PAM-MiniPolicy.gz] requires that each pam application have a file in /etc/pam.d: > Each application that uses PAM also must contain a file in /etc/pam.d/. > This file specifies which PAM modules will be used for the common PAM >functions in that application. It's not clear what formal force the Debian PAM MiniPolicy has, but in general I do think we've allowed packages (and their maintainers) that provide a service like pam to have significant influence over how that service is consumed.. I appreciate that my handling of this situation has not been great: * The Debian PAM man pages do mention /usr/lib/pam.d * there is partial /usr/lib/pam.d support I thought it was tied to the vendordri support, but apparently not completely. . What I'm going to do to make the situation better for the next few days: I will at least for now fix pam_include to support /usr/lib/pam.d. I'm going to hold a serious bug open on pam and I'm not at all convinced I will let that change into testing. I don't think I can completely remove /usr/lib/pam.d support in forky without doing a lot more research, but I do think I can log an error when a config file is found there instead of /etc/pam.d.
signature.asc
Description: PGP signature
