[Pkg-erlang-devel] CouchDB packaging updates

[Sam Bisbee]

On Mon, Nov 09, 2009 at 04:12:55PM -0500, Elliot Murphy wrote:
> Thanks for writing back!
> 
> On 11/09/2009 02:19 PM, Sam Bisbee wrote:
> > For the local user install option, would it still have the ability to serve to
> > the network devices? If yes, then this feels weird to me. If no, this still
> > seems a bit odd as it breaks the paradigm that most all database systems are
> > using right now: one or more installs as system wide applications that
> > subsequent applications pull from.
> 
> I will try to explain a bit better. Splitting out couchdb-bin allows:
> 
> installing couchdb will gives an end result exactly like we have now,
> with couchdb started via init script at boot. Existing packages such as
> chef that depend on couchdb continue to work with no change required.
> 
> Installing couchdb-bin installs the couchdb binaries with no init
> script, so that there is no systemwide instance of couchdb running.

Gotcha.

> This seems to offer the most flexibility, anyone who wants a system wide
> install can get it by installing couchdb. It also enables
> http://launchpad.net/desktopcouch to depend on couchdb-bin to get a
> demand-started couchdb instance. Booting an unwanted systemwide couchdb
> instance gets a lot of unwanted attention when reviewing bootspeed
> performance charts :)

Well, why have it start at boot if it's unwanted? And can't desktopcouch (or
whatever) just run the init script if couchdb isn't running, thereby creating
an on demand service?

> Is this a style thing, or is there any bad effect from having two binary
> packages instead of a single monolithic one?

It can just be a style thing (I prefer one package: ex., why have man pages not
be in the dev package), but I think we're running into technical reasons too.

 - Will each individual instance be pulling from the same config file? If yes,
   then not only is this redundant but it could cause issues: two servers
   attempting to bind to the same address/port.

 - This seems like another fork from upstream that we'd have to support for
   each new release. I'd rather limit the number of forks that we have, unless
   they make sense for Debian. Even if we personally disagree with something in
   the upstream, as long as it works in Debian then we should just port it.
   Otherwise we're really not couchdb, but a completely forked project.

Thanks,

p.s. Am being slowed down by svn/ssh issues in the virtual box when connecting
to alioth. 

-- 
Sam Bisbee