Re: inet-superserver virtual package

[Guillem Jover <guillem@debian.org>]

On Wed, 2006-08-30 at 14:22:07 +0200, Marco d'Itri wrote:
> On Aug 30, Guillem Jover wrote:
> > I'm not convinced that duplicating update-inetd in most of the
> > inetd providing packages is a good idea, even if this would allow
> > xinetd to be able to replace a normal inetd easily. I'd prefer that the
> > odd cases override update-inetd, via a custom script that gets called
> > if present from u-i or replace it or whatever.

> I can't see why this would be better.

Well, if we want to be able to replace any of the inetd with any other
one we need a neutral format (as someone else also said in the other
thread), this neutral format could be the existing inetd.conf, because
the other packages should support already converting from it, so the
only thing needed would be to add this hook support to update-inetd for
the specific cases where the application does not read the "neutral"
format directly. Also because this hook support should imply minimal
code, just passing the whole arguments to it if the file is present.

> > Also in case the mythical rewrite happens it will be easier to
> > coordinate just one instance than all of them, or to sync them if
> > people start fixing their instances.

> I do not believe this. xinetd and rlinetd need their own versions of
> the program anyway, so at best it could be shared by openbsd-inetd and
> inetutils-inetd. Coordinating the changes in a 13 KB code base among
> 2 or 4 maintainers is easy.

This is a fair point, thought there would be way more of those. But
consider the above, and if the others have to support the "neutral"
format, we may as well share the code, for all of them.

> > > netbase then will temporarily depend on inet-superserver to allow smooth
> > > upgrades until the other packages will switch to a dependency on the
> > > virtual package[1][2].

> > Do you mean only a depedency to the virtual package, w/o a real one?

> No.

Then I agree here with Roger, that spreading this dependency all over
the place makes future changes difficult innecessarily, even if you
can consider me biased I'd think the same if the package for this
depedency was going to be inetutils-inetd. ;)

regards,
guillem