Code review comment for lp:~jderose/ubuntu/trusty/couchdb/1.5.0

Revision history for this message
Jason Gerard DeRose (jderose) wrote :

Dave,

Thanks for the review! I didn't realize that was the intent of the "vendor" information (I thought it was to differentiate between say, rcouch, BigCouch, etc). I'll add that in ASAP.

As far as using the pre-built docs, I personally feel it's more correct to build the docs from their source during the package build. I recall getting dinged for using pre-built docs when I was trying to get pyskein into Debian. To do things the correct Debian way, all Sphinx docs should reference the common JavaScript in the `libjs-sphinxdoc` package, which means you need to build the docs from source so all the versions match up and whatnot. I've had good luck using dh_sphinxdoc for this[1], but I didn't get that working in time for the 1.4.0 package in Saucy. So thanks for reminding me that I still need to do this :)

As far as the Upstart script, I think your "start on" stanza is more correct than what I'm currently using, but as far as I know, my current Upstart script hasn't suffered from the infamous respawn bug. The reason is I'm not calling `couchdb` with the "-b -r 5" options the way the upstream init script does. Instead, I'm letting Upstart do all the process lifecycle management (including respawning if needed). Since switching to Upstart in couchdb 1.4.0-0ubuntu1, I've never encountered a situation where `sudo stop couchdb` didn't work correctly (including when removing or purging the `couchdb` package, something that still plagues the 1.2.0 package). Anyway, I'll incorporate your suggestion into the Upstart script.

Lastly, as far as packaging issues I'd like upstream to be aware of:

1) I'd like to see per-user CouchDB instances (rather than just the system-wide one) become a more official use case upstream; Ubuntu originally diverged from the Debian packaging because they needed to split things into the `couchdb` and `couchdb-bin` packages so desktopcouch could start per-user CouchDB instances without having a system-wide CouchDB instance needlessly running; although desktopcouch is no more, Novacut still has similar needs, just now Dmedia[2] starts CouchDB itself using UserCouch[3]; I think if this was a blessed use case upstream, it would be easier to get Debian (and other distros) on the same page

2) From a security perspective, I really don't like that CouchDB requires write access to its own config file (/etc/couchdb/local.ini); not sure what the correct solution is, but the current situation does *not* give me warm fuzzy feelings :P

Thanks again!

[1] dh_sphinxdoc example: http://bazaar.launchpad.net/~dmedia/dbase32/trunk/view/head:/debian/rules
[2] Dmedia: https://launchpad.net/dmedia
[3] UserCouch: https://launchpad.net/usercouch

« Back to merge proposal