** Description changed:
- Imported from Debian bug http://bugs.debian.org/579075:
+ 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/man-db/auto-update to exist if and only if the debconf value for
man-db/auto-update is true, and in turn that this still causes the database to
be updated or not updated respectively when installing a package containing a
manual page.
+ * 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://bugs.debian.org/579075:
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')
+ 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=en_US.UTF-8 (charmap=UTF-8)
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 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.0~svn20100423r45407-0u Chromium browser
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
** Also affects: man-db (Ubuntu Trusty)
Importance: Undecided
Status: New
** Also affects: man-db (Ubuntu Lucid)
Importance: Undecided
Status: New
** Also affects: man-db (Ubuntu Precise)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1372673
Title:
excessive debconf use when triggered
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/man-db/+bug/1372673/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
