On Thu, Nov 3, 2011 at 15:26, Jan Lehnardt <[email protected]> wrote: > 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.
I think what Till and I are getting at is that something this simple can still be distro-specific and provide a "better" experience (e.g., automatic upgrades with the system package manager when we make more releases) while still not requiring everyone to be an auto-tools sysadmin. $ curl $url | sh ...downloads certs and adds repositories $ sudo apt-get (install|update) couchdb Then relax. -Randall > > 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. > > Cheers > Jan > -- > > > On Nov 3, 2011, at 23:11 , Randall Leeds wrote: > >> On Thu, Nov 3, 2011 at 14:22, till <[email protected]> wrote: >>> On Thu, Nov 3, 2011 at 12:35 PM, Jan Lehnardt <[email protected]> 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 >>>> -- >>>> >>>> >>> 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: >> https://launchpad.net/~randall-leeds/+archive/couchdb >> 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 > >
