couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joan Touzet <>
Subject Re: On the Viability of Erlang Releases and CouchDB
Date Sun, 11 May 2014 18:32:45 GMT
Jan has a follow-up item from this week to email the list and clarify
the decision reached in Vienna regarding how we approach supporting
anything beyond the base CouchDB tarball. Strong viewpoints were
presented and I want to be sure everyone is at least aware of the 
decision reached, whether everyone agrees or not.


----- Original Message -----
From: "Klaus Trainer" <>
Sent: Sunday, May 11, 2014 1:28:04 PM
Subject: Re: On the Viability of Erlang Releases and CouchDB

Thanks Russell for this well-founded writeup!  This really helps a lot
in understanding that matter.  Your suggestion of making specific
recommendations regarding certain combinations of CouchDB and Erlang/OTP
 sounds reasonable in that context.

> The narrowness of the acceptable releases list is going to cause some
> problems. Debian Wheezy runs R15B01, which as established above, is
> not good to run with unless you have the `+sfwi` patch, and I'm sure
> there are many other distros running R15 and R16B or R16B01. I think
> it would be useful to users to have a set of packages with a proper
> Erlang CouchDB release allowing us to bless specific versions of
> Erlang and bundle it together, but I know this idea goes against the
> recent change in stance on working with distributions, and I don't
> know the ASF stance on this issue well enough to comment on the
> legality of it. That said, it does seem like the logical approach
> until we get a range of stable releases spread out through the
> distros.

We already do provide binary packages with Erlang/OTP and CouchDB
bundled together (see :)

Speaking of proper CouchDB OTP-releases: I don't see any conflict (or
potential conflict) regarding "the recent change in stance on working
with distributions".  We can both have OTP-releases (finally having them
will be great after all), while still being supportive of distributors
when they want to create their own distribution-specific package.

View raw message