[Pkg-erlang-devel] CouchDB packaging updates
chad.miller at canonical.com
Tue Nov 10 19:55:03 UTC 2009
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
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
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.
More information about the Pkg-erlang-devel