couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: Binary Downloads
Date Thu, 03 Nov 2011 22:26:11 GMT
Randall, Till,

I had hoped I addressed this in my original mail, but let me try again :)

I'm in favour of all the things your are saying, but I'm trying to address this scenario:

$ wget $url
$ tar xzf $archive
$ ./$dir/couchdb
  Time to relax.

All the other things we should also do, and please don't let me hold you back from doing them

A lot of areas need improvement, and I'm attacking a small one without trying to boil the
ocean. If you think the above is a bad idea, please let me know, we shouldn't do it.

But if you think it is okay, then lets do it. And then get to the next thing.


On Nov 3, 2011, at 23:11 , Randall Leeds wrote:

> On Thu, Nov 3, 2011 at 14:22, till <> wrote:
>> On Thu, Nov 3, 2011 at 12:35 PM, Jan Lehnardt <> 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 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.
>>> *
>>> 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
>>> --
>> Yes and no.
>> I'm not a fan of rogue binary installs which don't leverage anything
>> distributions have to offer. It's never all self-contained, e.g. you want
>> to register the service for a startup procedure and off you go into
>> specifics of a system and outside a single directory. If anything it should
>> be specific to the target: on Ubuntu/Debian there should be a launchpad
>> project which contains updated releases of CouchDB for let's say the
>> current Ubuntu/Debian releases. On Redhat/CentOS/Fedora a yum-mirror would
>> be appropriate, etc. pp.. I'm sure each platform has a project to piggyback.
> 100% agree. I've already got a launchpad ppa here:
> It's not useful right now, but I'm volunteering now to start keeping
> that up to date. I've already got the schroot toolchain set up so it
> shouldn't be too hard to maintain backports of recent CouchDB
> versions, along with dependencies, back to the lastest LTS Ubuntu
> release. I did some work the other night toward maintaining a debian
> branch in my git clone which should make it easier to maintain the
> package. I'll link up with sbisbee and chrisccoulson to see if I can
> help out with official Ubuntu packaging, but will also aim to maintain
> my own backports when necessary.
> Meebo runs CentOS/Scientific Linux and I've played with the RPM
> packaging for that quite a bit, though I tend to be less up to date on
> that since upgrading is a big production, whereas on my desktop I tend
> to keep more up to date. Happy to help out with that conversation,
> too, though.
> -Randall
>> Generally though, I'm not sure what the objective is. E.g. is it to please
>> people on hackernews (SCNR)? :-D
>> But for realz: is it to ensure more up-to-date CouchDB (binary) releases on
>> different platforms? Because that might be something to work on. As far as
>> binary is concerned, most platforms have something already (Ubuntu, Debian,
>> *BSD, ...). And some just don't do binary at all (I think Archlinux and
>> Gentoo would be examples). And then I am not sure if providing a binary to
>> their users makes sense.
>> Also to consider: team up with current package maintainers in order to have
>> more frequent releases etc.. Or at least give that a try, before the
>> CouchDB project goes off to do their own thing.
>> Till
> Great thoughts, Till. I agree all over.
> -Randall

View raw message