On Wed, Nov 28, 2007 at 11:08:27AM +0000, Steve Langasek wrote:
> On Wed, Nov 28, 2007 at 11:51:07AM +0100, Pierre Habouzit wrote:
> > > Well, not completely true. There might be more than one understanding.
> > > Mine is that providing a inet-superserver provides the _functionality_
> > > of a inet-superserver not the same _config file_.
>
> > wrong. providing inet-superserver means that you are able to perform
> > what any implementation of inetd(8) does, namely, reading
> > /etc/inetd.conf, and _then_ possibly have extended features on its own.
>
> Where is that documented? Watching the progression of inetd packages in
> Debian has been dizzying, I don't have the sense that there's any sort of
> central plan that everyone's following. This virtual package's semantics
> certainly aren't documented in policy.
Well I'd say that it's what common sense would expect[0], and with the
-4 I just uploaded, the "issues" about -inetd_compat are discussed in
NEWS.Debian, README.Debian and the changelog.
And upgrading xinetd from a previous version won't activate it by
default (with the except of -3 sorry for them). I believe this is the
best way to handle the transition: statu quo for "old" users, new
behavior for new ones.
[0] the reasoning is: this is clear to me that through update-inetd
that is the debian way to enable inet-like services, something
that claims to be an inet-superserver must react on update-inetd
triggered changes. update-inetd atm only acts on /etc/inetd.conf,
so as a consequences I believe it's necessary for an
inet-superserver provider to grok /etc/inetd.conf.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Attachment:
pgpK0pvVWW8Uc.pgp
Description: PGP signature