Re: (fwd) Draft spec for new dpkg "triggers" feature
Goswin von Brederlow <email@example.com> wrote:
> Frank Küster <firstname.lastname@example.org> writes:
>> Goswin von Brederlow <email@example.com> wrote:
>>> 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
> Bad idea. Say foobar 1.0 is installed already. Blafase 1.0 gets
> installed and triggers foobar and fails due to a bug in foobar.
> Now you want to install foobar 1.1 to fix the bug.
> If dpkg runs the trigers again first then it will just fail again and
> again and never update to a working foobar version.
I agree, I missed that. Still it is not a reason not to tell the user
which package(s) activated the trigger.
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)