Re: Triggers status?
Anthony Towns writes ("Re: Triggers status?"):
> [description of AJ's understanding of triggers]
I think this is basically correct. I'll answer your questions in more
detail below.
> AFAICS, this means that if you have three packages:
> I - implements trigger foo
> A - activates trigger foo
> B - depends: A, activates trigger foo in postinst
> then dpkg will:
> unpack I, A, B
> configure I, I = installed
> configure A, activate foo, A = trigger-await, I = trigger-pending
> can't configure B because A doesn't satisfy Depends
> I.postinst triggered foo, A = installed, I = installed
> configure B, activate foo, B = trigger-await, I = trigger-pending
> I.postinst triggered foo, B = installed, I = installed
> done
Yes. An example of this situation was provided some time ago by the
TeX package maintainers, who require this semantic. My first draft
did this differently but it was pointed out that this didn't satisfy
their requirements.
> But if B had activated foo by just installing a file or just an entry in
> its triggers control file, it would have been:
> unpack I, A, B
> configure I, I = installed
> configure A, activate foo, A = trigger-await, I = trigger-pending
> configure B, activate foo, A,B = trigger-await, I = trigger-pending
> I.postinst triggered foo, A,B,I = installed
> done
Yes, for a file trigger. But entries in the triggers control file
cause trigger activation even when the triggering package is
configured, so that is the case above.
> If you have dependency chains of packages with postinsts and a common
> trigger, it seems like you devolve to the current case of running the
> triggered code once per-package, which seems a shame.
Yes, but some packages need this semantic. This behaviour can be
avoided by a file trigger, by triggering explicitly in the preinst, by
indirecting the trigger activation through an intermediate package, or
by other means.
> Maybe invoking the trigger from B's preinst could work as a hack, but
> I don't see any indication you could rely on a trigger activated in
> preinst not being run prior to unpacking.
It might be run `prior to' unpacking. But it won't be run _between_
the preinst and the actual unpack. The whole point of triggers is to
defer things; they're not hooks which interrupt the processing of
other packages. So either the unpack is completed and then the
trigger processed later, or the unpack is not completed successfully
and then the next attempt to unpack (or remove) will reinvoke the
a maintainer script which can reactivate the trigger.
> In any event, that means that conceptually, triggers are the very last
> part of a package's postinst.
Yes.
> Other files in that directory are named after explicit triggers directly,
> and are a list of interested packages, one perline. Explicit triggers
> follow the package name convention so are limited to lower case letters,
> digits, plus, minus and dot. Presumably this is hardcoded to prevent
> conflicts with the File/Deferred/Lock files in the same directoy.
No, the restriction on explicit trigger names is to distinguish them
from file triggers and any future new kinds of exciting trigger.
It doesn't flow from the implementation; if I had wanted to support
explicit triggers with uppercase in their names I could trivially have
used a prefix on the front of the filename.
> So the worst I could say about this is:
>
> a) there's no way of indicating triggers are optional to an
> activating package
You mean from the point of view of dependencies, as you described
above, I take it. I think in fact this can be done with the existing
setup by appropriate use of the facilities now available.
Do you have a concrete example ?
> b) "interested" seems a confusing way to describe the packages
> that end up doing all the actual work to implement a trigger
It does at least convey the fact that there may be several interested
packages, and I intended it to convey the loose coupling. I never was
very good at names. It's a shame you didn't suggest a better name
earlier :-).
> this is a +1 from me for speedy inclusion.
Thanks.
I would like to say that I think now is too late for constructive
criticism of the specification. This spec was discussed and refined
extensively here over a number of months; a heads-up was posted to
debian-devel a couple of times as well.
I then went and implemented what had been agreed. I found it
necessary to make a minor semantic change with the benefit of
experience (to make it possible for a package to trigger itself), and
of course to change some of the originally planned implementation
details.
So I think what I have now implemented is what was discussed here and
everyone who wanted to comment had plenty of warning and time. If you
have comments based on purely the spec then I think you should have
made them earlier.
If you have comments based on experience with trying to use triggers
in your packages I'd be interested to hear about that of course.
And I am of course happy to answer questions about why things were
done a particular way.
Ian.
Reply to: