Re: Draft spec for new dpkg "triggers" feature (v2, repost)
[Note: IANADD; neither am I subscribed to -dpkg, so please Cc: me.]
Sounds like a worthwhile plan. :) Just a few minor comments.
* Ian Jackson <iwj@ubuntu.com> (Tue, 10 Apr 2007 19:27:06 +0100):
>
> TRIGGERS
> ========
> Details - triggered package
> ---------------------------
>
> When one of the triggers in which a package is interested is activated
> the triggered package goes has the trigger added to its list of
^^^^^^^^
> pending triggers. [...]
The "goes" seems to have been left while editing the draft.
> 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'.
Perhaps this would be more clear if the section below which states that
trigger processing of `config-failed' (et al.) packages will still be
awaited would be referenced. "(See also below.)"?
Or better a short remark that this is supposed to mark the offending
producer if a consumer finds bad data.
> Timing guarantees, races, etc.
> ------------------------------
>
> Activating a trigger will not have any immediate effect, although
> putative resulting status changes will show up in dpkg --status etc.
> (Putative because the actual status changes may depend on the state of
> trigger interests when dpkg processes the trigger activation into
> the status database, rather than that when dpkg --status is run.)
>
> A package is only guaranteed to become notified of a trigger
> activation if it is continuously interested in the trigger, and never
> in `config-failed' or worse, during the period from when the trigger
> is activatated until dpkg runs the package postinst (either due to
^^^^^^^^^^^
> --configure --pending, or at the end of the relevant run, as described
> above). [...]
This should probably read "activated".
> If the package is not in state `installed', `triggers-pending' or
> `triggers-awaited' then pending triggers are not accumulated.
> However, such a package (between `half-installed' and `config-failed'
> inclusive) declares some trigger interests then the triggering
> packages *will* await their trigger processing (or removal).
Probably should read: "However, if such a package [...]"
> WORKED EXAMPLE - SCROLLKEEPER
> =============================
> and to retain this behaviour, something along the following lines
> would be sensible:
>
> if [ "$1" = "configure" ]; then
> printf "Rebuilding the database. This may take some time.\n"
> scrollkeeper-rebuilddb -q
> else
> printf "Updating GNOME help database.\n"
> scrollkeeper-update -q
> fi
(Minor spacing issue: the if/else/fi and the new printf use only spaces,
the old printf and both scrollkeeper lines use a tab as well. This
messes up when re-indented, e.g., for quoting in email.)
> This not 100% in keeping with the full transition plan defined below:
> if a new gnome package is used with an old scrollkeeper, there is some
> possibility that the help will not properly be available.
>
> 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.
Why can't an updated dh_scrollkeeper set a versioned Conflicts of the
triggers unaware scrollkeeper packages on new gnome packages? Would it
be a problem if there is a "Conflicts: scrollkeeper (< N)" and at the
same time a "Depends: scrollkeeper (>= 3.8)" with 3.8 being less than N?
For maximum success, the scrollkeeper Depends would have to be removed
manually anyhow. But I'm most probably missing something here.
> TRANSITION PLAN
> ===============
> Transition hints for existing packages
> --------------------------------------
>
> When a central (consumer) package defines a directory where other leaf
> (producer) packages may place files and/or directories, and currently
> the producer packages are required to run an `update-consumer' script
> in their postinst:
> 1. In the relevant policy, define a trigger name which is the name of
> the directory where the individual files are placed by producer
> packages.
> 2. Update the consumer package:
> * 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.)
> 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.
Here, too: Why not alternatively use versioned Conflicts, in cases where
the producers might be used independently of the consumer?
> 4. After all producer packages have been updated according to step 3,
> `update-consumer' has become an interface internal to the consumer
> and need no longer be kept stable. If un-updated producers are
> still of interest, incompatible changes to `update-consumer' imply
> a versioned Breaks against the old producers.
> (See also `Transition plan', below.)
>
> 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:
> 1. Define the trigger name.
> 2. Update the switchboard to have any new functionality needed by the
> consumers in step 3 (2nd bullet).
> 3. Update the consumer packages:
> * Declare an interest in the trigger.
> * In the postinst, arrange for the new `trigger' invocation to run
^^^^^^^^^
Should this be `triggered', as the postinst argument?
> the compilation/registration process. This may involve scanning
> for new or removed producers, and may involve new common
> functionality from the switchboard (in which case a versioned
> Depends is needed).
> * The old interface allowing the switchboard to run
> compilation/registration should be preserved, including
> calls to the switchboard to register this consumer.
> 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. Alternatively,
> it may be the case that the switchboard is no longer needed (or
> not needed for this producer), in which case the dependency on
> the switchboard can be removed in favour of an appropriate
> versioned Breaks (probably, identical to that in the new
> switchboard).
> 6. After all the producers have been updated, the cruft in the
> consumers can go away:
> * Remove the calls to the switchboard's registration system.
> * Versioned Breaks against old switchboards, or versioned Depends
> on new switchboards, depending on whether the switchboard is
> still needed for other common functionality.
> 7. After all of the producers and consumers have been updated, the
> cruft in the switchboard can go away:
> * Remove the switchboard's registration system (but not obviously
> the common functionality from step 3, discussed above).
> * Versioned Breaks against pre-step-6 consumers and pre-step-5
> producers.
Perhaps some producers can't simply be identified by a unique point in
the file system hierarchy; an explicit trigger would be in order, then.
This would most probably mean an "activate" in the producer's triggers
control file. Old producers could keep working, then, if the switchboard
would use dpkg-trigger instead of no-ops in the producer registration
scripts.
It is arguable, though, if spelling out the "activate" and dpkg-trigger
steps in the transition plan would really be helpful or rather confusing
in their adding to the plan's complexity. ;)
> INTERNALS
> =========
>
> Processing
> ----------
>
> dpkg-trigger updates triggers/Deferred, and does not read or write the
> status file or take out the dpkg status lock. dpkg (and dpkg-query)
> reads triggers/Deferred after reading /var/lib/dpkg/status, and after
> running a maintainer script. If the status database is opened for
> writing then the data from Deferred is moved to updates as
> Triggers-Pending and Triggers-Awaited entries and corresponding Status
> changes.
>
> This means that the dpkg is guaranteed to reincorporate pending
^^^
This "the" looks out-of-place compared to the rest of the specification.
> trigger information into the status file only 1. when a maintainer
> script has finished, or 2. when dpkg starts up with a view to
> performing some operation.
Regards, Fabian
--
Fabian "zzz" Pietsch - http://zzz.arara.de/
Reply to: