[Pkg-erlang-devel] CouchDB packaging updates

[Chad MILLER]

Hi, I work near Elliot, and I don't mind elucidating some of the details 
that he thinks are offtopic here.  For most replies about our rationale 
and usage internals, perhaps we should go off-list; I do not mind.

tldr:  One couchdb per user, not per app.  Start couchdb lazily, so as 
to be conservative.  Putting init in a parent package is simple, works 
*now* with no code changes, and costs nothing.



On 11/10/2009 01:21 PM, Chad MILLER wrote:
> 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.

Let me betray a secret of ours:  We're trying to get couchdb on every 
desktop [evil genius voice] In The World!! [/]

Splitting couchdb allows us to start couchdb only lazily, so people who 
do not use apps that talk to couchdb will see no change at all -- no 
couchdb is started.  For people who do, they get it started for this app 
and all future apps.

>> 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?

Ah, I see your complaint.  One couchdb per app *would* suck.  We don't 
do that.

Each app must use DBus to discover the port number to talk to.  DBus 
port-getting function returns port of already-running server, and starts 
it first if there is none.

> 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.

Excellent.  We satisfy all three.

Since you seem to care about the details of how we're using couchdb:  We 
use XDG base-directory for users' home; OAuth and/or http-basic for 
authentication and each gets a personal port to talk to; we start it at 
first access and don't shut it down so that future access works fast.

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

All of our desktopcouch infrastructure works *without changing anything 
about the couchdb packages*.  Thus, it's not a fork at all.

(This "infrastructure" is a DBus service and a generated config file in 
$HOME, and some library functions that makes it trivial to talk to the 
personal server.)

What is new about what we advocate?  A system couchdb is unnecessary 
overhead and we try to avoid it.

There are two cases that cover everything (afaict):

1)  A user installs "couchdb" (as usual) and automatically also gets 
"couchdb-bin", and system couchdb starts at boot.

2)  A user installs apps that Depend on "couchdb-bin".  No couchdb runs 
until a user starts any one of those apps, and then a single user's 
instance for all apps runs until the user logs out.

People smarter than me considered the scenarios for doing this right.  I 
*think* I can list them:

- We could not split, and stop installation and prompt the user whether 
they want couchdb started by default.  Also, petition couchdb 
development to add user authentication (through PAM?) and change the way 
the internals of the server work so that users can not view or stomp on 
each others' data.  That would take a while and impact APIs and 
potentially all users of couchdb.

- We could not split, just decide whether we want couchdb started by 
default or not.  Neither is very good.  Also, petition couchdb 
development (ditto ditto)....  That would take a while and impact APIs 
and potentially all users of couchdb.

- Normal users could avoid using couchdb at all.

- We could split the binaries into a subpackage, so all upgrades just 
work, installs are not onerous, users get the smallest part that they 
want, and there's no change to couchdb internals.  Users and their apps 
get all the benefits of using couchdb for their interesting data.

We advocate the last one.  It costs almost nothing to put the init files 
in a same-named parent package that Depends on the real code.

- chad