Brian May wrote: > Obviously the design would have to be well though out, I think (first > draft only) dh_installinetd would need to be able to determine the > following bits of information: > - service > - group > - commented out by default > - stream/dgram? TCP/UDP? wait/nowait? (not sure about this one). > - userid:groupid > - command (not including /usr/sbin/tcpd). > - parameters > - (maybe extra information could be optionally used, eg. for xinetd.) > - max spawned processes, etc. I've thought about it, but I could see no way around requiring a lot of information of this sort. Trying to shoehorn this into debhelper as you do here -- > eg. heimdal-kdc might have a debian/packagename.inetd file with: > > --- cut --- > Service: kerberos-adm > Group: OTHER > Disabled: no > Type: stream/TCP/nowait > User: root > Group: root > Command: /usr/lib/heimdal-servers/kadmind > Parameters: > > Service: krb_prop > Group: OTHER > Disabled: yes > Type: stream/TCP/nowait > User: root > Group: root > Command: /usr/sbin/hpropd > Parameters: > --- cut --- Has the same problem as suggested dh_adduser program (bug #118787). Namely, you end up with something that is just as complicated as adding calls to updte-inetd to the maintainer scripts yourself. Which just ends up increasing the learning curve for maintainers, since they have to learn all of the above plus still learn how update-inetd really works, to debug things. There is some benefit in moving from procedural to data-driven mechanisms, but it doesn't seem to be worth it in the case of either adduser or update-inetd, to me. -- see shy jo
Attachment:
pgpBgQMpQ5Oc2.pgp
Description: PGP signature