excessive debconf use when triggered
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
man-db (Debian) |
Fix Released
|
Unknown
|
|||
man-db (Ubuntu) |
Fix Released
|
High
|
Colin Watson | ||
Lucid |
Fix Released
|
High
|
Colin Watson | ||
Precise |
Fix Released
|
High
|
Colin Watson | ||
Trusty |
Fix Released
|
High
|
Colin Watson |
Bug Description
SRU justification:
[Impact]
We see rather frequent hard-to-debug upgrade failures that amount to man-db's trigger failing in some way that has nothing to do with the mandb program itself, but rather in some kind of communication with the package management frontend. Almost all the open bugs on Ubuntu man-db come down to this in one way or another. The root cause is, I believe, that it is not really safe to use debconf from a dpkg trigger: while debconf itself behaves as if it were Essential, the debconf protocol is often mediated by various frontends with less stringent practices. It would certainly be a good idea to get man-db's trigger out of the loop here, as dpkg tends to run it at the end of an unpack phase when large numbers of packages are unconfigured, which is pretty much the worst case for having this work properly.
In the past I've tried to investigate why debconf fails in these situations. I've come to believe this is a wild goose chase, and that the common case of ordinary postinsts sourcing the debconf confmodule is much less likely to be a problem due to the nature of unpack/configure sequencing; I admit that I don't have proof of this, but having one fewer script using debconf is surely not going to make things worse, and since lots of unpack runs pull the man-db trigger it seems likely to improve things substantially.
The man-db trigger reads a single value from debconf to tell it whether to automatically update the manual page database (used by apropos and whatis). This is in an agreed location in debconf so that such things as package builders can save time by suppressing the database update. There is, however, no reason to read this value every time the trigger is activated; we can just cache it under /var/lib/man-db/ when man-db is configured and then do a much simpler file-level test in the trigger. I should have thought of this years ago.
To have the maximum benefit for upgraders, we should do what we can to ensure that they have a fixed version of man-db installed before the upgrade. I'd therefore like to apply this fix to all currently-supported releases.
[Test Case]
I don't have a reliable reproduction scenario, but I have two suggestions, which are in the sort of general vein of unit testing and integration testing respectively:
* Install the new version of man-db and check that it causes /var/lib/
* After installing the new version of man-db, upgrade to the next supported or development series using the upgrade tool of your choice.
[Regression Potential]
Installing packages that contain manual pages and running system upgrades should exercise this pretty thoroughly. Since in general this weakens the constraints on achieving successful upgrades, the main thing to watch out for would just be things like inverted logic that might cause the database not to be updated when it should be or vice versa.
Original report follows, imported from Debian bug http://
Package: man-db
Version: 2.5.7-2
Severity: wishlist
I noticed that man-db starts debconf when triggered. Given how
often triggers run, I think that should be optimised. Ie, move
the $1 = triggered test above the confmodule sourcing.
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-3-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=
Shell: /bin/sh linked to /bin/dash
Versions of packages man-db depends on:
ii bsdmainutils 8.0.10 collection of more utilities from
ii debconf [debconf-2.0] 1.5.32 Debian configuration management sy
ii dpkg 1.15.7.1 Debian package management system
ii groff-base 1.20.1-9 GNU troff text-formatting system (
ii libc6 2.10.2-6 Embedded GNU C Library: Shared lib
ii libgdbm3 1.8.3-9 GNU dbm database routines (runtime
ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime
man-db recommends no packages.
Versions of packages man-db suggests:
ii 5.0.386.
ii 2.30.2-1 Intuitive GNOME web browser
pn <none> (no description available)
ii 3.5.9-2 Web browser based on Firefox
ii 436-1 pager program similar to more
ii 0.5.2-4 WWW browsable pager with excellent
-- debconf information excluded
--
see shy jo
description: | updated |
Changed in man-db (Debian): | |
importance: | Undecided → Unknown |
status: | New → Fix Released |
Changed in man-db (Ubuntu Lucid): | |
importance: | Undecided → High |
Changed in man-db (Ubuntu): | |
importance: | Undecided → High |
Changed in man-db (Ubuntu Precise): | |
importance: | Undecided → High |
Changed in man-db (Ubuntu Trusty): | |
importance: | Undecided → High |
Changed in man-db (Ubuntu Precise): | |
status: | New → In Progress |
Changed in man-db (Ubuntu): | |
status: | New → Fix Committed |
Changed in man-db (Ubuntu Lucid): | |
status: | New → In Progress |
Changed in man-db (Ubuntu Trusty): | |
status: | New → In Progress |
Changed in man-db (Ubuntu): | |
assignee: | nobody → Colin Watson (cjwatson) |
Changed in man-db (Ubuntu Lucid): | |
assignee: | nobody → Colin Watson (cjwatson) |
Changed in man-db (Ubuntu Trusty): | |
assignee: | nobody → Colin Watson (cjwatson) |
Changed in man-db (Ubuntu Precise): | |
assignee: | nobody → Colin Watson (cjwatson) |
Hi Colin!
Does this fix cover bug #1364642 and its duplicates too?