> 1) I thought the plan was to have a couchdb-bin package to avoid exactly
> this sort of issue.
Right, I thought that was the plan, too.
> 2) Have you spoken to the Debian maintainer about this?
This is the crucial point here. There are other packages like chef-server or bindwood which depend on couchdb, and might rely on a system instance getting started. We should only change the behaviour of the couchdb package if (1) the reverse dependencies get along with this, i. e. don't expect a system instance, and (2) the Debian maintainer agrees with this change, so that we don't need to keep a packaging delta for all reverse dependencies just to cope with a different behaviour of couchdb.
If that means that the only thing in couchdb is the init script, so be it. There might be other things, though, like the /etc/couchdb/ hierarchy, /var/log/couchdb/, or /etc/logrotate.d/couchdb
Oh, and can we please stop the package from shipping /var/log/couchdb/0.10.0~svn809550 ? :-)
> 1) I thought the plan was to have a couchdb-bin package to avoid exactly
> this sort of issue.
Right, I thought that was the plan, too.
> 2) Have you spoken to the Debian maintainer about this?
This is the crucial point here. There are other packages like chef-server or bindwood which depend on couchdb, and might rely on a system instance getting started. We should only change the behaviour of the couchdb package if (1) the reverse dependencies get along with this, i. e. don't expect a system instance, and (2) the Debian maintainer agrees with this change, so that we don't need to keep a packaging delta for all reverse dependencies just to cope with a different behaviour of couchdb.
If that means that the only thing in couchdb is the init script, so be it. There might be other things, though, like the /etc/couchdb/ hierarchy, /var/log/couchdb/, or /etc/logrotate. d/couchdb
Oh, and can we please stop the package from shipping /var/log/ couchdb/ 0.10.0~ svn809550 ? :-)