Heya, nice effort here :) CouchDB 2.0 doesn’t use autotools. It mimics them minimally, but only insofar as it is useful for CouchDB and not for tools that expect autotools-like behaviour.
Over time, we want to make it so that the CouchDB install procedure fits right into normal tooling, but we are not there yet. Especially, `make install` is not available in 2.0. Instead, we have `make release` which produces a location independent directory `./rel/couchdb` that you can move into your system where you need it. There is no way to externalise log files or so from a setup perspective (although it can be configured in local.ini). HTH Best Jan -- > On 19 Sep 2016, at 17:48, Michael Hall <mhall...@gmail.com> wrote: > > I have attached the snapcraft.yaml file I've started. This is used by > the snapcraft tool to build and package a .snap file (just run > `snapcraft snap` in the same directory as this file). > > You can see that most of it is dedicated to grabbing the source, > specifying build dependencies (build-packages) and runtime dependencies > (stage-packages). The 'autotools' plugin will run the standard > "./configure; make; make install" steps on the source, and while the > output of those claims to be successful, make returns with a non-zero > status code ($?=2) which causes snapcraft to abort after building. > > As mentioned previously, this could be significantly simplified if it > could use the build processes already in place. In that case the > snapcraft.yaml would only need to be pointed to the local directory > containing the binary files needed to include in the .snap package. If > somebody wants to give that a try, I can put together a new > snapcraft.yaml that will do that. > > > Michael Hall > mhall...@gmail.com > > On 09/19/2016 02:56 AM, Constantin Teodorescu wrote: >> It would be nice to have two snap packages: >> - CouchDB 2.0 UN-CLUSTERED >> - CouchDB 2.0 CLUSTERED VERSION >> >> That will encourage a lot of "standalone" CouchDB users to upgrade to a 2.0 >> version without the clustering overload stuff, and thus make a big pool of >> 2.0 testers and bug-reporters! >> Teo >> >> >> On Mon, Sep 19, 2016 at 4:47 AM, Michael Hall <mhall...@gmail.com> wrote: >> >>> First off, congratulations on the upcoming 2.0 release! >>> >>> I would love to see this new version available as a Snap package for >>> users of Ubuntu 16.04 LTS, since the archive version will be frozen on >>> 1.6.0 for the next 5 years of it's lifecycle. >>> >>> Snaps are self-contained packages that include all of the dependencies >>> they need, which lets them run as you (the upstream) intended across new >>> releases of Ubuntu, Debian, Arch, and many other distros. They run in a >>> sandbox that protects them from changes made to the user's system, but >>> with a number of optional interfaces if you need deeper interaction or >>> to share data with other apps. >>> >>> Every snap includes its own file tree, and is run on top of the same >>> base image regardless of distro or form factor. This keeps the >>> application's own files isolated from other apps and the host system, in >>> a read-only filesystem, which makes updating them safe and simple while >>> keeping you in control of the whole stack that your application runs on. >>> The snappy runtime then provides writable areas for storing both >>> versioned and unversioned data, as well as system-wide or per-user data. >>> >>> We also provide a Snap Store, which combines the speed of >>> self-publishing with the discoverability of a central archive. It is >>> used by default across all Ubuntu 16.04 flavors and derivatives, and any >>> distro where snaps have been enabled. Thanks to Snap's confinement, >>> applications can be published immediately after uploading. This means >>> that your application and updates are available to tens of millions of >>> users as soon as you press the button. >>> >>> I started the work on producing a Snap package for Couchdb 2.0, but as I >>> couldn't find a binary release I had to try building it from source and >>> unfortunately I was not successful on that step. I am happy to share my >>> packaging configuration with anybody here who knows the build process >>> better than me, but it would be even simpler to create the snap package >>> at the end of whatever process you already have to build binary >>> releases. I am happy to help with either or both approaches, and you can >>> also learn more about the snap format and tools here: http://snapcraft.io/ >>> >>> -- >>> Michael Hall >>> mhall...@gmail.com >>> >> > <snapcraft.yaml> -- Professional Support for Apache CouchDB: https://neighbourhood.ie/couchdb-support/
