Ian Jackson <[EMAIL PROTECTED]> 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)
