sorry for the late answer.

first, the enable flag (and having it by default set to false is) is in general a good thing. that way, a daemon does need to get manually enabled by the admin. this appears to be specifically nice for daemons such as git-daemon which might "suddenly" expose users data that he did not necessarily want to in the first place. also, having no way to disable the daemon but keeping it installed would be bad.

having said that, for git-daemon-sysvinit, the package doesn't actually contain the daemon binaries but only the sysvinit integration, so it's not necessarily required to have a switch off flag, a 'dpkg -P git-daemon-sysvinit' or 'update-rc.d disable [...]' call would be aequivalent. if a enabled=true/false flag should be kept for convenience, rather than to trigger sysvinit or even packaging changes, is your call.

the potential automatic exposure of user data doesn't seem to much of an issue here, as git-daemon-sysvinit explicitly needs to be installed, and, even if installed and enabled, it still needs to have a) some repositories in the default location /var/cache/git *and* b) an 'attacker' would need to know the exact repo location.

[ unrelated to that, git-daemon-sysvinit actually doesn't work in the default case anyway, due to a bug with the basepath, i'll send a patch for that later these days; i had that in the original patch, but it got dropped after some time during the process of getting it merged in the git package itself. ]

or in other words, i personally don't really mind if there's a enable flag or not.

if you intend to keep it, it should have a debconf question (priority low) so that the package can be preseeded. this also holds true for the directory location.

would you accept patches to add that support (for the directory question, and, if you choose to keep it, also for the enable flag)?

Regards,
Daniel

--
Address:        Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:          daniel.baum...@progress-technologies.net
Internet:       http://people.progress-technologies.net/~daniel.baumann/



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to