From dev-return-19139-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Mon Nov 7 18:46:31 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 0B4D67BF2 for ; Mon, 7 Nov 2011 18:46:31 +0000 (UTC) Received: (qmail 59906 invoked by uid 500); 7 Nov 2011 18:46:30 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 59795 invoked by uid 500); 7 Nov 2011 18:46:30 -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 59787 invoked by uid 99); 7 Nov 2011 18:46:30 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 Nov 2011 18:46:30 +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 randall.leeds@gmail.com designates 209.85.213.52 as permitted sender) Received: from [209.85.213.52] (HELO mail-yw0-f52.google.com) (209.85.213.52) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 Nov 2011 18:46:24 +0000 Received: by ywm13 with SMTP id 13so7824040ywm.11 for ; Mon, 07 Nov 2011 10:46:02 -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=WGaVSRR5QzuE2kxmUbOy3uF/ME0Zv0Qls4e3S3yoSuQ=; b=M13LGVrb6VnzVtv4HGgS97wvTmEYiR8ssxBatlE6OUPoJZ1tRA/YF0GqUTahyvvzhK j7o3Hl0WDgYN7N4TWQ8KzmCrHb3JuaQbEGMsLQ1YRxXdrg2K0xATv4BMEVAki7VzXz/E 5+FfU5heeKh5qaKBjLEQlM/h1Yq24rT3x5kWg= MIME-Version: 1.0 Received: by 10.42.155.70 with SMTP id t6mr49028386icw.38.1320691561992; Mon, 07 Nov 2011 10:46:01 -0800 (PST) Received: by 10.42.142.4 with HTTP; Mon, 7 Nov 2011 10:46:01 -0800 (PST) In-Reply-To: References: <785FABDB-2EF0-409A-A6C5-E9C8D498241B@apache.org> Date: Mon, 7 Nov 2011 10:46:01 -0800 Message-ID: Subject: Re: Binary Downloads From: Randall Leeds To: dev@couchdb.apache.org Content-Type: text/plain; charset=UTF-8 X-Virus-Checked: Checked by ClamAV on apache.org 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?