First off, I disagree with the initial bug that opened this report and agree with Gerrit's response. The purpose of the git-daemon-run package is to provide a runit interface for git-daemon; asking that it not use runit is missing the point of the package.
I think there is a normal-severity bug in the git-daemon-run package in that the long description doesn't clearly state that it uses runit, and that might be surprising to some users, but I don't think any action is needed on that package other than changing the long description to more clearly note that it uses runit. It seems like the remaining issue is whether the git-daemon package should also provide an init script via some mechanism for people who don't want to use runit. If one does so, one has to be careful to not have both a runit configuration and an init script active at the same time, so it's not an entirely trivial exercise. The suggestion of providing a different package would work, but I agree that it's not ideal; that package would be extremely small and Policy recommends that init scripts be used as the default daemon management mechanism. Kurt Roeckx <k...@roeckx.be> writes: > All policy seems to have to say about this is: > Packages that include daemons for system services should place > scripts in `/etc/init.d' to start or stop services at boot time or > during a change of runlevel. These scripts should be named > `/etc/init.d/<package>' > > It's only a should and not a must. > > But it has also been pointed out that this is what administrators > expect. And I see no good reason not to provide that interface to our > users. Only providing the runit version seems to cause more problems > for the users that are not familiar with it. It could even be argued > that if you provided an init.d script you would have less bug reports. > > I would recommend putting the init script in the same binary package as > the daemon itself. Having it in an other package will most likely > result in the service being stopped and not started again on upgrades. runit, for runit-aware services and when the system administrator is familiar with the system, offers substantial features above what's available from the init system. It provides some capabilities similar to what upstart provides, including service monitoring, automatic restart, and a better-defined interface for controlling the service that doesn't require anywhere near as much fiddling as getting start-stop-daemon working properly with the right output. So I can certainly understand why Gerrit wants a runit-managed git-daemon and doesn't want to mess with a traditional init script. Were this my package, I think what I'd do is offer an init script that automatically switches to using runit if git-daemon-run is installed, detecting that in some reasonable fashion. I can understand Gerrit's lack of enthusiasm for writing that script and maintaining it, though. But if someone else contributes it, it's fairly simple and straightforward, and it doesn't break git-daemon-run, maybe he'd be willing to consider it? (I realize that he's still on vacation and we'll need to wait for him to return to really complete this discussion.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
