[Pkg-erlang-devel] CouchDB packaging updates

[Chad MILLER]

On 11/11/2009 10:16 PM, Sam Bisbee wrote:
> On Tue, Nov 10, 2009 at 10:11:57PM -0500, Chad MILLER wrote:
>> On 11/10/2009 08:53 PM, Sam Bisbee wrote:
>>> On Tue, Nov 10, 2009 at 02:55:03PM -0500, Chad MILLER wrote:
>>>> 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.
>>>
>>> Hello Chad,
>>>
>>> Thank you very much for your reply, it was quite clear and it sounds like
>>> you're doing some interesting things with couchdb. I'm quite happy to hear that
>>> you're trying to spread couchdb use.
>>>
>>> However, your packaging and use of couchdb _does_ change the natural way things
>>> are done with couchdb. I'm not saying that what you are trying to accomplish is
>>> right or wrong, I'm just saying that it's not what native couchdb does. That
>>> makes it a fork, regardless of whether you change the code or not.
>>
>> I'm running stock couchdb manually, and specifying a different data
>> directory and specifying that it use the magical port "0".  That sounds
>> "native" to me, and there is nothing at all I need from couchdb
>> developers.  There are no couchdb changes to take to an upstream, and
>> I'm frankly at a loss to imagine what else you think I should do.
>>
>> The only thing on my wish list is that people using this not waste
>> memory or boot time on a daemon that they're not using.
>
> Okay, then maybe that's where my real problem is. If they're not using couchdb,
> then why do they have it installed?

Ah, Sam, you're equating the software name with a single daemon running 
as user 'couchdb' on port 5984, which was started at boot.  We're saying 
that, like all great tools, couchdb is more useful than that.  A single 
user does not have to run it.  All data don't have to be in the same 
pool for all users.  It doesn't have to be started at boot time, or 
perhaps not at all.  It doesn't have to be running on a predetermined port.

> And if they're temporarily not using it,
> then why can't they configure it to not run at boot (remove the init script,
> etc.)?

I'll answer why.  Remember my secret?  The audience for couchdb 
functionality will be different.

We're bringing couchdb to every user who uses something that stores data 
that more than one program might care about, whether it's a different 
package or similar software on a different machine.

Firefox, epiphany, opera, chrome, maybe even lynx -- all sharing 
bookmarks on every machine you use.  Tomboy notes synch to your 
computers (and to your mobile phone).  Calendar items.  Contacts.  The 
data are application agnostic,   It replicates to everywhere you are.

And we're not driving every usage of couchdb data or trying to predict 
it.  I spoke to a stranger 30 seconds ago on Freenode who has decided to 
change empathy to put IM conversations in the personal couchdb so that 
he has them on all the machines he logs-in to.  I think it's a wonderful 
idea, and it's the first I've heard of it.

I get enthusiastic, so please pardon my verbosity.  My point is that we 
hope couchdb will be everywhere soon*, even for nontechnical users.  My 
grandma will not want to mess with /etc .

> I don't think it's a stretch in users' minds that if they install a
> program and forget about it that it'll still be there, doing its job.

Absolutely.  If you install 'couchdb', you should get a running daemon 
that a normal user doesn't own.

I'm also adding:  If you install Tomboy, you should be able to use *a* 
couchdb instance without a running system daemon.

 >
> If there are two things that get my blood boiling with packages it's when
> either they (1) "depend" on everything including the baby and the bath water in
> the repository, or (2) break everything into tiny packages (ex., what's the
> point in having a dev package without man files or debug symbols?).
>
> This scenario appears to be in the second category for me.

I agree on 1 and 2, but I think instead that we have a good reason to 
put the init file in a 'couchdb' package, which Depends on the guts of 
couchdb-the-software.  There are several projects in the works that need 
couchdb-the-software but not a unitary single couchdb daemon.  These are 
coming to Debian soon.

> As for my upstream comments, I was under the impression that source code,
> config files, etc. had been changed. I came under this impression when Sergei
> put forth a list of things that would need to be done to have a per-user
> couchdb in his eyes (I appended to it) and the response was "we do all that" -
> if all those things are done, then code or config changes had to have been
> made. Hence my repeated spiels about sending such changes upstream.

I intended only to say "we satisfy these three per-user-couchdb 
conditions."  We fabricate a new configuration file for the personal 
couchdb to read, in ~/.config/desktop-couch/ .  couchdb 0.10 is perfect 
for personal use, with no changes at all to its source.

I hope this has helped convince you, Sam, that splitting has merit. 
Also, I hope you, plural, are inspired to help with this project.  I 
want to take over the ugly old dotfile world and significantly enhance 
the Linux desktop (leapfrogging those other OSes!), and I welcome help 
from smart people.  It's still early, and there's plenty of interesting 
work to do.

- chad


* Did you know Ubuntu is shipping 'erlang' and 'couchdb-bin' on The CD 
for the most recent Ubuntu release?   Not only did we make room in the 
700MB, they are installed by *default*!  We may have just increased the 
number of erlang installations by many orders of magnitude.  I, for one, 
am very exceited about that.