> This adds a new variable in /etc/default/couchdb to control whether couchdb is
> started at boot or not - most desktop installs will not need couchdb started
> at boot so this is a nice compromise. It seemed simpler that splitting the
> init script into a separate binary package, and a few other packages such as
> pulseaudio, monit, and fetchmail seem to do the same thing.
Most packages that use this default to starting the daemon.
pulseaudio doesn't because Ubuntu's default set-up uses a per-user setup,
and fetchmail is often used in the same way.
Granted you are doing this because you use couchdb in a similar way, but
it's still a system db on it's own, and that's currently how most people
use it.
Therefore I am a little wary of this change, but not against it. 2 questions:
1) I thought the plan was to have a couchdb-bin package to avoid exactly
this sort of issue.
2) Have you spoken to the Debian maintainer about this?
> This adds a new variable in /etc/default/ couchdb to control whether couchdb is
> started at boot or not - most desktop installs will not need couchdb started
> at boot so this is a nice compromise. It seemed simpler that splitting the
> init script into a separate binary package, and a few other packages such as
> pulseaudio, monit, and fetchmail seem to do the same thing.
Most packages that use this default to starting the daemon.
pulseaudio doesn't because Ubuntu's default set-up uses a per-user setup,
and fetchmail is often used in the same way.
Granted you are doing this because you use couchdb in a similar way, but
it's still a system db on it's own, and that's currently how most people
use it.
Therefore I am a little wary of this change, but not against it. 2 questions:
1) I thought the plan was to have a couchdb-bin package to avoid exactly
this sort of issue.
2) Have you spoken to the Debian maintainer about this?
Thanks,
James