[Pkg-erlang-devel] CouchDB packaging updates

[Sergei Golovan]

On Tue, Nov 10, 2009 at 12:54 AM, Elliot Murphy <elliot at canonical.com> wrote:
> On 11/09/2009 04:31 PM, Sam Bisbee wrote:
>> 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?
>>
>
> The point of splitting out the couchdb-bin package is so that the init
> script isn't installed, and couchdb is not started on boot.

It's very strange point as for me. Either you want to use the service,
so it should be started, or you don't, so don't install it.

>
>>> 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.
>>
>
> The design of the other applications which use the couchdb binaries is
> out of scope for this team/package I think :) Just to go ahead and
> answer the question though: desktopcouch dynamically chooses the port at
> runtime, and uses a separate config file. There's other details as well
> around token exchange and driving replication.

Does it mean that every application which wants to use couchdb should
start its own instance? And as a result to have another erlang in
memory and another couchdb database on a disk?

I would say that if you want to install couchdb on a per-user basis it
must satisfy the following conditions:

0) It must be configurable by user in his home directory and not by
root it /etc. It must be usable in multiple user environment (so two
couchdbs running by two different users must not conflict);
1) It must be really personal, another user must not be able to
connect to it and store or retrieve data;
2) any application which wants to use couchdb must be able to use an
existing instance if any.

But achieving these goals does look as forking to me. Simply removing
init script isn't sufficient.

>
> Getting back on topic, there is a genuine desire from people writing
> applications which use couchdb (Ubuntu One) to be able to install the
> couchdb binaries without getting a systemwide couchdb booted. If there
> is a better way to provide this capability in the packaging than
> splitting into two binary packages, then I'd love to hear it.

Debian is not UbuntuOne. And having one system-wide database service
looks better to me than launching another one on start of any
application. Moreover, the upstream doesn't provide per-user
customization of couchdb.

>
> Another approach that was considered was using a flag in a config file
> to determine whether or not the systemwide couchdb should be started
> when the init script runs. That doesn't totally solve this though, as
> then there is a debate over what the default setting should be. Even
> with such a setting in the upstream init script and config file, I don't
> know how to express a dependency on couchdb to say "Desktopcouch depends
> on couchdb but please don't boot the system instance by default unless
> someone else requested it".

Why can't desktopcouch use a system-wide couchdb service?

>
> This isn't in any way a fork from upstream. Upstream doesn't provide the
>  debian packaging in the tarball they release (yes, I'm ignoring that
> Noah is awesome and maintained the package so far ;), the packaging is
> added by debian maintainers. This is purely about splitting the binary
> packages so that they are useful in the widest variety of situations.

It is essentially a fork because you have yo add (remove init script,
actually) something which is unexpected by the upstream.

>
>>
>> p.s. Am being slowed down by svn/ssh issues in the virtual box when connecting
>> to alioth.
>>
>
> Strange! It's been a long time since I worked with svn, I've been having
> to type my passphrase for every operation, even log. Otherwise it's been
> working fine.

It's possible to add a public key in alioth web-interface (at account
management) and use ssh-agent instead of always typing your password.

Cheers!
-- 
Sergei Golovan