Bug#978600: Substantial increase in pseudo-Essential due to libnsl2 and libtirpc3 (and dependencies)
Package: libpam-modules
Version: 1.4.0-1
Severity: normal
X-Debbugs-Cc: josh@joshtriplett.org, debian-devel@lists.debian.org
The new pam 1.4.0 has switched pam_unix from libnsl.so.1 (in libc6) to
libnsl2 and libtirpc3, which brings those packages into the
pseudo-Essential set. This is a rather substantial increase in the
number of pseudo-Essential packages; it also pulls in libgssapi-krb5-2,
libkrb5-3, libtirpc-common, libk5crypto3, libkrb5support0, and
libkeyutils1. In addition, it adds a second dependency on libcom-err2,
which was otherwise only pulled in by e2fsprogs (Essential but generally
safely removable).
I realize it makes sense to migrate from the previous libc-provided
RPC/NIS support to the separate libraries. However, this seems likely to
make those libraries quite difficult to remove from pseudo-Essential in
the future. I'm reporting this issue as soon as I noticed it, in the
hopes that it might be possible to mitigate this before the the next
stable release, before it becomes further entrenched and migrations
become more challenging.
A few possible ideas for how to address this:
- Make pam_unix dlopen the necessary libraries, which (given sufficient
notice) would allow dropping the hard dependency. Considering that
libc6 already only Recommends the NSS modules for NIS, it seems
reasonable to follow suit here.
- Build pam_unix with and without NIS support, and make libpam-modules
Pre-Depends on a non-Essential "libpam-unix-nis | libpam-unix". (This
seems rather more invasive, but cleaner long-term.)
- Migrate libpam-modules itself towards dropping the Essential flag. PAM
no longer "fails open" in the absence of configuration or specified
modules, so this should be safe. A system without PAM still functions,
and just doesn't support PAM authentications/sessions/etc; this
doesn't seem any more unreasonable than making init non-Essential
(because chroots and some containers don't need it), or eventually
making login non-Essential (because systems without interactive
console login don't need it).
I'm happy to contribute towards any of these paths, or another path that
would avoid expanding the pseudo-Essential set.
Reply to: