Re: Draft spec for new dpkg "triggers" feature (v2, repost)
Fabian Pietsch writes ("Re: Draft spec for new dpkg "triggers" feature (v2, repost)"):
> Sounds like a worthwhile plan. :) Just a few minor comments.
Thanks for all the comments. Most of them are uncontroversial and
I've incorporated them into my draft.
> * Ian Jackson <iwj@ubuntu.com> (Tue, 10 Apr 2007 19:27:06 +0100):
> > 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.
I'm not sure what you mean. It's not to do with marking the offending
producer; it's just a side-effect of the fact that `config-failed'
packages have an empty pending trigger list.
> > 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?
Because there isn't currently any plumbing in the
dh_scrollkeeper-using packages to allow dh_scrollkeeper to specify the
dependencies.
Furthermore, these very strong dependencies will impose very stringent
upgrade ordering which I thin will in practice cause more problems
than they solve. Remember that the bad failure mode for the weaker
dependencies is that under some very rare conditions some of the
documentation might not be available.
If we start messing with Conflicts, you can easily get to a situation
where packages are wedged and can't be upgraded properly, or where apt
decides to remove things entirely. Really if anything we should be
using Breaks and I hope Breaks can get into lenny's dpkg RSN, but I
think using nothing would be better. And of course we should be using
Recommends rather than Depends anyway since this documentation is far
from critical.
> For maximum success, the scrollkeeper Depends would have to be removed
> manually anyhow. But I'm most probably missing something here.
It's all rather complicated and it's probably best to make do with a
best-effort setup with a reasonably low probability of a reasonably
harmless failure mode, than an attemopt to fix every corner case with
stronger and more awkward restrictions.
> > 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?
I think the same arguments apply in general as do in the Gnome
documentation case
> > 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.
Yes.
> 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.
Yes, but it may not be worth the effort.
> 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. ;)
Quite so :-).
Thanks,
Ian.
Reply to: