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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
