couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <>
Subject Re: Binary Downloads
Date Tue, 08 Nov 2011 14:27:40 GMT
On Mon, Nov 7, 2011 at 7:46 PM, Randall Leeds <> wrote:
> On Sun, Nov 6, 2011 at 09:15, Jason Smith <> wrote:
>> On Sun, Nov 6, 2011 at 4:18 PM, Noah Slater <> wrote:
>>> On Sun, Nov 6, 2011 at 4:07 PM, kowsik <> wrote:
>>>> Contrast this with CouchDB which has huge dependencies external to
>>>> itself (the right version of erlang, compiling it with just the right
>>>> options, openssl, spidermonkey, etc, etc). Personally, I love the
>>>> simplicity of CouchDBX. One click and boom you are up and running.
>>>> This is philosophical, but ultimately no matter what software you are
>>>> building, if the time to value is going to take a bunch of hoops to
>>>> get through, nobody's going to have the patience.
>>> Yep, CouchDBX is great, but it is still a "toy" version of CouchDB.
>>> Personally, I rely on build-couchdb. @_jhs and others have added
>>>> knowledge into this about OS detection and how best to get couchdb
>>>> setup and compiled and started on specific distro's. It implicitly
>>>> encodes this knowledge of 'on this OS you have to compile erlang with
>>>> these flags' kind of things.
>>> It concerns me that these things are in build-couchdb, and not in CouchDB.
>> Technical note: build-couchdb is more akin to packaging tools than
>> compiling tools. (There is a reason Debian `rules` files are
>> Makefiles.)
>> It (1) includes and (2) builds several related packages
>> * autoconf-2.13
>> * autoconf-2.59
>> * erlang
>> * libicu
>> * libcurl
>> * libmozjs
>> * couch
>> * couch plugins such as GeoCouch, BrowserID, Facebook authentication, etc.
>> It also does several things which made me blush when I wrote them but
>> I figured nobody would ever find out.
>> But it is not unlike how package developers maintain diffs against the
>> upstream sources, and in fact some of that logic could flow upstream.
>> At this stage in the discussion, the main function build-couchdb
>> serves is as a known "thing" to compare and contrast against.
>> --
>> Iris Couch
> So, whatever build-couchdb does that's overly difficult is something
> that we should ameliorate with upstream changes. We have lots of
> configure flags and I suspect build-couchdb probably has to use many
> of them to link couchdb against the other deps it also builds.
> One approach could be to update the build system to search for things
> in a well-known ./deps folder. Then, the default (and the only thing
> hosted and released officially by the project) would be a bare source
> checkout, but we could include a script (parts taken from
> build-couchdb) to fetch everything into ./deps and build against that.
> But build-couchdb still _builds_ couchdb, so it's not the dream of a
> "download-and-run-it" binary. The primary difference in the end
> between build-couchdb and a standard source build is that the deps are
> all wrapped up in the install prefix and kept separate from the user
> system. What Jan was proposing was something like the _result_ of
> build-couchdb builds, on several OS/architecture combinations, ready
> to go.
> And to be honest, I'm totally fine with that. But, users are getting
> more and more used to package managers even outside the *nix world, so
> great downstream packaging is also key. I think this is the same
> topic.
> It's really starting to sound like nothing's much wrong with our
> source tree as just that our download page, and our packaging
> community, doesn't get users where they need to go easily enough.
> Concrete next steps?
> For me, I'm going to try to get a clean debian patch branch based off
> the latest packaging I can find, start building CouchDB in a chroot
> and put it in my PPA.
> We already revived the web site overhaul thread, but I think we could
> improve the download page without waiting. Anyone up for it? Start a
> thread and collect the relevant links and info, I guess.
> What else?

I think this isn't our goal to provide debs rpm, ... that the role of
the distribution. Our role is to make etehir life easier and
eventually help them to solve issues they have very fast.

Also packaging is somehow something depending on the goal people have.
Some want it embedded other want a way to manage multiple couchdb.
Other are distributing a custom build . So distributing official
binaries could be tricky.

On the other hand what we could provide is a way to ease packaging. I
would put more effort in couchdb core than providing a binary imo. Ie
improving application supports, handling erlang releases to handle
easy updates of a couchdb release/package etc... The think that ease
the deploiement and packaging in fact.

For the rest a download page linking to all the couchdb distributions
would be enough imo ...

- benoit

View raw message