[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Triggers status?

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

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

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.


Attachment: signature.asc
Description: Digital signature

Reply to: