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

Re: Draft spec for new dpkg "triggers" feature (v2, repost)

Ian Jackson <iwj@ubuntu.com> wrote:

> Following some very cogent criticisms from Florent Rougon I posted a
> significantly version on the 2nd of March but we were all too busy
> trying to release and/or being flamed, and it seems that no-one read
> my article.  At least, no-one replied.  So herewith a repost with a
> slightly wider distribution.

I think Florent is currently VAC, but I'm not sure (oh man, I really
should know which of my teams' members are VAC.  But I'm too
concentrated on non-Debian stuff ATM).

> I'd appreciate it if particularly people who maintain large groups of
> packages which might use the triggers feature would take some time to
> read my draft specification and comment on it.  If you don't tell me
> now why it's broken then please don't blame me later after I've
> implemented it and it ate your system :-).

I'll try to answer as one of the TeX maintainers.

All in all, the specification looks quite clear to me now, it's well
written and I think it will work :-)

I think here's an error:

> At a trigger activation, the activating interested packages(s) are
> added to the activating package's list of triggers-awaited packages;
> the activating package is said to await the trigger processing.

1 s/activating interested/activated interested/ or rather

-> At a trigger activation, the activating interested packages(s) are
+> At a trigger activation, the  packages(s) interested in that trigger are
 > added to the activating package's list of triggers-awaited packages;
 > the activating package is said to await the trigger processing.

> Details - triggered package
> ---------------------------
> When one of the triggers in which a package is interested is activated
> the triggered package goes has the trigger added to its list of

s/activated$/activated,/;s/goes //

> To restore a package in state `triggers-pending' to `installed', or to
> process pending triggers of a package with both pending and awaited
> triggers, dpkg will run the postinst script:
>    postinst triggered "<trigger-name> <trigger-name> ..."

That means, $2 is a single shell word with spaces separating its
components?  Wouldn't a sequence of arguments $2 $3 ... be more

> Packages in `config-failed' or worse are never considered to have
> lists of pending triggers.
> This means that if a triggering package T awaits trigger processing by
> an interested package I, and I goes to `config-failed' or worse (eg,
> during unpack for upgrade), then when I is reconfigured (goes to
> `installed') or removed, T will no longer await processing by I, so
> that T may automatically go from `triggers-awaited' to `installed'.

This sounds to me as if there is a problem, but in fact I don't think
there is: Either T Depends on I, then when I goes to "config-failed", T
goes from triggers-awaited to "needs-configure" (however it is called).
Or else, T does not depend on I, then it's just as if I never was
installed at all, or never declared interest in the trigger.

And if I goes to "installed" from "config-failed", it will have to
execute the same code as if called with triggered, anyway.

I'm not sure how to rephrase the paragraph above.  Maybe add a short
rationale like "triggered actions are considered unnecessary if the
interested package I is not configured, and will be executed when I is
later reinstalled or configured".

> If the package is not in state `installed', `triggers-pending' or
> `triggers-awaited' then pending triggers are not accumulated.
> However, such a package (between `half-installed' and `config-failed'
> inclusive) declares some trigger interests then the triggering
> packages *will* await their trigger processing (or removal).

3 s/such/if such/

> It is not defined in what order triggers will run.

But a package which has more than one triggers pending is guaranteed to
be called *once* with all triggers, correct?  So if there's any
particular order needed between those different triggers, the postinst
can arrange for that.

> Configuration files (whether dpkg-handled conffiles or not), or any
> other files which are modifed at times other than package management,
> should not be used for file triggers; dpkg triggers are not a general
> mechanism for filesystem monitoring.

Hm.  Assume a package I which allows add-on packages T to drop snippets
into a conf.d, and is not able to parse the conf.d at runtime - instead
it does so at configure time and generates a "configuration" file in
/var/lib/I/.  Without triggers, add-on packages must invoke update-I in
their postinst, and users are advised to do the same should they change
files in conf.d.  With triggers, it would be convenient to use file
triggers for activating update-I (still advise the users).  Following
this "should not", the packages would have to use explicit triggers.

Hm, I see: Here, file triggers only work if the files in conf.d are
conffiles, not maintainer-script managed configuration files.  Is it
possible to use dpkg-trigger to explicitly activate a file trigger?  If
not, my point is moot, and this *needs* to be an explicit trigger.  If
yes, I suggest to consider to allow file triggers in /etc, and change
the paragraph above to be just a warning that dpkg does not monitor

> If there are or might be directory symlinks which result in packages
> referring to files by different names, then to be sure of activation
> all of the paths which might be included in packages should be listed.

Hm, isn't it a bug to install a file into a directory which, under that
name, is only accessible through a symlink?  If so, should the bug be
hidden by declaring interest in buggy filenames, too?

> 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.

In which case would that occur?  If a package is updated and installs
files in the triggering place which are identical to the old ones?

> Leading and trailing whitespace is trimmed and lines starting with #
> and empty lines will be ignored.

By the way, are comment lines allowed in the control file?

> Where a trigger script finds bad data provided by a triggering
> package, it should generally report to stderr the problem with the bad
> data and exit nonzero, leaving the interested package in config-failed
> and the triggering package in triggers-awaited and thus signalling the
> problem to the user.

That sounds like a very sensible solution to the concerns we raised

[transition scenario with multiple consumer packages and switchboar]
>  4. When all consumers have been updated, update the switchboard:
>     * Versioned dependency on triggers-supporting dpkg.
>     * Make the registration scripts called by producers be no-ops.
>     * Versioned Breaks, against the old (pre-step-3) consumers.
>  5. After the switchboard has been updated, producers can be updated:
>     * Remove the calls to the switchboard registration/compilation
>       functions.
>     * Change the dependency on the switchboard to a versioned one,
>       specifying the one which Breaks old consumers.  

Cannot the switchboard support both registration mechanisms until a
large enough number of producer packages have switched?  The way it is
described here, steps 4 and 5 must be coordinated (both in terms of sid
upload and testing transition), otherwise producer packages are broken.

Or am I understanding "no-ops" incorrectly?  

> For each package which has pending triggers, the status field contains
> an Triggers-Pending field which contains the space-separated names of

s/an/a/ (I'm not a native speaker, so this might be "allowed" - but it's
certainly uncommon and made me stumble while reading)

> the pending triggers, and a Triggers-Awaited field which contains the
> *package* names of the packages whose trigger processing is awaited.

Shouldn't that be "...and for each package which awaits triggers, the
status field contains a Triggers-Awaited field..."?

Regards, Frank

[1] and for /etc/texmf/updmap.d
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Reply to: