Re: Draft spec for new dpkg "triggers" feature (v2, repost)
* 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).
> package creation). This file contains directives, one per line.
> Leading and trailing whitespace is trimmed and lines starting with #
> and empty lines will be ignored.
Please also ignore anything after "#", so that one can write
interest foo # necessary for ...
interest bar # drop after release of Lenny
> --triggers
> Processes only triggers. All pending triggers will be
> processed. If package names are supplied only those packages'
> triggers will be processed, exactly once each where necessary.
>
> Use of --suppress-triggers, or an explicit list of packages with
> --triggers, may leave packages in the improper `triggers' state. This
> can be fixed later by running one of:
> dpkg --configure --pending
> dpkg --triggers
why not require --pending here as well? (just for "being the same")
> 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.)
> However, dh_scrollkeeper doesn't generate the scrollkeeper dependency
> in the control file, which makes it excessively hard to get the
> dependency up to date. (This was a mistake in the design of
> dh_scrollkeeper.) The bad consequences of the inaccurate dependencies
> are less severe than the contortions which would be required to deal
> with the problem.
I don't think it is a good idea to describe some package this way - and,
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
(and adding some --assert-triggers is IMHO a good idea, like the current
--assert-support-predepends)
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/...)
(And of course, dh_scrollkeeper can add an explicit dependency via the
usual debhelper way, and we can just phase the current dependency out,
but I don't think a versioned dependency is necessary.)
> 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.
> 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.)
> * 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"?
> 3. Update the producer packages:
> * In the postinst, remove the call to update-consumer
> * Change the dependency on consumer to be versioned, specifying a
> trigger-interested consumer.
See above - why not just check if dpkg is trigger aware?
> If there are several consumer packages all of which are interested in
> the features provided by producer packages, the current arrangements
> usually involve an additional central switchboard package (eg,
> emacsen-common). In this case:
same comments as above apply, of course.
> DISCUSSION
> ==========
>
> 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)?
> Broken producer packages, and error reporting
> ---------------------------------------------
>
> Often trigger processing by will involve a central package
> registering, compiling or generally parsing some data provided by a
> leaf package.
>
> If the central package finds problems with the leaf package data it is
> usually more correct for only the inidividual leaf package to be
> recorded as not properly installed. There is not currently any way to
> do this and there are no plans to provide one.
>
> The naive approach of giving the postinst a list of the triggering
> packages does not work because this information is not recorded in the
> right way (it might contain lacunae); enhancing the bookkeeping for
> this to work would be possible but it is far better simply to make the
> system more idempotent. See above for the recommended approach.
The right approach to this would be call-backs, which shell doesn't
provide. A "not so right" approach could be some "dpkg-triggers
--mark-as-failed $package" (where the package could be found from a file
via dpkg -S $file - or via dpkg-triggers itself once that is
implemented). How about that?
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
Reply to: