Josip Rodin <[EMAIL PROTECTED]> writes: > Peter Makholm (brother) already did some work on it, but I haven't > seen anything else... and we have a big fat warning in current > update-inetd implemented.
What I did was a drop-in replacement of the present perlscrip behind update-inetd. It can serve as an temporary solution to the problem but I don't think it's a nice solution and freeze was just about that time (first try). I had some thought about a better solution but they would require some more rewriting of the present scripts and I didn't really have the time before the freeze (which never happened). The design of a future update-inetd would be something like the following: Any package providing inetd-like features implements a module to make a configuration file based on some common data. Any package providing serveres to be run through inetd register with update-inetd (just like now). update-inetd constructs with help of the modules conf-files for all inetd-like packages. (Nothing exceptionel here, and I could probally look at the menu things to se how that works) The question is, should servers have the posibility to use non-vanilla inetd features. That is, should update-inetd has the posibillity to set any other flags than those used by the normal inetd? -- Spinach, carrot, and a melon -- a meal fit for a nurse! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
