[Pkg-erlang-devel] CouchDB packaging updates
chad.miller at canonical.com
Thu Nov 12 16:24:29 UTC 2009
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,
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.
* 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.
More information about the Pkg-erlang-devel