Re: Draft spec for new dpkg "triggers" feature (v2, repost)
Frank Küster writes ("Re: Draft spec for new dpkg "triggers" feature (v2, repost)"):
> Ian Jackson <iwj@ubuntu.com> wrote:
> > 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.
Thanks.
> All in all, the specification looks quite clear to me now, it's well
> written and I think it will work :-)
Good :-).
> -> At a trigger activation, the activating interested packages(s) are
> +> At a trigger activation, the packages(s) interested in that trigger are
Indeed. I have done this:
+ At a trigger activation, the interested packages(s) are
since it seems unnecessary to say what they're interested in as it's
obviously.
> > postinst triggered "<trigger-name> <trigger-name> ..."
>
> That means, $2 is a single shell word with spaces separating its
> components?
Yes.
> Wouldn't a sequence of arguments $2 $3 ... be more
> convenient?
Not significantly, since dealing with a single word with spaces in is
easy in sh. The reason I do it like that is that it leaves more room
for other stuff to be passed in the arguments later.
> > 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).
No, because the deconfiguration of I does not cause deconfiguration of
T. Dependencies are not transitively followed during deconfiguration.
This is deliberate, as full maintenance of the invariant you are
assuming (ie T -Depends-> I && not(installed(I)) => not(installed(T)))
would often involve massive deconfiguration runs for simple updates
(eg, consider a libc security update!)
The reason it's not supposed to be a problem is that I's postinst is
supposed to deal with any dropped triggers when T is reconfigured.
> 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".
That's an excellent sentence and I have cribbed it. Thanks.
> > 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.
In my mind I had the idea that the postinst would be called once for
all of the triggers. However, I don't want to write this guarantee
because it isn't true in the presence of other packages: other
packages might cause further trigger activations, so that a single
package postinst might be called for triggers more than once.
If processing of trigger A undoes the processing effects for a trigger
B, then when the postinst is called for A, the actions for A and B
should be executed in that order. Eg,
case " $3 " in
*" a "*) process-for-a ;;
esac
case " $3 " in
*" a "*|*" b "*) process-for-b ;;
esac
or some such.
I've just noticed that I appear to have posted that syntax here but
not mentioned it in the spec document; I've rectified that omission
now.
> > 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).
Right. I've changed this to:
Configuration files (whether dpkg-handled conffiles or not), or any
other files which are modifed at times other than package management,
should not rely file triggers detecting all modifications; dpkg
triggers are not a general mechanism for filesystem monitoring.
> Following
> this "should not", the packages would have to use explicit triggers.
That would be daft and isn't what I meant.
> 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...
Yes, you can use dpkg-trigger for a file trigger. As you can infer
from my caveat:
NB that in the case of a file trigger the name of the trigger is
needed, not the name of a file which would match the trigger.
> > 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?
No, such arrangements often happen due to filesystem layout
transitions and of course the sysadmin may use symlinks to reorganise
things 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?
That's an example, yes. Or perhaps dpkg got halfway through
considering some operation and then rewound it, in which case I don't
promise that the triggers will be `deactivated'.
> > 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?
Err, that's what that sentence says. Lines starting with # will be
ignored ie they are comments.
> [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?
Err, no, steps 4 and 5 can happen in that order. After step 4 we have
precisely the switchboard which supports both kinds of producers: it
will always detect the files because of the file trigger (done
automatically by dpkg without the producer packages having to do
anything) and it won't break on the old un-updated producers because
it provides the noop update script.
If there are producers which synthesize the files, or some other
reason why the triggers need to be activated explicitly, things get
more complicated.
> > 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..."?
Yes, except that I stupidly wrote `status field' when I meant `status
file'. I can see that I need to proofread this text again, with all
the comments from everyone :-).
Regards,
Ian.
Reply to: