FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian dpkg

 
 
LinkBack Thread Tools
 
Old 03-30-2011, 02:12 PM
Goswin von Brederlow
 
Default file trigger and dpkg aborting due to dependency errors

Hi,

I have a little problem with file triggers.

I have a tool (qlustar-image-common) that builds a root filesystem image
from a set of modules. The tool has a file trigger on
/usr/lib/qlustar/modules. Now I have 2 modules: core and ha. The core
module contains a minimal bootable system and the ha modules adds high
availability stuff to it. The ha module depends on the core module.

Now here is what happens:

% sudo dpkg -i ../qlustar-module-ha-lucid-amd64-7.4.1_7.4.1~exp+2011-03-30+15.27_all.deb

(Reading database ... 94836 files and directories currently installed.)
Preparing to replace qlustar-module-ha-lucid-amd64-7.4.1
7.4.1~exp+2011-03-30+15.14 (using
.../qlustar-module-ha-lucid-amd64-7.4.1_7.4.1~exp+2011-03-30+15.27_all.deb)
...
Unpacking replacement qlustar-module-ha-lucid-amd64-7.4.1 ...
dpkg: dependency problems prevent configuration of
qlustar-module-ha-lucid-amd64-7.4.1:
qlustar-module-ha-lucid-amd64-7.4.1 depends on qlustar-module-core-lucid-amd64-7.4.1 (= 7.4.1~exp+2011-03-30+15.27); however:
Version of qlustar-module-core-lucid-amd64-7.4.1 on system is 7.4.1~exp+2011-03-30+14.37.
dpkg: error processing qlustar-module-ha-lucid-amd64-7.4.1 (--install):
dependency problems - leaving unconfigured
Processing triggers for qlustar-image-common ...
qlustar-image-common: triggered /usr/lib/qlustar/modules
....


As you can see the the ha module can not be configure due to
dependencies. But the file trigger is run none the less. This causes
images to be build with a version skew between the core and ha
module. Can this be avoided?


% sudo dpkg -i ../qlustar-module-core-lucid-amd64-7.4.1_7.4.1~exp+2011-03-30+15.27_all.deb

(Reading database ... 94836 files and directories currently installed.)
Preparing to replace qlustar-module-core-lucid-amd64-7.4.1 7.4.1~exp+2011-03-30+14.37 (using .../qlustar-module-core-lucid-amd64-7.4.1_7.4.1~exp+2011-03-30+15.27_all.deb) ...
/var/lib/dpkg/info/qlustar-module-core-lucid-amd64-7.4.1.prerm upgrade 7.4.1~exp+2011-03-30+15.27
Unpacking replacement qlustar-module-core-lucid-amd64-7.4.1 ...
Setting up qlustar-module-core-lucid-amd64-7.4.1 (7.4.1~exp+2011-03-30+15.27) ...
Processing triggers for qlustar-image-common ...
qlustar-image-common: triggered /usr/lib/qlustar/modules
...

Installing the core module works fine and the file trigger is run as expected.
This luckily fixes the images as they are generated again.

And last:

% sudo dpkg --configure qlustar-module-ha-lucid-amd64-7.4.1
Setting up qlustar-module-ha-lucid-amd64-7.4.1 (7.4.1~exp+2011-03-30+15.27) ...

The file trigger is not run again. For me this is not a problem right
now. But what if the postinst of the ha module needs to be run before
the file trigger is to be run?

Or actualy it is a problem right now because I need the depends of my
package to be satisfied before the file trigger is run.

What are my options here? Do I need to Pre-Depend on the core module or
do I need to use an explicit trigger in the modules postinst scripts?

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87pqp8itnj.fsf@frosties.localnet">http://lists.debian.org/87pqp8itnj.fsf@frosties.localnet
 
Old 03-30-2011, 05:11 PM
Raphael Hertzog
 
Default file trigger and dpkg aborting due to dependency errors

Hi,

On Wed, 30 Mar 2011, Goswin von Brederlow wrote:
> Unpacking replacement qlustar-module-ha-lucid-amd64-7.4.1 ...
> dpkg: dependency problems prevent configuration of
> qlustar-module-ha-lucid-amd64-7.4.1:
> qlustar-module-ha-lucid-amd64-7.4.1 depends on qlustar-module-core-lucid-amd64-7.4.1 (= 7.4.1~exp+2011-03-30+15.27); however:
> Version of qlustar-module-core-lucid-amd64-7.4.1 on system is 7.4.1~exp+2011-03-30+14.37.
> dpkg: error processing qlustar-module-ha-lucid-amd64-7.4.1 (--install):
> dependency problems - leaving unconfigured
> Processing triggers for qlustar-image-common ...
> qlustar-image-common: triggered /usr/lib/qlustar/modules
> ....
>
> As you can see the the ha module can not be configure due to
> dependencies. But the file trigger is run none the less. This causes
> images to be build with a version skew between the core and ha
> module. Can this be avoided?

I don't see how it could be avoided. The file trigger is triggered by the unpack
which succeeds.

It's execute because qlustar-image-common is in configured state at the
start and it's required to come back to the configured state (and not stay
in triggers-pending).

What you can do is code your trigger to do nothing if it detects a version
skew...

> % sudo dpkg --configure qlustar-module-ha-lucid-amd64-7.4.1
> Setting up qlustar-module-ha-lucid-amd64-7.4.1 (7.4.1~exp+2011-03-30+15.27) ...
>
> The file trigger is not run again. For me this is not a problem right
> now. But what if the postinst of the ha module needs to be run before
> the file trigger is to be run?

