Trigger directives that do not put packages in triggers-awaited
Hi,
please find attached a patch that implements 2 new directives
"interest-noawait" and "activate-noawait" for the triggers control file.
They work exactly like "interest" and "activate" but the package
that activate the triggers are not put in triggers-awaited status instead
they are directly configured. Up to now, this was only possible if you
manually activated triggers with dpkg-trigger. With this patch, the
package implementing the trigger can also specify that the trigger
is not important enough to consider that the triggering package is
not configured.
My goal is to simplify the configuration process because most
triggers are purely convenience triggers and are not required by
the triggering packages... (see man-db, bash-completion, etc.)
This will also make it more likely that the trigger is really only
executed once at the end instead of multiple times because some
package had to be configured earlier.
My main problem is how to introduce this new feature. For now, I
have added "-noawait" variants but given they are the most common case, I
wonder if I shall not change the current directive to not
put the packages in triggers-awaited and instead to add new directives
"interest-await" and "activate-await" (or "interest-crucial",
"activate-crucial") with the current behaviour. That would also reduce the
number of packages to modify to get the expected benefits... very few
packages really need to put the triggering package in triggers-awaited.
What do you think?
Also any code review is welcome of course.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News â–¶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
05-19-2011, 12:09 PM
Goswin von Brederlow
Trigger directives that do not put packages in triggers-awaited
Raphael Hertzog <hertzog@debian.org> writes:
> Hi,
>
> please find attached a patch that implements 2 new directives
> "interest-noawait" and "activate-noawait" for the triggers control file.
>
> They work exactly like "interest" and "activate" but the package
> that activate the triggers are not put in triggers-awaited status instead
> they are directly configured. Up to now, this was only possible if you
> manually activated triggers with dpkg-trigger. With this patch, the
> package implementing the trigger can also specify that the trigger
> is not important enough to consider that the triggering package is
> not configured.
>
> My goal is to simplify the configuration process because most
> triggers are purely convenience triggers and are not required by
> the triggering packages... (see man-db, bash-completion, etc.)
> This will also make it more likely that the trigger is really only
> executed once at the end instead of multiple times because some
> package had to be configured earlier.
>
> My main problem is how to introduce this new feature. For now, I
> have added "-noawait" variants but given they are the most common case, I
> wonder if I shall not change the current directive to not
> put the packages in triggers-awaited and instead to add new directives
> "interest-await" and "activate-await" (or "interest-crucial",
> "activate-crucial") with the current behaviour. That would also reduce the
> number of packages to modify to get the expected benefits... very few
> packages really need to put the triggering package in triggers-awaited.
>
> What do you think?
Not all trigger are convenience triggers and switching the default to
not wait would break those. So I think that is not an option in the
short run.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 878vu2zybn.fsf@frosties.localnet">http://lists.debian.org/878vu2zybn.fsf@frosties.localnet
05-20-2011, 12:29 PM
Raphael Hertzog
Trigger directives that do not put packages in triggers-awaited
Hi,
On Thu, 19 May 2011, Goswin von Brederlow wrote:
> > What do you think?
>
> Not all trigger are convenience triggers and switching the default to
> not wait would break those. So I think that is not an option in the
> short run.
The new dpkg could break the packages that have to be upgraded to continue
to use the same semantic for the triggers, there's probably only a couple
of them (maybe libc6/ldconfig, update-initramfs?, what else?).
On the other hand, the upgrade would be somewhat awkward. The new
updated package would have to pre-depend on the new dpkg and given the
breaks it means to always follow this:
- deconfigure the broken packages
- upgrade & configure dpkg
- upgrade the broken packages
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News â–¶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110520122942.GF7064@rivendell.home.ouaza.com">ht tp://lists.debian.org/20110520122942.GF7064@rivendell.home.ouaza.com
05-20-2011, 06:36 PM
Jonathan Nieder
Trigger directives that do not put packages in triggers-awaited
Raphael Hertzog wrote:
> The new dpkg could break the packages that have to be upgraded to continue
> to use the same semantic for the triggers, there's probably only a couple
> of them (maybe libc6/ldconfig, update-initramfs?, what else?).
python support. I agree with Goswin --- better to use a new name.
--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110520183605.GF17177@elie">http://lists.debian.org/20110520183605.GF17177@elie
05-20-2011, 07:07 PM
Raphael Hertzog
Trigger directives that do not put packages in triggers-awaited
Hi,
On Fri, 20 May 2011, Jonathan Nieder wrote:
> Raphael Hertzog wrote:
>
> > The new dpkg could break the packages that have to be upgraded to continue
> > to use the same semantic for the triggers, there's probably only a couple
> > of them (maybe libc6/ldconfig, update-initramfs?, what else?).
>
> python support. I agree with Goswin --- better to use a new name.
The job to create symlinks is done in the postinst otherwise everything is
left broken for far too long. Thus I believe the trigger is not essential.
But I couldn't find any clear documentation on its role.
But of course it needs some investigation. Looking at
/usr/sbin/update-python-modules, it activates the trigger with --no-await
already... so this one is definitely not a problem.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News â–¶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110520190758.GB9188@rivendell.home.ouaza.com">ht tp://lists.debian.org/20110520190758.GB9188@rivendell.home.ouaza.com
05-20-2011, 07:52 PM
Jonathan Nieder
Trigger directives that do not put packages in triggers-awaited
Raphael Hertzog wrote:
> Looking at
> /usr/sbin/update-python-modules, it activates the trigger with --no-await
> already... so this one is definitely not a problem.
Well, that takes my worry away. You already know to be careful, so I
have no objections.
Maybe we are lucky enough to be at an early moment when no one is
relying on the detailed semantics.
--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110520195249.GA18361@elie">http://lists.debian.org/20110520195249.GA18361@elie
06-07-2011, 04:20 AM
Guillem Jover
Trigger directives that do not put packages in triggers-awaited
Hi!
On Wed, 2011-05-18 at 22:53:12 +0200, Raphael Hertzog wrote:
> please find attached a patch that implements 2 new directives
> "interest-noawait" and "activate-noawait" for the triggers control file.
>
> They work exactly like "interest" and "activate" but the package
> that activate the triggers are not put in triggers-awaited status instead
> they are directly configured. Up to now, this was only possible if you
> manually activated triggers with dpkg-trigger. With this patch, the
> package implementing the trigger can also specify that the trigger
> is not important enough to consider that the triggering package is
> not configured.
> My main problem is how to introduce this new feature. For now, I
> have added "-noawait" variants but given they are the most common case, I
> wonder if I shall not change the current directive to not
> put the packages in triggers-awaited and instead to add new directives
> "interest-await" and "activate-await" (or "interest-crucial",
> "activate-crucial") with the current behaviour. That would also reduce the
> number of packages to modify to get the expected benefits... very few
> packages really need to put the triggering package in triggers-awaited.
I don't think that's acceptable. We are not even talking about so many
packages! Changing the semantics in such a way might subtly break stuff
for the cases that actually matter (if it was the other way around I'd
not have any issue with it), there's no way to automate a switch over
or to detect when the wrong semantics are being used, and dpkg being
used beyond Debian/Ubuntu guarantees a transition involving unknown
packages to dpkg will cause external breakage (be it other distributions
or sysadmins, etc). Changing it few weeks after its introduction might
have been okish, but definitely not now, two stable Debian releases
after the fact.
> commit 8fd4917ab6eeff63f3035b8c76b90939ee9ae017
> Author: Raphaël Hertzog <hertzog@debian.org>
> Date: Sun May 15 01:39:31 2011 +0200
>
> dpkg: implement "interest-noawait" and "activate-noawait" trigger commands
>
> Those variants do not put triggering packages in triggers-awaited status
> and thus do not record the package with the corresponding pending triggers
> in the Triggers-Awaited field.
>
> This should be used for triggers which do not provide essential
> functionality when we can safely consider that the triggering packages
> are able to satisfy dependencies even if the trigger processing
> has not yet happened.
Move the scope of these two to the while loop, so it's clear their
data is not supposed to be preserved outside the loop or across
iterations. There's another instance of this.
index(3) was marked as legacy in POSIX.1-2001, and has been dropped by
POSIX.1-2008, use strchr(3) instead. There's another instance of this.
Anyway the rest I've just skimmed over, will try to take a second look
in few days. Something to consider though are downgrades when the new
directives are on the db.
regards,
guillem
--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110607042046.GA1888@gaara.hadrons.org">http://lists.debian.org/20110607042046.GA1888@gaara.hadrons.org
06-11-2011, 09:54 AM
Raphael Hertzog
Trigger directives that do not put packages in triggers-awaited
Hi Guillem,
thanks for the review.
On Tue, 07 Jun 2011, Guillem Jover wrote:
> I don't think that's acceptable. We are not even talking about so many
> packages! Changing the semantics in such a way might subtly break stuff
> for the cases that actually matter (if it was the other way around I'd
> not have any issue with it), there's no way to automate a switch over
> or to detect when the wrong semantics are being used, and dpkg being
> used beyond Debian/Ubuntu guarantees a transition involving unknown
> packages to dpkg will cause external breakage (be it other distributions
> or sysadmins, etc). Changing it few weeks after its introduction might
> have been okish, but definitely not now, two stable Debian releases
> after the fact.
Yeah, it's probably best to keep the semantics intact.
>From the questions I asked, there seems to be 5-6 packages which sort of
rely on this behaviour, it's not many but a bit too much for dpkg to
Breaks them and impose some complicated upgrade scenario.
Maybe we can consider creating "interest-await" and "interest-noawait".
And in wheezy+1 we would add a lintian warning for people still using
"interest". That way people have to consider the question at least.
Not sure if it's worth the effort though.
I have integrated all your other suggestions. The updated patch is
attached.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News â–¶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
commit 572b672b810c57a418ec38760b107a80430e4fe0
Author: Raphaël Hertzog <hertzog@debian.org>
Date: Sun May 15 01:39:31 2011 +0200
dpkg: implement "interest-noawait" and "activate-noawait" trigger commands
Those variants do not put triggering packages in triggers-awaited status
and thus do not record the package with the corresponding pending triggers
in the Triggers-Awaited field.
This should be used for triggers which do not provide essential
functionality when we can safely consider that the triggering packages
are able to satisfy dependencies even if the trigger processing
has not yet happened.
diff --git a/doc/triggers.txt b/doc/triggers.txt
index d10aab0..77668ed 100644
--- a/doc/triggers.txt
+++ b/doc/triggers.txt
@@ -46,7 +46,8 @@ will not be processed immediately when it is activated; processing is
deferred until it is convenient (as described below).
At a trigger activation, the interested packages(s) are added to the
-triggering package's list of triggers-awaited packages; the triggering
+triggering package's list of triggers-awaited packages (unless the
+trigger has been configured to not require it); the triggering
package is said to await the trigger processing.
A package which has pending triggers, or which awaits triggers, is not
diff --git a/lib/dpkg/triglib.c b/lib/dpkg/triglib.c
index 50b6012..65efcb6 100644
--- a/lib/dpkg/triglib.c
+++ b/lib/dpkg/triglib.c
@@ -253,7 +253,8 @@ struct trigkindinfo {
/* Rest are for everyone: */
void (*activate_awaiter)(struct pkginfo *pkg /* may be NULL */);
void (*activate_done)(void);
- void (*interest_change)(const char *name, struct pkginfo *pkg, int signum);
+ void (*interest_change)(const char *name, struct pkginfo *pkg, int signum,
+ enum trig_options opts);
};
diff --git a/man/deb-triggers.5 b/man/deb-triggers.5
index f869cd2..6c8df02 100644
--- a/man/deb-triggers.5
+++ b/man/deb-triggers.5
@@ -21,19 +21,32 @@ The trigger control directives currently supported are:
.I trigger-name
.PP
.in +5
+.B interest-noawait
+.I trigger-name
+.PP
+.in +5
Specifies that the package is interested in the named trigger. All
triggers in which a package is interested must be listed using this
-directive in the triggers control file.
+directive in the triggers control file. The "noawait" variant does
+not put the triggering packages in triggers-awaited state. This should
+be used when the functionality provided by the trigger is not crucial.
.PP
.in +5
.B activate
.I trigger-name
.PP
.in +5
+.B activate-noawait
+.I trigger-name
+.PP
+.in +5
Arranges that changes to this package's state will activate the
specified trigger. The trigger will be activated at the start of
the following operations: unpack, configure, remove (including for
the benefit of a conflicting package), purge and deconfigure.
+The "noawait" variant does not put the triggering packages in
+triggers-awaited state. This should be used when the functionality
+provided by the trigger is not crucial.
.PP
.in +5
If this package disappears during the unpacking of another package
@@ -45,6 +58,11 @@ versions of the package will be activated.
.PP
Unknown directives are an error which will prevent installation of the
package.
+.PP
+The "-noawait" variants are only supported by dpkg 1.16.1 or newer, and
+will lead to errors if used with an older dpkg. It is thus recommended
+to add a "Pre-Depends: dpkg (>= 1.16.1)" to any package that wish to use
+those directives.
.
.SH SEE ALSO
.BR dpkg-trigger (1),
diff --git a/src/trigproc.c b/src/trigproc.c
index 07bf346..0291ad4 100644
--- a/src/trigproc.c
+++ b/src/trigproc.c
@@ -345,7 +345,8 @@ trigproc(struct pkginfo *pkg)
/*========== Transitional global activation. ==========*/
Trigger directives that do not put packages in triggers-awaited
On Sat, 11 Jun 2011, Raphael Hertzog wrote:
> I have integrated all your other suggestions. The updated patch is
> attached.
In fact I forgot to forbid the downgrade when the new directives
are in use. The attached patch does it now.
I'll merge the new feature in a few days if there are no objections.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News â–¶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
commit d43eb815a147d93dbdb8eb34a73c20759a8373bf
Author: Raphaël Hertzog <hertzog@debian.org>
Date: Sun May 15 01:39:31 2011 +0200
dpkg: implement "interest-noawait" and "activate-noawait" trigger commands
Those variants do not put triggering packages in triggers-awaited status
and thus do not record the package with the corresponding pending triggers
in the Triggers-Awaited field.
This should be used for triggers which do not provide essential
functionality when we can safely consider that the triggering packages
are able to satisfy dependencies even if the trigger processing
has not yet happened.
diff --git a/debian/dpkg.prerm b/debian/dpkg.prerm
new file mode 100755
index 0000000..ab51157
--- /dev/null
+++ b/debian/dpkg.prerm
@@ -0,0 +1,81 @@
+#!/bin/sh -e
+# This script can be called in the following ways:
+#
+# Before the package is removed:
+# <prerm> remove
+#
+# Before an upgrade:
+# <old-prerm> upgrade <new-version>
+# if that fails:
+# <new-prerm> failed-upgrade <old-version>
+#
+#
+# Before package is deconfigured while dependency is replaced due to conflict:
+# <prerm> deconfigure in-favour <new-package> <version>
+# removing <old-package> <version>
+#
+# Before the package is replaced due to conflict:
+# <prerm> remove in-favour <new-package> <version>
+
+ensure_no_triggers_noawait()
+{
+ admindir=${DPKG_ADMINDIR:-/var/lib/dpkg}
+ pkgadmindir=$admindir/info
+
+ trig_noawait=$(find "$pkgadmindir" -name "*.triggers" -type f |
+ xargs -r grep -El "^(interest|activate)-(no)?await" |
+ sed -e 's,^.*/([^/.:]+)[^/]+$,1,')
+
+ # Abort if we cannot possibly downgrade
+ if [ -n "$trig_noawait" ]; then
+ cat <<- MSG
+ dpkg: error: You have packages using the "interest-noawait" and/or
+ "activate-noawait" trigger directives but the dpkg version that
+ you're trying to downgrade to doesn't support them. Aborting
+ downgrade.
+
+ List of affected packages:
+
+ $trig_noawait
+ MSG
+ exit 1
+ fi
+
+ bad_triggers_files=$(find "$admindir/triggers" -type f |
+ xargs -r grep -l "/noawait$" || true)
+ if [ -n "$bad_triggers_files" ]; then
+ cat <<- MSG
+ dpkg: error: Some internal trigger files unexpectedly reference
+ packages tagged with "/noawait" while their corresponding
+ infodb files doesn't seem to contain any "interest-noawait"
+ directive. Aborting the downgrade as those tags are not supported
+ by the version you're trying to downgrade to.
+
+ List of internal trigger files that are affected:
+
+ $bad_triggers_files
+ MSG
+ exit 1
+ fi
+}
+
+case "$1" in
+ upgrade)
+ # Allow the downgrade only if no package is using the
+ # (interest|activate)-noawait trigger directives
+ if dpkg --compare-versions "$2" lt 1.16.1~; then
+ ensure_no_triggers_noawait
+ fi
+ ;;
+
+ remove|failed-upgrade|deconfigure)
+ ;;
+
+ *)
+ echo "$0 called with unknown argument `$1'" 1>&2
+ exit 1
+ ;;
+esac
+
+#DEBHELPER#
+exit 0
diff --git a/doc/triggers.txt b/doc/triggers.txt
index d10aab0..77668ed 100644
--- a/doc/triggers.txt
+++ b/doc/triggers.txt
@@ -46,7 +46,8 @@ will not be processed immediately when it is activated; processing is
deferred until it is convenient (as described below).
At a trigger activation, the interested packages(s) are added to the
-triggering package's list of triggers-awaited packages; the triggering
+triggering package's list of triggers-awaited packages (unless the
+trigger has been configured to not require it); the triggering
package is said to await the trigger processing.
A package which has pending triggers, or which awaits triggers, is not
diff --git a/lib/dpkg/triglib.c b/lib/dpkg/triglib.c
index 50b6012..65efcb6 100644
--- a/lib/dpkg/triglib.c
+++ b/lib/dpkg/triglib.c
@@ -253,7 +253,8 @@ struct trigkindinfo {
/* Rest are for everyone: */
void (*activate_awaiter)(struct pkginfo *pkg /* may be NULL */);
void (*activate_done)(void);
- void (*interest_change)(const char *name, struct pkginfo *pkg, int signum);
+ void (*interest_change)(const char *name, struct pkginfo *pkg, int signum,
+ enum trig_options opts);
};
diff --git a/man/deb-triggers.5 b/man/deb-triggers.5
index f869cd2..6c8df02 100644
--- a/man/deb-triggers.5
+++ b/man/deb-triggers.5
@@ -21,19 +21,32 @@ The trigger control directives currently supported are:
.I trigger-name
.PP
.in +5
+.B interest-noawait
+.I trigger-name
+.PP
+.in +5
Specifies that the package is interested in the named trigger. All
triggers in which a package is interested must be listed using this
-directive in the triggers control file.
+directive in the triggers control file. The "noawait" variant does
+not put the triggering packages in triggers-awaited state. This should
+be used when the functionality provided by the trigger is not crucial.
.PP
.in +5
.B activate
.I trigger-name
.PP
.in +5
+.B activate-noawait
+.I trigger-name
+.PP
+.in +5
Arranges that changes to this package's state will activate the
specified trigger. The trigger will be activated at the start of
the following operations: unpack, configure, remove (including for
the benefit of a conflicting package), purge and deconfigure.
+The "noawait" variant does not put the triggering packages in
+triggers-awaited state. This should be used when the functionality
+provided by the trigger is not crucial.
.PP
.in +5
If this package disappears during the unpacking of another package
@@ -45,6 +58,11 @@ versions of the package will be activated.
.PP
Unknown directives are an error which will prevent installation of the
package.
+.PP
+The "-noawait" variants are only supported by dpkg 1.16.1 or newer, and
+will lead to errors if used with an older dpkg. It is thus recommended
+to add a "Pre-Depends: dpkg (>= 1.16.1)" to any package that wish to use
+those directives.
.
.SH SEE ALSO
.BR dpkg-trigger (1),
diff --git a/src/trigproc.c b/src/trigproc.c
index 07bf346..0291ad4 100644
--- a/src/trigproc.c
+++ b/src/trigproc.c
@@ -345,7 +345,8 @@ trigproc(struct pkginfo *pkg)
/*========== Transitional global activation. ==========*/