Hi folks,
I'm attempting to solve bug #502140 in pam, which is marked as
release-critical for lenny. Unfortunately, the only ways to solve this all
involve fiddling around with preinsts of transitively essential packages, so
per Policy 3.5 I'm asking here about my proposed solution to add Pre-Depends
to libpam0g.
The issue is that, in order to reliably ensure that a user (such as the
admin) is not locked out by xscreensaver or xlockmore in the middle of an
upgrade, possibly breaking the very upgrade by leaving the admin unable to
get back to a pending conffile or debconf prompt, the admin must be
prompted, giving them the opportunity to disable the screensaver, before
the new libpam-modules is unpacked. (I'm ruling out the option of forcibly
disabling the screensaver as part of the upgrade; even if we can do this
reliably, I don't think it's appropriate.)
There are two ways to achieve this prompt-before-unpack: we can put the
prompt in the preinst of libpam-modules and have libpam-modules pre-depend
on debconf, or we can put the prompt in the preinst of libpam-modules using
the same style of opportunistic debconf use found in the preinst of libc6.
In practice, debconf is already be part of the transitively essential set in
Debian, as of lenny:
Package: login
Essential: yes
Version: 1:4.1.1-6
Pre-Depends: libc6 (>= 2.7-1), libpam0g (>= 0.99.7.1), libpam-runtime,
libpam-modules
Package: libpam0g
Version: 1.0.1-4
Depends: libc6 (>= 2.7-1), debconf (>= 0.5) | debconf-2.0, libpam-runtime
Therefore, I don't see that there is any disadvantage in terms of the
dependency graph to have libpam-modules Pre-Depend on debconf: because
libpam0g and libpam-modules must both already be configured prior to unpack
of the Essential login package, and libpam0g Depends on debconf, having
libpam-runtime also Pre-Depend on debconf does not add any significant new
constraints.
(Whether debconf should be transitively essential at all might be a
different question, I suppose; I didn't discuss the new dependency on
debian-devel when I added it, but so far I'm not aware of any bug reports in
Debian or Ubuntu that are traceable to this change.)
The disadvantages with the approach currently used by libc6 are:
- In theory, in some number of cases debconf will not be installed and
therefore the user will have a fallback to a tty-only prompt in English.
Current policy doesn't actually allow for this - it states that
non-debconf prompting is deprecated, without making allowances for
transitively essential packages.
- The check for whether to use debconf is not at all reliable: since
debconf itself is not Essential: yes, it may be unpacked but in an
unusable state (e.g., because of broken dependencies), so checking for
[ -f /usr/share/debconf/confmodule ] without also pre-depending does not
guarantee debconf is in a usable state, in which case the maintainer
script will fail ungracefully.
Therefore I think it's neither necessary nor appropriate for libpam-modules
to avoid a pre-dependency on debconf.
Is it ok to make libpam-modules Pre-Depends: debconf (>= 0.5) | debconf-2.0
for lenny?
Also, once that change is made, it might be appropriate to also move the
current service restart handling from the libpam0g postinst to the
libpam-modules preinst. The reason to do this is that libpam0g is not the
only library used by libpam-modules that could cause symbol skew for a
running service (the same problem has been reported in Ubuntu with
versioned symbols from glibc), so although not relevant for etch->lenny
(because the lenny libpam0g depends on the lenny libc6), in the general
case it's possible the libpam0g postinst is too early to restart services to
ensure they're usable afterwards with the new libpam-modules.
So is it ok to also make libpam-modules Pre-Depends: ${shlibs:Depends} for
lenny? For reference, the current shlibs (on i386) are:
libc6 (>= 2.7-1), libdb4.6, libpam0g (>= 0.99.7.1), libselinux1 (>= 2.0.59)
Again, these are all already transitively essential, so the main concern is
whether further restricting the unpack order will cause any dependency
loops, which I don't believe it will.
If y'all agree to this change, I can knock out the implementation within a
couple of days and get another RC bug off the list - then I just have to
accept the beatings from Christian for the implied addition of a new debconf
template this late in the lenny freeze... :)
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
