On Sat, Mar 08, 2003 at 09:56:57PM -0500, Joey Hess wrote:
> 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.
Maybe the code I copied from was overly complicated, but manipulating
inetd scripts ended up modifying postinst, postrm, and prerm.
postrm is a duplicate of the part of the code in postinst, and
preinst is a duplicate of the other part of the code in preinst.
That leaves a lot of room for mistakes to occur, and the different
files can become out of sequence.
This might be OK if the package only has one or two inetd entries, but
heimdal-servers has 4 entries, and heimdal-kdc (same source) has two.
Now say I want to improve the algorithm I used, I would need to modify 6
files, and that leaves a lot of room for errors...
I wrote code that will do similar to what I want, although at the moment
it is specific to TCP, and hasn't had heaps of testing, see
Now instead of modifying 6 files containing duplicate information, I
only need to modify 2.
dh_adduser on the other hand, isn't so important, partly because
adding a user is a procedural task, and usually has to be done in the
right order, and partly because adding/deleting a user is relatively a
straight forward task anyway.
Brian May <firstname.lastname@example.org>