[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

(and adding some --assert-triggers is IMHO a good idea, like the current

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.

> ==========
> 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?


Reply to: