On Wed, Nov 28, 2007 at 07:06:13PM +0000, Klaus Ethgen wrote: > Am Mi den 28. Nov 2007 um 11:51 schrieb Pierre Habouzit: > Pardon? debconf overkill? This is right the correct place for it as it > change the basic way the package work completely. Debconf can be used if there isn't a sane default. > > 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. > > There we have completely other understanding of. xinetd is a replacement > (with its own configuration). Using the inetd.conf you have no benefit > of using the plain old one. The compat mode is only good for migration. and to allow the auto-configuration debian is supposed to give for inetd-powered services. > > > Disabled can also mean that the respective file is not created or > > > deleted. > > > > Too bad. Note that given that xinetd proposes the handly "disabled = > > yes" configuration option, that's unwise. > > Why? I know the option. But a deleted (or truncated to zero size) file > is more clear than a option inside. your call. > > > > Only if it provides the full functionality of xinetd (like ie. only > > > allow specified ip range or only few connection at once). > > > > Gni ? I don't understand what you're talking about. > > See manpage options only_from or instances or log_on_* for example. I still don't understand how it's relevant to -inetd_compat. > > because the duplicated configuration in stock /etc/inetd.conf _and_ > > /etc/xinetd.c/* configuration will come from packages that want to > > support both, and then the service name will be the same. > > Untrue. If I look for my configuration, around 50% of the xinetd > services are handmade. oh and there are services with the same name in /etc/inetd.conf ? I bet that not. I try to make the packager life simple with this one. Nothing more. I still don't understand why you're fighting here. I don't force you to also write an /etc/inetd.conf right ? > > I don't expect administrators to be dumb enough to configure mutual > > exclusive services in their /etc/inetd.conf _and_ xinetd.conf. > > Well, just to think about a (fictive) common one, admins might start > with inetd and /etc/inetd.conf and configure there stuff. Then after > years they decide switching to xinetd to have a more granularly way to > control there services. They ignore the old inetd.conf and configure all > services in xinetd. Sometimes later they decide to switch of a service > (by deleting the file as they don't need it anymore). But it is still > running as xinetd uses the entry in inetd.conf. A horror thought! Admins are supposed to read the documentation about the package they install, and if they believe it's a dangerous thing, they can change the default in /etc/default/xinetd once for all. > Am Mi den 28. Nov 2007 um 12:34 schrieb Pierre Habouzit: > > 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. > > True. > > > [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. > > Well, it might be clear for you but I install xinetd to get away from > this crap of the old inetd config. So for me the idea that xinetd might > use /etc/inetd.conf is a horror! (Well I controll it after each update > now but what about other who see that the same than I?) I grow tired of that argument, why should I sacrifice Debian auto-configurability for the 99% of the users that use xinetd extensions for some of the services only ? Again, just edit your /etc/default/xinetd. It's a conffile, it won't be overwritten behind your back, give me a break. -- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.org
Attachment:
pgpzQp8xRrPgY.pgp
Description: PGP signature