Re: file trigger and dpkg aborting due to dependency errors
- To: Goswin von Brederlow <firstname.lastname@example.org>
- Cc: email@example.com
- Subject: Re: file trigger and dpkg aborting due to dependency errors
- From: Goswin von Brederlow <firstname.lastname@example.org>
- Date: Sun, 03 Apr 2011 14:00:10 +0200
- Message-id: <[🔎] email@example.com>
- In-reply-to: <20110331054543.GB6286@rivendell.home.ouaza.com> (Raphael Hertzog's message of "Thu, 31 Mar 2011 07:45:43 +0200")
- References: <firstname.lastname@example.org> <20110330171150.GC2894@rivendell.home.ouaza.com> <email@example.com> <20110331054543.GB6286@rivendell.home.ouaza.com>
Raphael Hertzog <firstname.lastname@example.org> writes:
> On Wed, 30 Mar 2011, Goswin von Brederlow wrote:
>> > Note also that the trigger activation is a no-op if the qlustar-image-common is
>> > not configured which means that you have to regenerate your image in the
>> > "configure" of qlustar-image-common as well as in the "triggered" case.
>> Is a package allowed to trigger itself? Or is that already considered a
> I don't see how a package can trigger itself. If you run dpkg-trigger from
> the postinst, the package is not configured yet and the trigger is a
> no-op. It's the same for a file trigger which is executed during unpack.
Looking closer at /usr/share/doc/dpkg-dev/triggers.txt.gz:
Packages in `config-failed' or worse are never considered to have
lists of pending triggers. A package whose postinst is being run
can however acquire pending triggers during that run (ie, a package
can trigger itself).
The docs seem to support triggering oneself is valid and it works not
just for pakages in `config-failed' state.