On Sun, Oct 21, 2007 at 02:13:59PM +0100, Colin Watson wrote: > > Is there a quick intro to using the triggers implementation anywhere > > around (this list's archives, maybe)? Or would you care to give a > > quick intro? > Ian's final design is here and has a worked example: > http://lists.debian.org/debian-dpkg/2007/04/msg00076.html > I've attached my patch for man-db to make it use triggers, [...] Heh, neither of which are really terribly /quick/... > minus the > changes to debian/po/*. Basically, I install a 'triggers' control file > registering interest in all the manual page directory hierarchies, and > make the postinst run mandb when run with the 'triggered' argument So, two sorts of packages -- ones that activate a trigger, and ones that implement it (aka are interested in it). Packages activate a trigger by (a) just installing a file, no postinst needed, or (b) invoking dpkg-trigger from a maintainer script, or (c) having an "activate" entry in the triggers control file. AFAICT this puts the package into a "triggers-awaited" state and means it doesn't satisfy Depends:. When the trigger is eventually undertaken by the implementing package, it'll switch from triggers-awaited to installed. Packages implement a trigger by having an "interest" entry in the triggers control file, and having their postinst implement the trigger when invoked with "triggered" as the first argument, and all the trigger names, separated by spaces, as the second argument. When a trigger is activated, the implementing package will go from the "installed" state to "trigger-pending", but continue to satisfy Depends:. 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 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 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. I would have thought the common case would have been for B's postinst to be able to be run prior to the trigger happening for its dependency, A, but afaics there's no way that A can indicate that -- basically to say "this trigger is relevant, but if it fails, I don't break at all", so that A can be installed immediately and stay that way, even if the I package later ends up in config-failed if the trigger doesn't end up working. 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. In any event, that means that conceptually, triggers are the very last part of a package's postinst. dpkg uses the /var/lib/dpkg/triggers/ directory to manage state, with File - being a list of file/dir triggers, of the form "$path $pkg\n" Deferred - is a queue for trigger activations that haven't yet been put in /var/lib/dpkg/status Lock - is a lockfile 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. So the worst I could say about this is: a) there's no way of indicating triggers are optional to an activating package b) "interested" seems a confusing way to describe the packages that end up doing all the actual work to implement a trigger Obviously I haven't looked at the code, but I presume the worst thing there would be the indentation choices... :-P (a) could be fixed in the future just by changing the code, so doesn't seem a major issue. (b) is just an explanation issue. If the design is right, then it's just a matter of fixing any problems with the code, which can also happen over time afaics, so given this: a) speeds up installations/upgrades significantly by not duplicating work; and b) simplifies packaging by removing lots and lots of postinst code this is a +1 from me for speedy inclusion. I've done some very limited dpkg hacking in the past, so I suppose I could do a quick code review if none of the dpkg team have time in the near future. Cheers, aj
Attachment:
signature.asc
Description: Digital signature