couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <randall.le...@gmail.com>
Subject Re: Binary Downloads
Date Mon, 07 Nov 2011 18:46:01 GMT
On Sun, Nov 6, 2011 at 09:15, Jason Smith <jhs@iriscouch.com> wrote:
> On Sun, Nov 6, 2011 at 4:18 PM, Noah Slater <nslater@tumbolia.org> wrote:
>> On Sun, Nov 6, 2011 at 4:07 PM, kowsik <kowsik@gmail.com> 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?

Mime
View raw message