Re: Finding out in postinst whether some other package is configured
Goswin von Brederlow <email@example.com> wrote:
> Anthony DeRobertis <firstname.lastname@example.org> 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
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.
> 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.
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.
Inst. f. Biochemie der Univ. Zürich