Re: Draft spec for new dpkg "triggers" feature (v2, repost)
* Ian Jackson (ian@davenant.greenend.org.uk) [070430 18:02]:
> 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.
Ok, I understand your reasoning.
About my example, my current understanding is (but my logic might be
flawed, so please say so):
It is only guranteed that the trigger is activated before the file is
being modified.
However, one wants to have the trigger executed after the file is
actually changed. So, how is this guranteed? Or could there be a
sequence of events where the trigger is executed before the file is
being modified?
> > > 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.
How about making --pending optional for --configure as well then?
> > 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.
In the long term, any of the above is unnecessary, agreed.
However, we probably want some code that works with the old dpkg, but
already takes advantage of the new dpkg (like people did with
po-debconf, so that packages could still be built on woody, even though
po-debconf didn't work there - though of course not required by policy).
> > > 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) ?
The second. If we find some way the user isn't bothered to execute
--triggers himself, that's of course ok.
> > > * 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 can remember well how much effort we had for the Etch release to
describe a good, working upgrade order, and any package that we can keep
off that detailed description is helpful.
> 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.
I expect some consumer packages to have the scripts anyways - well,
actually, I expect different packages will do it different, independed
of what you or I propose. :)
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
Reply to: