incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: Binary Downloads
Date Thu, 03 Nov 2011 16:08:10 GMT
On Thu, Nov 3, 2011 at 12:35 PM, Jan Lehnardt <jan@apache.org> wrote:
> Hi all,
>
> I think we should start considering providing binary downloads for our users.
>
> The whole topic is a bit of a mess (see below), so I'd propose to start small.
>
> 1. This first iteration are links from couchdb.apache.org that are clearly
>   marked as "unofficial 3rd party binary downloads" that are not hosted on
>   ASF infrastructure.
>
> 2. Start with popular platforms.
>
> 3. Use the build-couchdb* script to create a fully self-contained directory with
>   CouchDB and all its dependencies in one place that can be rm -rf'd for
>   uninstalling.
>
> * https://github.com/iriscouch/build-couchdb
>
>
> The above circumvents several things that I hope we can resolve later, but that
> I don't consider blocking us from getting the above started.
>
> A. Official ASF releases. Of course, ideally, we should provide official ASF
>   binary releases, but I acknowledge that with a small community, we may have
>   trouble getting votes and testing for all popular platforms together.
>
>   The nice thing of the proposal above though is, that we can, at any time
>   promote an unofficial build to an official one by voting on it and changing
>   it's label on the downloads page.
>
> B. There's many target platforms our users work with and we can't possibly try
>   to service them all at once. We can grow this operation as we get volunteers
>   to help out with each platform.
>
>   The nice thing here is that we can help a significant portion of users with
>   relatively little effort.
>
> C. Using existing package managers. There are many advantages to use official
>   package managers for system installation and they should in fact be the
>   preferred way to set up a system, but they tend to be a little bit behind
>   with current releases.
>
>   I'd be super happy to also work with existing package managers to improve
>   the situation there, but I consider this to be outside of the scope of this
>   discussion.
>
>
> What do you think?
>
> Cheers
> Jan
> --
>
>

Ah, quite interresting topic. Thanks to raise it!

I'm +1 on the idea to have "official binaries" but I really dislike
the idea to have to use build-couchdb for that. Or any system that use
rakes, ruby, python .... where we could just use erlang and unix
tools. It does the job but it's petty ugly (Jason, no offense,
build-couchdb does its job quite well).

I think to do the right job we could:

- adapt the build system to build proper elang release (using
reltools). We can wrap rebar for that since it's pretty efficient
these days and well supported (allows parralel builds, release buils
and clean updates) but this isn't really required, it can be perfectly
handled by autotools. (I think that using rebar would give us more
options though).  The advantage of using erlang release tools is that
we can cleanly manage the modules we need. You can manage templates,
so other distributors can adapt it to their system.

- Create a toolchain à la mozilla that would allows later to introduce
later cross-complication and start to support other platforms. They
are petty good for that and I think we can borrow a couple of ideas.

I would be really interested to work on such things. Also maybe with a
proper toolchain we could setup a build-bot that create nightly
releases and such.

- benoit

Mime
View raw message