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
convenient?
> 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
/etc...
> 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
earlier.
[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: