[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Triggers status?



On Sun, Oct 21, 2007 at 10:04:34PM +1000, Anthony Towns wrote:
> On Fri, Oct 19, 2007 at 08:56:57AM +0000, Colin Watson wrote:
> > I would understand the delay if there were some major problem that
> > had been identified - but it all seems to work and it's a
> > substantial advance that would let me simplify a bunch of stuff, so
> > please forgive my impatience. :-)
> 
> Is there a quick intro to using the triggers implementation anywhere
> around (this list's archives, maybe)? Or would you care to give a
> quick intro?

Ian's final design is here and has a worked example:

  http://lists.debian.org/debian-dpkg/2007/04/msg00076.html

I've attached my patch for man-db to make it use triggers, minus the
changes to debian/po/*. Basically, I install a 'triggers' control file
registering interest in all the manual page directory hierarchies, and
make the postinst run mandb when run with the 'triggered' argument
(whose actions should normally be a subset of those performed on
'configure'). The rest is cleanup of older code that is now no longer
needed.

There are more complex ways to use triggers that could be used to
replace things like the update-menus lock in a smooth way by deferring
execution of a tool until the trigger is activated. See update-initramfs
in Ubuntu for an example of this:

if         $USETRIGGERS                                         \
        && test x"$DPKG_MAINTSCRIPT_PACKAGE" != x               \
        && test $# = 1                                          \
        && test x"$1" = x-u                                     \
        && dpkg-trigger --check-supported 2>/dev/null
then
        if dpkg-trigger --no-await update-initramfs; then
                echo "update-initramfs: deferring update (trigger activated)"
                exit 0
        fi
fi

But at this point Ian should field any further questions, I think; I've
only looked into this superficially because AIUI that sort of trick is
only necessary if you have a slow tool that lots of postinsts already
call and you want to stop them doing so even before you've changed all
the postinsts. I don't think we typically need this for migrating things
like debhelper - if a tool is idempotent we can often enough just make
it be triggered by changes to the relevant directory, drop the debhelper
autoscript, and let packages be rebuilt in the normal course of events.

-- 
Colin Watson                                       [cjwatson@debian.org]
Index: debian/man-db.triggers
===================================================================
--- debian/man-db.triggers	(revision 0)
+++ debian/man-db.triggers	(revision 0)
@@ -0,0 +1,9 @@
+# Several of these directories are not expected to be used in
+# policy-compliant packages, but they're listed in our default
+# /etc/manpath.config so we register interest in them for completeness.
+interest /usr/man
+interest /usr/share/man
+interest /usr/local/man
+interest /usr/local/share/man
+interest /usr/X11R6/man
+interest /opt/man
Index: debian/postinst
===================================================================
--- debian/postinst	(revision 2503)
+++ debian/postinst	(working copy)
@@ -1,5 +1,17 @@
 #!/bin/sh -e
 
+run_mandb () {
+    perl -e '@pwd = getpwnam("man"); $( = $) = $pwd[3]; $< = $> = $pwd[2];
+	     exec "/usr/bin/mandb", @ARGV' -- "$@" || true
+}
+
+if [ "$1" = triggered ]; then
+    # We don't print a status message here, as dpkg already said
+    # "Processing triggers for man-db ...".
+    run_mandb -pq
+    exit 0
+fi
+
 [ "$1" = configure ] || exit 0
 
 oldcatdir=/var/catman
@@ -71,56 +83,37 @@
 
 if dpkg --compare-versions "$2" lt 2.3.16 || \
    ([ ! -f $catdir/index.db ] && [ ! -f $catdir/index.bt ]); then
-    # If the build-database question was never asked, this is probably a
-    # fresh install, or maybe we're reconfiguring. The default is to build
-    # the database.
-    db_fget man-db/build-database seen
-    if [ "$RET" = false ]; then
-	build_db=1
-    else
-	# This should probably only fire when upgrading from less than
-	# 2.3.16, but it doesn't really matter.
-	db_get man-db/build-database
-	if [ "$RET" = true ]; then
-	    build_db=1
-	fi
-    fi
+    # All versions before 2.3.17.1-1 removed cat page hierarchies on
+    # upgrade. Since then a preinst hack means upgrades from 2.3.16 or later
+    # won't do this, but the hack is nasty enough that I don't want to
+    # extend it back beyond then. Thus, we need to build the database from
+    # scratch on old upgrades. This also covers fresh installs.
+    build_db=1
 elif dpkg --compare-versions "$2" lt 2.4.2-1; then
+    # At 2.3.17.1-5, the database version number changed to 2.3.2.
+    # At 2.4.0-1, the database version number changed to 2.4.1 and we
+    # moved from libdb2 to libdb3.
+    # At 2.4.2-1, we moved from libdb3 to libgdbm3.
+    build_db=1
+
     # Clean up old btree databases from before 2.4.2-1. They're useless now.
     find /var/cache/man -name index.bt -print0 | xargs -0r rm -f
-
-    db_get man-db/rebuild-database
-    if [ "$RET" = true ]; then
-	build_db=1
-    fi
 fi
 
 if [ $build_db -eq 1 ]; then
-    frontend=`echo "$DEBIAN_FRONTEND" | tr '[:upper:]' '[:lower:]'`
-    if [ "$frontend" = noninteractive ]; then
-	# Run in the foreground. In this case, chances are we're being run
-	# from debootstrap, which will have problems if mandb runs
-	# backgrounded for too long (bug #100616).
-	# start-stop-daemon isn't available when running from debootstrap.
-	echo "Building database of manual pages ..." >&2
-	perl -e '@pwd = getpwnam("man"); $( = $) = $pwd[3]; $< = $> = $pwd[2];
-	         exec "/usr/bin/mandb", "-cq"' || true
-    else
-	echo "Building database of manual pages in the background." >&2
-	# --pidfile /dev/null so it always starts; mandb isn't really a
-	# daemon, but we want to start it like one.
-	start-stop-daemon --start --pidfile /dev/null --background \
-			  --startas /usr/bin/mandb --oknodo --chuid man \
-			  -- --create --quiet
-    fi
+    # Chances are we're being run from debootstrap, which will have problems
+    # if mandb runs backgrounded for too long (bug #100616).
+    # start-stop-daemon isn't available when running from debootstrap.
+    echo "Building database of manual pages ..." >&2
+    run_mandb -cq
+else
+    # Otherwise, just update the database in the foreground. It's unlikely
+    # to take very long, and configuration needs to cover everything that
+    # happens when we're triggered.
+    echo "Updating database of manual pages ..." >&2
+    run_mandb -pq
 fi
 
 #DEBHELPER#
 
-# The upgrade is complete, so no more concern about this question being
-# asked twice. Clean up the flag.
-db_fset man-db/rebuild-database seen_in_2.4.2-1_upgrade false
-
-db_stop
-
 exit 0
Index: debian/changelog
===================================================================
--- debian/changelog	(revision 2504)
+++ debian/changelog	(working copy)
@@ -1,3 +1,21 @@
+man-db (2.4.4-5) UNRELEASED; urgency=low
+
+  * Add support for dpkg triggers per
+    http://lists.debian.org/debian-dpkg/2007/04/msg00076.html. There's no
+    versioned dependency on a trigger-supporting version of dpkg since this
+    is an optional feature, but now installation of any package including
+    manual pages will trigger a database rebuild at the end of the dpkg run
+    once the new dpkg is available (closes: #133917, LP: #50110).
+  * Configuration always needs to be a superset of triggering, so we always
+    need to build or update the database on upgrade. After some thought,
+    I've decided that we can live with doing this unconditionally in the
+    foreground: mandb is faster than it used to be, hardware is faster than
+    it used to be, and most builds from scratch will be due to installing
+    from scratch when relatively few manual pages are installed. Thus, I've
+    ripped out the two debconf questions dealing with this.
+
+ -- Colin Watson <cjwatson@debian.org>  Mon, 20 Aug 2007 12:26:28 +0100
+
 man-db (2.4.4-4) unstable; urgency=low
 
   * Ignore chown failures, though affected systems are buggy and should be
Index: debian/rules
===================================================================
--- debian/rules	(revision 2503)
+++ debian/rules	(working copy)
@@ -95,6 +95,7 @@
 	dh_compress
 	dh_fixperms
 	dh_installdeb
+	install -m644 debian/man-db.triggers $(dtmp)/DEBIAN/triggers
 	chown man:root $(dtmp)/var/cache/man
 	chmod 2755     $(dtmp)/var/cache/man
 	dh_shlibdeps
Index: debian/templates
===================================================================
--- debian/templates	(revision 2503)
+++ debian/templates	(working copy)
@@ -23,34 +23,3 @@
  .
  Enabling this feature may be a security risk, so it is disabled by default.
  If in doubt, you should leave it disabled.
-
-Template: man-db/build-database
-Type: boolean
-Default: true
-_Description: Should mandb build its database now?
- You do not yet have a database of manual page descriptions. Building one
- may take some time, depending on how many pages you have installed; it
- will happen in the background, possibly slowing down the installation of
- other packages.
- .
- If you do not build the database now, it will be built the next time
- /etc/cron.weekly/man-db runs (automatically or manually). Until then,
- the 'whatis' and 'apropos' commands will not be able to display any
- output.
-
-Template: man-db/rebuild-database
-Type: boolean
-Default: true
-_Description: Should mandb build its database now?
- This version of man-db is incompatible with your existing database of
- manual page descriptions, so that database needs to be rebuilt. This may
- take some time, depending on how many pages you have installed; it will
- happen in the background, possibly slowing down the installation of other
- packages.
- .
- If you do not build the database now, it will be built the next time
- /etc/cron.weekly/man-db runs (automatically or manually). Until then,
- the 'whatis' and 'apropos' commands will not be able to display any
- output.
- .
- Incompatible changes like this should happen rarely.
Index: debian/config
===================================================================
--- debian/config	(revision 2503)
+++ debian/config	(working copy)
@@ -4,37 +4,6 @@
 db_version 2.0
 
 db_input medium man-db/install-setuid || true
-
-catdir=/var/cache/man
-
-if dpkg --compare-versions "$2" lt 2.3.16 || \
-   ([ ! -f $catdir/index.db ] && [ ! -f $catdir/index.bt ]); then
-    # All versions before 2.3.17.1-1 removed cat page hierarchies on
-    # upgrade. Since then a preinst hack means upgrades from 2.3.16 or later
-    # won't do this, but the hack is nasty enough that I don't want to
-    # extend it back beyond then. Thus, we may need to build the database
-    # from scratch on old upgrades. This also covers fresh installs.
-    db_input low man-db/build-database || true
-elif dpkg --compare-versions "$2" lt 2.4.2-1; then
-    # At 2.3.17.1-5, the database version number changed to 2.3.2.
-    # At 2.4.0-1, the database version number changed to 2.4.1 and we
-    # moved from libdb2 to libdb3.
-    # At 2.4.2-1, we moved from libdb3 to libgdbm3.
-    # Set the seen flag to false in case people answered this for the
-    # previous transition, but only if it hasn't been asked already in
-    # the current upgrade.
-    db_fget man-db/rebuild-database seen_in_2.4.2-1_upgrade
-    if [ "$RET" = false ]; then
-	db_fset man-db/rebuild-database seen false
-    fi
-    db_input medium man-db/rebuild-database || true
-    rebuilding=1
-fi
-
 db_go
 
-if [ "$rebuilding" = 1 ]; then
-    db_fset man-db/rebuild-database seen_in_2.4.2-1_upgrade true
-fi
-
 exit 0

Reply to: