couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Hall <>
Subject Re: CouchDB 2.0 as Snap
Date Mon, 19 Sep 2016 21:47:56 GMT
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/ 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

On 09/19/2016 01:19 PM, Jan Lehnardt wrote:
>> On 19 Sep 2016, at 19:13, Michael Hall <> 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
>> 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 <> 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
>>>> On 09/19/2016 02:56 AM, Constantin Teodorescu wrote:
>>>>> It would be nice to have two snap packages:
>>>>> - CouchDB 2.0 UN-CLUSTERED
>>>>> 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
>>>>> 2.0 testers and bug-reporters!
>>>>> Teo
>>>>> On Mon, Sep 19, 2016 at 4:47 AM, Michael Hall <>
>>>>>> First off, congratulations on the upcoming 2.0 release!
>>>>>> I would love to see this new version available as a Snap package
>>>>>> users of Ubuntu 16.04 LTS, since the archive version will be frozen
>>>>>> 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
>>>>>> 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,
>>>>>> with a number of optional interfaces if you need deeper interaction
>>>>>> 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,
>>>>>> a read-only filesystem, which makes updating them safe and simple
>>>>>> keeping you in control of the whole stack that your application runs
>>>>>> The snappy runtime then provides writable areas for storing both
>>>>>> versioned and unversioned data, as well as system-wide or per-user
>>>>>> We also provide a Snap Store, which combines the speed of
>>>>>> self-publishing with the discoverability of a central archive. It
>>>>>> 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
>>>>>> 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
>>>>>> unfortunately I was not successful on that step. I am happy to share
>>>>>> 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:
>>>>>> --
>>>>>> Michael Hall
>>>> <snapcraft.yaml>

View raw message