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

Bug#35691: dpkg: New package dependency: "affects"



On Wed, 7 Apr 1999, Santiago Vila Doncel wrote:

> > Package: dpkg
> > Version: 1.4.0.34
> > Severity: wishlist

[new dep field]

> I think this particular problem would be solved by:
> 
> 1. Making /etc/mailcap not to be a conffile but instead generate a
> default one in the postinst when it does not exist.
> 
> 2. Making the generation of the default /etc/mailcap by
> mime-support.postinst to be done by a new script, mime-support-conf.
> 
> 3. Making the install-mime script to call mime-support-conf to create a
> default /etc/mailcap if it does not exist, before registering any app.

This does not, however, solve all problems. Assume you are running a
system without mime-support installed and you would want to install it
later on. With my approach, dpkg would notice that the other package, e.g.
lynx, interacts in some way with mime-support, and call lynx.postinst,
which would register lynx as an HTML viewer. Your approach would not do
that but ignore lynx because it was installed before mime-support.

> This way install-mime would not have to be configured first.

You could have the very same effect if install-mime would save the
requests until mime-support is configured.

> I suggest that this bug is reassigned to mime-support as a technical
> suboptimality in the current implementation, because it may be solved
> without the need of a new dpkg field.

I disagree with that, because this problem is not uncommon to other
packages as well; I've already mentioned doc-base. The very same method
could be used when bytecompiling emacs modules or for the inetd database
in case you're upgrading netbase (simply install the new config, any
program that needs an entry in /etc/inetd.conf registers itself again).

Implementing this as a dpkg feature would help keeping this mechanism aout
of the other packages, and increase system robustness, because you can
automatically rebuild such databases.

   Simon



Reply to: