wow thats super cool! thank you!
On Mon, Sep 19, 2016 at 11:47 PM, Michael Hall <mhall...@gmail.com> wrote: > Thanks to help from Jan and Wohali on IRC, I was able to manually build > couchdb from the 2.0.x branch, and then snap-package the resulting > binary. I have attached the snapcraft.yaml used for this. Put this file > in a directory with the couchdb directory built in ./rel/, then run > "snapcraft snap" to build couchdb_2.0_amd64.snap > > The snap package will create a systemd service file for running couchdb > as a daemon, but due to the way it launches a background epmd process > this isn't working right (systemd thinks it failed to start and keeps > trying to restart it until it givesup). Because of that, I've also > included a /snap/bin/couchdb.run which will manually kick it off, but > this should only be temporary until the daemon process can be fixed. > > One last caveat, you'll need to copy /snap/couchdb/current/etc/*.ini > into /var/snap/couchdb/current/ and mkdir /var/snap/couchdb/current/data > before running it. This could be done at runtime either by couchdb > itself, or with a custom wrapper script for the snap command. > > Michael Hall > mhall...@gmail.com > > On 09/19/2016 01:19 PM, Jan Lehnardt wrote: > > > >> On 19 Sep 2016, at 19:13, Michael Hall <mhall...@gmail.com> wrote: > >> > >> Maybe I'm using the wrong branch, because the Makefile has an "install" > >> target but not a "release" target. I'm using developer-preview-2.0, if > >> that's not the correct one, which should I use? > > > > Please use the `2.0.x` branch. > > > > Best > > Jan > > -- > > > >> > >> Michael Hall > >> mhall...@gmail.com > >> > >> On 09/19/2016 12:10 PM, Jan Lehnardt wrote: > >>> 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> > >>> > > >
