Re: Finding out in postinst whether some other package is configured
Frank Küster <frank@debian.org> writes:
> Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> wrote:
>
>> Anthony DeRobertis <anthony@derobert.net> writes:
>>
>>> Frank Küster wrote:
>>>
>>>> In the particular case, the reason is something else: If the recommended
>>>> package B (tetex-bin) is there, it makes sense to run one of its
>>>> executables (mktexlsr, updmap) to register the files of package A (any TeX
>>>> font package). This is a time-consuming process. However, if B is
>>>> installed but unconfigured, we can save this time because when B is
>>>> configured, it will run these executables, anyway, and doing this also
>>>> will pick up package A's files.
>>>
>>> Sounds to me like package B should be performing these optimizations,
>>> not package A.
>>
>> In the past people have suggested adding something to dpkg that allows
>> one to schedule a script to be run _once_ at the end of a dpkg
>> session.
>
> This is already possible by using DPkg::Post-Invoke in apt.conf. The
> zope packages do that, however I don't know what happens if a zope
> package is installed with dpkg instead of apt/aptitude/whatever.
Post-Invoke gets run every time so you need some more wraper magic to
implement a run "this" just once but only when needed.
Also how would a package inset such a Post-Invoke line into the
conffig? Modifying the conffile would be a policy violation.
>> dpkg-run-once would add the command to a journal (unless it already
>> contains it) and dpkg would execute that journal at the end of its
>> livetime. For use in apt/aptitude/dselect executing the journal could
>> be suspended until the last dpkg run.
>
> The big problem with that is that if such a command ever fails, how does
> the package system know which package caused the error? It could be the
> one that first registered the call, but also an other package that would
> have added it to the journal if it hadn't been there yet.
Probably all of them instead of just one.
I don't see this as a big problem. Currently if one of the packages
adds broken files causing the update script to fail on average half
the packages will be broken (everything after the broken one).
So having them all set to failed is just twice as bad from a statistic
point of view and doesn't create any extra work.
> And even if you make a decision here, there's an other problem: Once
> the call failed and you attributed this to a particular package, how do
> you indicate this in the package system? Either by setting its state to
> "unconfigured"; but this will then happen *after* packages that depend
> on it have been (maybe successfully) configured. Or you have to invent
> a new category.
The run-once system would be for stuff with no depends on it. If
something depends on such a command to be run then it is not garantied
that _once_ is enough. One can easily create cases where the command
must be run every time to satisfy the depends.
But you are right. There could be a similar thing (an option)
indicating this must be run at the end of a depends step instead at
the end of dpkg or even multiple dpkg calls by apt.
A simple and probably already quite effective solution would be to
have packages stay unconfigured until their journal entry has been run
but run it as late as possible (only if something depends on it or at
the end).
> Regards, Frank
MfG
Goswin
Reply to: