Feel free to disregard this as irrelevant as I am pretty ignorant about the history involved but I am interested in why spidermonkey is not packaged inside of CouchDB as a few of the other dependancies are.
Every time I build Couch on a new machine linking against spidermonkey breaks in some way, in IRC its a problem that developers are hitting constantly, not only that but we have 'issues' between various different versions of spidermonkey itself. It seems like its by far the biggest problem building couch, and although binary distributions would be awesome, it would also be nice to have couchdb as easy to build as possible (outside problems linking against spidermonkey it does very well) Cheers Dale On 8 November 2011 10:26, Noah Slater <nsla...@tumbolia.org> wrote: > Big fat +1 for all of this. > > On Tue, Nov 8, 2011 at 2:43 AM, Jason Smith <j...@iriscouch.com> wrote: > > > A brief diversion from sticking to technical facts in this thread: > > > > > > On Tue, Nov 8, 2011 at 1:46 AM, Randall Leeds <randall.le...@gmail.com> > > wrote: > > > 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. > > > > Randall, thanks for moving the conversation back to goals and > > non-goals of a hypothetical binary distribution. That will illuminate > > a subsequent discussion about tooling and execution. > > > > Noah and I have each asked whether people *really* want a > > download-and-run executable. Recall the Steve Jobs quote, "You can't > > just ask customers what they want and then try to give that to them." > > > > Many users were briefly satisfied with build-couchdb's "just works" > > behavior, but ultimately disappointed that it requires manual > > startup/shutdown integration, manual log management, and manual > > upgrades. > > > > I strongly agree with Jan that the community needs turnkey CouchDB, > > but I share Noah's skepticism whether ./bin/couchdb is the best we can > > do. > > > > > 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. > > > > CouchDB as a desktop app is exciting. It reminds me of the joke that > > Linux is where you run web applications, Mac is where you develop web > > applications, and Windows is where you debug Internet Explorer bugs > > for web applications. Every desktop Couch user is a larval server > > Couch user, long-term developer, and community member. (Larva! Ew, > > it's nasty. It's so nasty.) > > > > IMO, as a CouchDB user, somebody who has to test upgrades and > > compatibility often: > > > > * An Ubuntu PPA > > * A free app in the Mac App Store > > * Whatever Windows does (.msi installer?) > > * An Android app, either in the Marketplace or maybe Amazon > > * An iPhone app in the App Store > > > > Notes: > > > > 1. If we achieved Jan's hypothetical ./bin/couchdb milestone, we would > > be very close to achieving the above list. Mostly it's jumping through > > a few procedural hoops. > > > > 2. All (most?) of these imply an official install, uninstall, and > > upgrade process, but we wouldn't have to write that ourselves (the > > "check for updates" feature) > > > > 3. The mobile apps are not an SDK, but like Android's DavDrive, > > http://davdrive-android.fun2code.de/ -- you run the app, it tells you > > your phone's IP, and you hit it with your browser (or CouchApp, or > > whatever). You could actually develop entire couch apps and replicate > > them to your production server. Quit the app, couch is gone. Remove > > the app, the data is gone. > > > > -- > > Iris Couch > > >
