Re: (fwd) Draft spec for new dpkg "triggers" feature

[Frank Küster <frank@kuesterei.ch>]

Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> wrote:

>>> Frank Küster <frank@debian.org> writes:
>>>
>>>>   However, in this case an additional feature which I didn't find would
>>>>   be great: In case the triggered action fails and the package that was
>>>>   triggered is put into failed-config state, it would be very good to
>>>>   somehow be able to know: "Which package(s) activated the trigger?".
>>>>   [...]
>>>
>>> Say I install buggy-updmap-package first and then udpmap1-package and
>>> udpmap2-package.
>>>
>>> The second time around the updmap would still fail and claim that
>>> udpmap1-package and udpmap2-package triggered it. But both are not to
>>> blame.
>>
>> There is no second time:  If you install the three packages in one dpkg
>> run, the trigger will be only run once.  All three packages would then
>> be listed as "has activated the failed trigger":  That's better than
>> none, since I only need to check these three packages and not all N
>> installed packages that might activate the trigger.
>>
>> If you first install the buggy package in one run, you can't install the
>> others, since they will depend on the package that contains updmap and
>> provides the trigger, which will be failed-config.
>
> Unless they have no depends but just the trigger.
>
> Say foobar has a kde and gnome module for better integration into the
> desktop. It would then just trigger the gnome or kde desktop hook if
> any of them are installed. But it wouldn't depend on them.

Obviously there are several possible use cases, and you got a point
here.  On the other hand, this problem does not invalidate the wish to
be informed which package(s) triggered and might be the cause, in
particular considering your following suggestion:

> I guess a failed trigger should leave the triggering package in a non
> "installed" state as well so it retriggers on every configure run and
> can be listed by dpkg as a source for failure.

Yes, but it should be listed.  Maybe the trigger itself should have a
"failed" state, too.  Then, if it is requested again, it will be run
once first *before* new triggers are registered.  This means that only
the really buggy package will be in "failed-config" state, the others
are just unpacked/half-configured.

Regards, Frank
-- 
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)