Re: stupid dependencies on update-inetd
md@Linux.IT (Marco d'Itri) writes:
> On Jul 31, Russ Allbery <rra@debian.org> wrote:
>> I'm at a bit of a loss now as to whether to change lintian's checks or
>> not, although I did update the long description of that tag to not push
>> depending on update-inetd directly.
> Yes, because it's *wrong* for all the reasons I explained in this
> thread.
As near as I can tell, it's wrong because rlinetd provides update-inetd
but doesn't depend on update-inetd, and if its diversion instead of
conflict is fixed, you won't be able to install both at the same time, and
because the expectation is that xinetd will do the same. The
generalization is therefore that inet-superserver provides this interface
and the existence of a separate update-inetd package is an accident of
implementation that people should ignore.
However, the current setup, although accidental and arguably buggy, does
allow for packages that strongly depend on the update-inetd functionality
but only recommend or suggest an inet-superserver to express that. This
seems useful to me.
What I'm wondering is if it would be worthwhile to support that accidental
feature rather than making all packages go back to depending on
inet-superserver if they want to run update-inetd from their postinst.
One way to do so that I don't see any immediate problems with would be to
declare update-inetd a virtual package of sorts (I'm not sure if it's
*really* a virtual package when it also has a real package that
corresponds to it, and if that state might cause problems), and have any
package that provides an update-inetd Provide and Conflict with
update-inetd.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: