Re: Finding out in postinst whether some other package is configured
Ben Armstrong <email@example.com> wrote:
> On Tue, 2005-10-11 at 19:28 +0200, Frank Küster wrote:
>> is there an established way to find out in the postinst script of a
>> package whether an other package (e.g. one which we Recommend or
>> Suggest) is configured? Testing for file contents can only tell whether
>> it is unpacked, but that might not be enough.
>> If there isn't, are there other people who felt the need to know this?
> I worry about why you would need to know this. I'm envisioning a
> package "A" that has a particular default configuration if you install A
> before B, but a different configuration if you install B before A. What
> will the user be missing out on if they're installed in the "wrong"
> order? And what corrective action can the user take?
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.
While writing this, I get the feeling that I don't want to know this. I
have been thinking about a mechanism to run these time-consuming
processed with a dpkg-postinstallation hook as zope does for a long
time. But I decided not to do this because they sometimes fail (99%
because of user misconfiguration), and it's better to know which package
was configured when it failed. For the same reason, I probably don't
want to delay the registration process if tetex-bin isn't already
Inst. f. Biochemie der Univ. Zürich