[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: file trigger and dpkg aborting due to dependency errors


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

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

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.

Raphaël Hertzog ◈ Debian Developer

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

Reply to: