[Bug 1372673] Re: excessive debconf use when triggered

Tue Sep 23 12:56:17 UTC 2014

** 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: (unassigned) => Colin Watson (cjwatson)

** Changed in: man-db (Ubuntu Lucid)
     Assignee: (unassigned) => Colin Watson (cjwatson)

** Changed in: man-db (Ubuntu Trusty)
     Assignee: (unassigned) => Colin Watson (cjwatson)

** Changed in: man-db (Ubuntu Precise)
     Assignee: (unassigned) => Colin Watson (cjwatson)

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to man-db in Ubuntu.
https://bugs.launchpad.net/bugs/1372673

Title:
  excessive debconf use when triggered

Status in “man-db” package in Ubuntu:
  Fix Committed
Status in “man-db” source package in Lucid:
  In Progress
Status in “man-db” source package in Precise:
  In Progress
Status in “man-db” source package in Trusty:
  In Progress
Status in “man-db” package in Debian:
  Fix Released

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/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')
  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  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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/man-db/+bug/1372673/+subscriptions