Re: Draft spec for new dpkg "triggers" feature
Kurt Roeckx writes ("Re: Draft spec for new dpkg "triggers" feature"):
> 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.
Yes.
> 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.
Examples I can think of where pathnames aren't a good identifier for
the trigger and you don't want the trigger to be invoked automatically
include:
- where the only common directory for the triggering files contains
lots of other unrelated stuff too (eg, running ldconfig as a result
of putting things in /usr/lib)
- where the state change which ought to invoke the trigger isn't
recorded as normal disk files (eg, perhaps it's in a database of
some kind, or in a daemon which might be running)
> 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.
I think people with these advanced use cases will be able to figure it
out.
> > Concepts
> > --------
...
> > 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. [...]
See the complete explanation under `File triggers', further down.
> > 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.
I have demonstrated this in the worked example.
> > 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.
? dpkg doesn't need to know in advance. It just queues up the
activated triggers and executes them in order (as one possible
approach).
> > 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"?
The term `activated' is defined in `Concepts':
When a trigger is activated, it becomes pending for every package
which is interested in the trigger at that time. Each package has a
list of zero or more pending triggers. Repeated activation of the
same trigger has no additional effect.
> I'm also not sure why you guarantee that.
Because otherwise files might be modified without the trigger being
activated (eg, due to dpkg crashing or other strange events).
> > 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.
I haven't mentioned it before because this is the first time this is
mentioned. Also, the last. Is there a problem with saying things
only once ?
A document of this nature really needs to be read as a whole. It's a
specification, not a tutorial, I'm afraid. I'm not very good at
tutorials.
The idea is that rather than using dpkg-trigger in maintainer scripts,
it's better to put the trigger activation in the declarative triggers
control file.
> 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.
Oh, yes, so I see. Excellent.
> 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.
Because dh_scrollkeeper doesn't generate the dependency, making sure
that gnome binary packages declare some relationship to the
triggers-interested scrollkeeper would involve (at least) all of the
updated gnome packages having a Build-Depends on the new debhelper.
This would be very awkward, particularly for backports, and would also
be a considerable amount of effort.
Instead, if we do nothing (which is easy), the bad consequence is
slightly inaccurate documentation registration if the user updates the
gnome packages but not scrollkeeper. I think this is a good tradeoff.
> > 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.
Yes. It activates _all_ triggers. This is overzealous of course but
correct.
> > 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.
Because a user who does an update run one week and then the next week
says
dpkg -i something.deb
doesn't expect the system to suddenly decide to reexamine all of its
innards for no readily apparent reason!
> > 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.
Much as I'm a sceptic about Debian release dates, I don't think this
feature will be implemented in time for etch :-). How do you think
the upgrade path can be improved ?
> 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.
Nothing particularly special happens if dpkg upgrades dpkg.
Ian.
Reply to: