From dev-return-19154-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Tue Nov 8 14:28:08 2011 Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4573A9286 for ; Tue, 8 Nov 2011 14:28:08 +0000 (UTC) Received: (qmail 13314 invoked by uid 500); 8 Nov 2011 14:28:07 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 13276 invoked by uid 500); 8 Nov 2011 14:28:07 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 13268 invoked by uid 99); 8 Nov 2011 14:28:07 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 Nov 2011 14:28:07 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of bchesneau@gmail.com designates 209.85.215.180 as permitted sender) Received: from [209.85.215.180] (HELO mail-ey0-f180.google.com) (209.85.215.180) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 Nov 2011 14:28:01 +0000 Received: by eyg5 with SMTP id 5so474168eyg.11 for ; Tue, 08 Nov 2011 06:27:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=6atZ5qbzR7Nrw+wFZxAiQMj6aYHOZ4gt2Jarsrm7dDE=; b=Lvlm0HN032EVTHmddWed7eBd/BYVi1V8IbmEKfjIC/62QhPnlzGOaQX0xkcBFzrz5v pVrWhzIQooKUvK5UbQ61Y0fK9MfyW/Z05Qd04fMWAunP0cHvIRQtN0hh9vNGork9eDyQ mjZWyvt0kmncTqCuRX2xhtbuQBFqzuy0h4jUI= MIME-Version: 1.0 Received: by 10.14.16.166 with SMTP id h38mr2610267eeh.193.1320762461106; Tue, 08 Nov 2011 06:27:41 -0800 (PST) Received: by 10.14.28.73 with HTTP; Tue, 8 Nov 2011 06:27:40 -0800 (PST) In-Reply-To: References: <785FABDB-2EF0-409A-A6C5-E9C8D498241B@apache.org> Date: Tue, 8 Nov 2011 15:27:40 +0100 Message-ID: Subject: Re: Binary Downloads From: Benoit Chesneau To: dev@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org 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