[EMAIL PROTECTED] (Marco d'Itri) writes: > On Jul 31, Russ Allbery <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
