On Mar 10, Brian May <email@example.com> wrote:
>> You would make many more people happy by rewriting update-inetd first.
>> If you want to do this please talk to me and aj first, we both have
>> ideas and some code.
>The idea behind my code is that it should be possible to adapt to
>Then again, perhaps with a good update-inetd interface, there wouldn't
>be so much need for dh_installinetd (but see my other E-Mail).
It would still be useful to not force the maintainer to add all the code
needed to start/restart on install/upgrade/etc.
*Please* do not write anything which will cause the current update-inetd
to stay around longer.
>> This is also a problem for switching among different inetd daemons.
>> I think that any update-inetd rewrite would have to keep on the system a
>> database of the default configuration of each entry added by a package.
>This is probably a good idea, but then you need to get a set of fields
>that are as common as possible between all inetd daemon, but as the same
>time can be expanded to support extra futures that some might provide
Yes. A RFC-822-like file would probably be appropriate.