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
would you accept patches to add that support (for the directory
question, and, if you choose to keep it, also for the enable flag)?