Previously H. Peter Anvin wrote: > Agreed. This is another reason for having a post-install script: the > post-install script could coax the output into the appropriate form for > your particular flavour of inetd. Things not supported by your inetd > such as respawn limits would simply get dropped. I don't see at all what this has to do with a post-install script.. What we are looking for is something to manage the configuration of a inetd-like tool such that * we are not restricted to the features inetd, it should be possible to add new features (which may be ignored if your inetd doesn't support them) * allows packages to (un)register themselves * allows admins to override the configuration as supplied by the package * can handle multiple versions if a service installed (I might have multiple ftpds or in.fingerds on my system) * allows admins to manually add/remove entries Wichert. -- _________________________________________________________________ / Generally uninteresting signature - ignore at your convenience \ | wichert@liacs.nl http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Attachment:
pgpxakC2mcQJT.pgp
Description: PGP signature