Enrico Scholz wrote:
Todd Zullinger <tmz(a)pobox.com> writes:
> A package like git-daemon on the other hand, which is a subpackage
> specifically designed to provide an xinetd service, really ought to
> require xinetd to give a good experience out of the box, correct?
no; you can use it with every inetd like program. E.g. placing
| start on starting local
| exec /sbin/busybox tcpsvd 0 1234 /usr/bin/git-daemon ...
into /etc/event.d/git-daemon provides an alternative way to invoke
git-daemon and it's not more work than editing the xinetd setup.
Keeping stuff configurable and do not require stuff which is not
needed for core functionality is a good thing...
Even when it means that we're shipping something that doesn't work out
of the box? It seems rude to expect users to install git-daemon, try
to enable it using the standard chkconfig method, then have to
manually install xinetd.
I do understand keeping requirements to a minimum, but I think that
also needs to be balanced against making packages work as smoothly as
possible by default. I appreciate your opinion Enrico and I'm
certainly interested to know what other folks think about this before
I add an xinetd requirement to git-daemon.
At the least, having a consistent approach to this would help users
and packagers. Currently, some packages require xinetd and others do
not. I think that leaves users of our packages in an uncomfortable
If the goal really is to cater to users wanting to run the daemon via
xinetd, upstart, init.d, etc, having subpackages for each would seem
to be the way to go. But I'm certainly not interested in trying to
play that game.
I think that we should make a sane default choice for a given package
and ensure that it works. At worst, those wanting to use some method
other than xinetd are stuck with having xinetd pulled in (which costs
~376K of disk space).
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
Once ... in the wilds of Afghanistan, I lost my corkscrew, and we were
forced to live on nothing but food and water for days.
-- W.C. Fields