At some point you must decide that the file trigger is definitely not
the right interface for what you're trying to do instead of trying to
paper over poor design choices.

> Or actualy it is a problem right now because I need the depends of my
> package to be satisfied before the file trigger is run.

You can only be sure that the depends of the package that runs the triggers
are satisfied, those of the triggering packages might not be since the
file trigger is activated at unpack time.

> What are my options here? Do I need to Pre-Depend on the core module or
> do I need to use an explicit trigger in the modules postinst scripts?

Obviously a Pre-Depend can ensure you that you have the right dependencies
when you unpack and thus activate the file trigger but that's ugly IMO.

An explicit trigger in the postinst(s) is probably better but it won't
solve your problem of version skew... since the core will be configured
first and the image might be regenerated before the "ha" part gets
configured.

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.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110330171150.GC2894@rivendell.home.ouaza.com">ht tp://lists.debian.org/20110330171150.GC2894@rivendell.home.ouaza.com
 
Old 03-30-2011, 09:36 PM
Goswin von Brederlow
 
Default file trigger and dpkg aborting due to dependency errors

Raphael Hertzog <hertzog@debian.org> writes:

> Hi,
>
> On Wed, 30 Mar 2011, Goswin von Brederlow wrote:
>> Unpacking replacement qlustar-module-ha-lucid-amd64-7.4.1 ...
>> dpkg: dependency problems prevent configuration of
>> qlustar-module-ha-lucid-amd64-7.4.1:
>> qlustar-module-ha-lucid-amd64-7.4.1 depends on qlustar-module-core-lucid-amd64-7.4.1 (= 7.4.1~exp+2011-03-30+15.27); however:
>> Version of qlustar-module-core-lucid-amd64-7.4.1 on system is 7.4.1~exp+2011-03-30+14.37.
>> dpkg: error processing qlustar-module-ha-lucid-amd64-7.4.1 (--install):
>> dependency problems - leaving unconfigured
>> Processing triggers for qlustar-image-common ...
>> qlustar-image-common: triggered /usr/lib/qlustar/modules
>> ....
>>
>> As you can see the the ha module can not be configure due to
>> dependencies. But the file trigger is run none the less. This causes
>> images to be build with a version skew between the core and ha
>> module. Can this be avoided?
>
> I don't see how it could be avoided. The file trigger is triggered by the unpack
> which succeeds.
>
> It's execute because qlustar-image-common is in configured state at the
> start and it's required to come back to the configured state (and not stay
> in triggers-pending).

Which is a bit surprising but on closer examination it makes sense.

> What you can do is code your trigger to do nothing if it detects a version
> skew...
>
>> % sudo dpkg --configure qlustar-module-ha-lucid-amd64-7.4.1
>> Setting up qlustar-module-ha-lucid-amd64-7.4.1 (7.4.1~exp+2011-03-30+15.27) ...
>>
>> The file trigger is not run again. For me this is not a problem right
>> now. But what if the postinst of the ha module needs to be run before
>> the file trigger is to be run?
>
> At some point you must decide that the file trigger is definitely not
> the right interface for what you're trying to do instead of trying to
> paper over poor design choices.

It does look that way. So file triggers are definetly out of the picture
when the trigger has to run after configuring the triggering package.

>> Or actualy it is a problem right now because I need the depends of my
>> package to be satisfied before the file trigger is run.
>
> You can only be sure that the depends of the package that runs the triggers
> are satisfied, those of the triggering packages might not be since the
> file trigger is activated at unpack time.

Ok, so the observed behaviour is the intended behaviour for file
trigger. Knowing that I can work with it.

>> What are my options here? Do I need to Pre-Depend on the core module or
>> do I need to use an explicit trigger in the modules postinst scripts?
>
> Obviously a Pre-Depend can ensure you that you have the right dependencies
> when you unpack and thus activate the file trigger but that's ugly IMO.

It also wouldn't help because core would be unpacked and configured and
trigger the rebuild and only then in a second dpkg call ha would be
unpacked and trigger again. There would still be a window where an image
with version skew is build.

> An explicit trigger in the postinst(s) is probably better but it won't
> solve your problem of version skew... since the core will be configured
> first and the image might be regenerated before the "ha" part gets
> configured.

You are right, there is still the chance of a version skew and explicit
trigger (alone) won't solve the problem.


In all cases the trigger seems to need to handle versions skews gracefully.
And given that any option will work and a file trigger looks like the
best solution. That way module packages don't need a (identical)
postinst and prerm script.

> 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
cycle?

It seems to work to manually trigger /usr/lib/qlustar/modules during
"configure". That way images are build at least once and only once.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87hbaks32f.fsf@frosties.localnet">http://lists.debian.org/87hbaks32f.fsf@frosties.localnet
 
Old 03-31-2011, 05:45 AM
Raphael Hertzog
 
Default file trigger and dpkg aborting due to dependency errors

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
> cycle?

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.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110331054543.GB6286@rivendell.home.ouaza.com">ht tp://lists.debian.org/20110331054543.GB6286@rivendell.home.ouaza.com
 
Old 04-03-2011, 12:00 PM
Goswin von Brederlow
 
Default file trigger and dpkg aborting due to dependency errors

Raphael Hertzog <hertzog@debian.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
>> cycle?
>
> 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.
>
> Cheers,

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.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87zko7ilyt.fsf@frosties.localnet">http://lists.debian.org/87zko7ilyt.fsf@frosties.localnet
 

Thread Tools




All times are GMT. The time now is 10:29 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org