Code review comment for lp:~statik/ubuntu/karmic/couchdb/fix-bug427036

Revision history for this message
James Westby (james-w) wrote :

> I've discussed creating a separate couchdb-server binary package that contains
> only the init script, yes. However I didn't find any example of another
> package that was structured this way, while John showed me several packages
> that were using the variable-in-config-file approach. Also, splitting out the
> separate couchdb-server binary package for the init script would require
> making changes in the packages that depend on couchdb, which current only
> seems to be chef-server.

Well, I would suggest that if we do this the "couchdb" package is the one
with the init script, and the couchdb-bin package contains the executable.
That way "apt-get install couchdb" does what an admin would expect and
desktopcouch can just depend on couchdb-bin if I understand correctly,
and so the init script won't end up in the default install and we don't
have to worry about this.

> So I'm not opposed to going back and redoing this fix by creating a separate
> binary package for the init script, but this seemed like a better and simpler
> way to fix the problem.

Yes, I agree, my concern is just for admins, who may expect "apt-get install
couchdb" to give them a couchdb, and in general installing a server package
gets you a running server on Debian/Ubuntu. As you found there are cases
where that isn't the case, but we should at least justify it.

> > 2) Have you spoken to the Debian maintainer about this?
>
> The init scripts are actually shipped by upstream, and I've submitted the
> patch to couchdb: https://issues.apache.org/jira/browse/COUCHDB-499

I was also wondering about the "default off" approach, if Debian disagrees then
this is a delta we have to carry forever. If they prefer the split package
approach say then it isn't.

> Considering this, what approach do you want to take? If you are convinced that
> splitting the init script really is the preferable solution, I'm willing to go
> back and do the change that way.

I don't know what the preferred solution would be, I wanted to have
a discussion to see if we could decide that.

Thanks,

James

« Back to merge proposal