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

[Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>]

Frank Küster <frank@kuesterei.ch> writes:

> 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.


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.

Can't remember what the specs said there.

MfG
        Goswin