Re: Draft spec for new dpkg "triggers" feature (v2, repost)
Andreas Barth writes:
> Ian Jackson (iwj@ubuntu.com) [070410 20:39]:
> > 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.
>
> Why should it be activated *before* the file is modified? For the cases
> where I think about it might be a good thing if it is activated after
> the fact (so that e.g. the list of available fonts can be changed).
Activation has to precede modification because otherwise the system
goes through a forbidden state: modified but not activiated. These
should be avoided; dpkg is not supposed to ever leave the system in an
horrid state even if it crashes unexpectedly.
I'm not sure I understand your example.
> Please also ignore anything after "#", so that one can write
> interest foo # necessary for ...
> interest bar # drop after release of Lenny
OK.
> > dpkg --configure --pending
> > dpkg --triggers
>
> why not require --pending here as well? (just for "being the same")
I think I should permit --pending but not require it.
> I don't think it is a good idea to describe some package this way
It does seem to be causing controversy. I've toned it down.
> btw, what is the problem if dh_scrollkeeper does something like this:
> if [ $1 -eq configure ]; then
> if ! dpkg --assert-triggers ; then
> # run update as it used to be
> fi
> fi
What you really want to know is `is this trigger going to be run any
time soon', that's difficult to know. In particular, you don't know
whether dpkg is going to be upgraded to a triggers-supporting version,
or whether a triggers-supporting dpkg is deferring new trigger
processing according to the transitional arrangements.
I'm working on the assumption that usually the consequences of lack of
trigger processing in some corner upgrade cases are less bad than the
consequences of excessive trigger processing or excessive fragility.
> Alternatively, one could execute dpkg --compare-versions $(dpkg -l | cut
> -f 1 -d ' ') -lt .., but I think that would be more crappy. (Or even
> worse, use -d /var/lib/...)
I would like a design that didn't need anything along any of these
lines and I think I have one.
> > These trigger activations will not be processed in the same dpkg run,
> > to avoid unexpectedly processing triggers while attempting an
> > unrelated operation. dpkg --configure --pending (and not other dpkg
> > operations) will run the triggers, and the dpkg postinst will warn the
> > user about the need to run it.
>
> Please supress the warnings in case there are no interessts registered.
Of course.
> > To use this correctly:
> > * Update instructions and tools should arrange to run
> > dpkg --configure --pending
> > after the install; this will process the pending triggers.
>
> I don't think this is an acceptable approache for stable releases - we
> need to consider something else for that. (And, BTW, dpkg --triggers
> --pending should do the same IMHO.)
Err, you don't think it's acceptable that stable releases upgrade
tools should arrange to run --configure --pending ? Or do you mean
that it wouldn't be acceptable to do this only via documentation (in
which case I agree with you) ?
> > * Declare an interest in the trigger.
> > * Declare a versioned dependency on a triggers-supporting dpkg.
> > * In the postinst, arrange for the new `trigger' invocation to run
> > update-consumer. (The consumer package's postinst will alread
> > run update-consumer during configuration, and this should be
> > retained.)
>
> I think this makes upgrade cycles unnecessary complex. How about "change
> the name of update-consomer, and put a transition script at the old
> place which checks if it is run in an trigger-aware environment, and if
> not, run the real update-consumer"?
Do you think it's too difficult to ask that the package processing
tools are updated early ? It seems to me to be an obvious requirement
for upgrades.
I don't think adding complexity in all of the consumer packages is the
best way forward. It is IMO better in this case to add a dependency
(which adds a not-unreasonable constraint to upgrades) than to add
machinery to deal with both cases.
> > The activation of a trigger does not record details of the activating
> > event. For example, file triggers do not inform the package of the
> > filename. In the future this might be added as an additional feature,
> > but there are some problems with this.
>
> How about having the names print out by some "special"
> dpkg-triggers-call (once this is implemented of course)?
It might be possible but I definitely don't want to go there now.
Re error handling:
> > Alternatively, in some situations it may be more desirable to allow
> > the interested package to be configured even though it can only
> > provide partial service. In this case clear information will have to
> > be given in appropriate places about the missing functionality, and a
> > record should be made of the cause of the errors. However, this
> > option is not normally recommended unless the coupling between the
> > interested and triggering package is particularly loose.
>
> Wouldn't it be better to allow a package to "kick back" a dependend
> package into config-failed? (So, if A triggers package B, and B notices
> A did something *very* wrong, B can make A going to config-failed, and
> configure itself successfully.)
I think this would result in maintainers playing core wars on the
users' systems (already rather a problem). Perhaps I should encourage
the decoupled approach more.
In practice in our current setup, leaving a package in a bad state is
not really helpful to the user. None of the contemporary package
management tools using libapt cope at all well. dselect (without `apt
acquisition') is somewhat better although still not ideal and no-one
but a handful of curmodgeons still uses it.
What we'd be engaging in there is a kind of institutionalised
finger-pointing. How sure are we that our fingers will be pointed
only appropriately ? I think this kind of approach is going to cause
more problems than it solves.
Thanks for all your comments.
Ian.
Reply to: