Re: Draft spec for new dpkg "triggers" feature

[Florent Rougon <f.rougon@free.fr>]

Hi,

Frank Küster <frank@debian.org> wrote:

>> Maybe 'baz' could depend on tex-common in addition to lmodern, since
>> tex-common's configured state would vanish as soon as the trigger is
>> activated.
>
> Hm, since it's much more likely that updmap-sys fails, I'd rather say
> the consumer package is texlive-base-bin, and 'baz' will depend on it,
> anyway.  

I'm not sure I understand the situation in which you think updmap-sys is
likely to fail.

As for the producer/consumer thing, this terminology (besides being
common in algorithmic) was introduced towards the end of Ian's draft
spec, to respectively refer to a package that provides stuff that needs
to be registered with some update-* command, and to the package that
runs (and usually provides) the update-* command in question (this is
what should happen when triggers are used; without triggers, it's
usually the producer package that issues the update-* command(s) in its
postinst). Just to make sure we are talking about the same thing.

So, you would want texlive-base-bin, instead of tex-common, to run
mktexlsr, update-updmap and updmap-sys? Because it ships mktexlsr and
updmap-sys, and depends on tex-common, which provides mktexlsr? Makes
sense. And tetex-bin could do the same, since several packages can be
interested in the same triggers.

> This is more a problem: I think that if the trigger fails and the
> package that runs it is put into state failed-config (or even if it's
> put into failed-config for non-trigger reasons), this should affect all
> packages that Depend on it.

Seems natural to me, but is not what is happening with current dpkg. And
this isn't a new problem brought by the trigger spec, it's a general
behavior of dpkg wrt dependencies (design choice?). As Ian wrote in
#378009:

  We don't [preserve]:

     B <-Depends- C && installed(C) => installed(B)

  as an invariant in general.

-- 
Florent