Re: 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
Reply to: