Re: Draft spec for new dpkg "triggers" feature
On Tue, Jan 30, 2007 at 05:08:24PM +0000, Ian Jackson wrote:
> For some time the idea of having some kind of event queue notification
> mechanism in dpkg has been floating about. For example, it would be
> used to avoid running scrollkeeper-update dozens of times during an
> upgrade and could simplify the emacs addon registration. Wichert and
> I even had a good design conversation in a taxi some years ago but we
> failed to make proper notes and write it up.
I've been thinking what kind of things this would be useful for. I
think we have lots of cases where we have a directory where packages put
a file into, and then run some update script.
I guess you could do those triggers both by name and by directory,
but by directory seems more logical. I currently can't come up with
examples where you want/need to trigger it by some name.
I think it's good that it seems to be defined in a manner that general,
but some more examples of the other use cases would be great.
> Concepts
> --------
>
> Each trigger is named, and at any time zero or more packages may be
> interested in it.
>
> We currently envisage three kinds of triggers:
> * Explicit triggers. These can be activated by any program
> by running dpkg-trigger (at any time, but ideally from a maintainer
> script).
> * File triggers. These are activated automatically by dpkg
> when a matching file is installed, upgraded or removed as part
> of a package. They may also be explicitly activated by running
> dpkg-trigger.
> * Special triggers, which activate magic code in dpkg itself.
> Currently none of these are defined.
>
> Trigger names contain only printing 7-bit ascii characters (no
> whitespace). Each trigger kind has a distinct subset of the trigger
> name space so that the kind can be determined from the name. After we
> run out of straightforward syntaxes, we will use <kind>:<details>.
This is a little confusing. In the example you mention
"interest /usr/share/omf". You defined that as:
interest <trigger-name>
So the directory seems to be the same as the trigger name. I'm guessing
that if a trigger name starts with a / it's a file trigger, and that
that shouldn't be allowed in other trigger names.
I'm wondering how you're going to see the difference between explicit
and special triggers.
> If the package is not in state `installed' then it not interested,
> even if it declares some trigger interests; when a package is
> deconfigured for any reason, its list of pending triggers is reset.
So, in your example, if none of the package shipping thoe omf files
depend on scrollkeeper anymore, it could that it's never triggered.
So it should during configure probaly do what it normally does during
the trigger. Sort of trigger itself. It might already be doing that,
but it's probably not a bad thing to document that.
> It is not defined in what order triggers will run. dpkg will make
> some effort to minimise redundant work in the case where many packages
> have postinst trigger processing activating another package's triggers
> (for example, by processing triggers in fifo order during a single
> dpkg run).
This sounds nice, but I wonder how you're going to know in advance which
triggers the postinst will trigger.
Afaics, this is only a problem the explicit triggers, and not with the
file triggers.
> A file trigger is guaranteed to be activated before the file in
> question is modified by dpkg; on the other hand, a file trigger might
> be activated even though no file was actually modified.
I'm not really sure what you're trying to say here. What do you mean by
"activated"?
I'm also not sure why you guarantee that.
> The trigger control directives currently supported are:
>
[...]
> activate <trigger-name>
>
> Arranges that any change of the package's state will activate the
> specified trigger. The trigger will be activated just before the
> package state changes.
You don't seem to have mentioned this before. I have to wonder why
this is useful.
> This not 100% in keeping with the full transition plan defined below:
> if a new gnome package is used with an old scrollkeeper, there is some
> possibility that the help will not properly be available. Likewise,
> if a new gnome package is built with an old debhelper, its postinst
> will call scrollkeeper-update but no dependency on scrollkeeper will
> be present.
>
> However, dh_scrollkeeper doesn't generate the scrollkeeper dependency
> in the control file, which makes it excessively hard to get the
> dependency up to date. (This was a mistake in the design of
> dh_scrollkeeper.) The bad consequences of these missing dependencies
> are less severe than the contortions which would be required to deal
> with the problem.
The postinst that dh_scrollkeeper generates also checks for
scrollkeeper-update before using it. So it doesn't depend on
scrollkeeper. I think this is good, so that people that do not want
scrollkeeper can actually get rid of it. This also means that it
should perfectly work for your new gnome package / old debhelper case.
I think a Recommends scrollkeeper would be better, but with and without
the triggers. But I think for a proper upgrade you're either going to
need to depend on a version of scrollkeeper that has the trigger, or use
conflict/break.
Anyway, there are other and probably better ways to find which packages
need to be updated.
> TRANSITION PLAN
> ===============
>
>
> >From old dpkg to new dpkg
> -------------------------
>
> The first time a trigger-supporting dpkg is run on any system, it will
> activate all triggers in which anyone is interested, immediately.
How does it know which triggers to activate? I assume that active means
put package that have an interest in it in triggered state.
> These trigger activations will not be processed in the same dpkg run,
> to avoid unexpectedly processing triggers while attempting an
> unrelated operation. dpkg --configure --pending (and not other dpkg
> operations) will run the triggers, and the dpkg postinst will warn the
> user about the need to run it.
I'm guessing I'm missing something because I don't see why it needs to be
delayed.
> To use this correctly:
> * Packages which are interested in triggers, or which want to
> explicitly activate triggers, should Depend on the
> triggers-supporting version of dpkg.
So you basicy want to have this in lenny, and etch's dpkg shouldn't
support this? I think you're making the upgrade path harder than it
should be.
I'm also not sure what happens now if dpkg uprades dpkg, which might
explain why I don't understand some of the above things.
Kurt
Reply to: