Re: CouchDB 2.0 as Snap
I've done a little more work on the snapcraft.yaml, and integrated it with couchdb's build files. Pull request is https://github.com/apache/couchdb/pull/442 You can now ./configure && make snap Michael Hall mhall...@gmail.com On 10/06/2016 12:57 PM, Adam Kocoloski wrote: > Nice work Michael! > > I noticed your snap.ini overrides the bind address for both the cluster port > and the node-local port to have them listen on all interfaces. I think it’s > worth discussing whether we want that to be the default for the snap. There’s > a reason CouchDB defaults to listening only on the loopback interface. > Otherwise it looks good to me. > > Adam > >> On Oct 6, 2016, at 8:39 AM, Michael Hall wrote: >> >> Hey everyone, >> >> Sorry for the long delay, but I got some help from a coworker and >> between the two of us we have fixed the issue with the systemd service. >> >> If you put the attached files into a directory with the couchdb >> directory from ./rel/ you get after building, then run "snapcraft snap" >> you will get a ~40MB couchdb_2.0_amd64.snap (or whatever arch you're on) >> that, when installed with "snap install couchdb_2.0_amd64.snap >> --force-dangerous" will get you a running couchdb instance on >> http://localhost:5984 (see attached screenshot). The --force-dangerous >> is only needed because it's a local (untrusted) file, once it's being >> published into the snap store that won't be needed and user can install >> it with a simple "snap install couchdb". >> >> It's configured to put local.ini and couchdb.log into SNAP_DATA, which >> will be /var/snap/couchdb// and the actual database files in >> SNAP_COMMON which will be /var/snap/couchdb/common/. The first will be >> forward-copied every time you install a new version, the second is >> unversioned so you won't be duplicating large database files on upgrades. >> >> I'd like to get this into upstream now that it produces a working snap, >> and from there it can be improved as needed based on feedback from users. >> >> Michael Hall >> mhall...@gmail.com >> >> On 09/19/2016 07:36 PM, Robert Newson wrote: >>> Make a separate systemd service for epmd and have the couch one depend on >>> it. There is a parameter you can add to couch's vm.args file to prevent it >>> even trying to start epmd. >>> >>> Sent from my iPhone >>> On 19 Sep 2016, at 22:47, Michael Hall 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 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 wrote: I have attached the snapcraft.yaml
Re: CouchDB 2.0 as Snap
Ah, yes, I had originally built and run couchdb in an LXC container, so I changed the bind address so I could access it from outside the container. Since Snaps aren't containers that isn't needed, so it can be removed from snap.ini (and overwritten in local.ini when needed) Michael Hall mhall...@gmail.com On 10/06/2016 12:57 PM, Adam Kocoloski wrote: > Nice work Michael! > > I noticed your snap.ini overrides the bind address for both the cluster port > and the node-local port to have them listen on all interfaces. I think it’s > worth discussing whether we want that to be the default for the snap. There’s > a reason CouchDB defaults to listening only on the loopback interface. > Otherwise it looks good to me. > > Adam > >> On Oct 6, 2016, at 8:39 AM, Michael Hall wrote: >> >> Hey everyone, >> >> Sorry for the long delay, but I got some help from a coworker and >> between the two of us we have fixed the issue with the systemd service. >> >> If you put the attached files into a directory with the couchdb >> directory from ./rel/ you get after building, then run "snapcraft snap" >> you will get a ~40MB couchdb_2.0_amd64.snap (or whatever arch you're on) >> that, when installed with "snap install couchdb_2.0_amd64.snap >> --force-dangerous" will get you a running couchdb instance on >> http://localhost:5984 (see attached screenshot). The --force-dangerous >> is only needed because it's a local (untrusted) file, once it's being >> published into the snap store that won't be needed and user can install >> it with a simple "snap install couchdb". >> >> It's configured to put local.ini and couchdb.log into SNAP_DATA, which >> will be /var/snap/couchdb// and the actual database files in >> SNAP_COMMON which will be /var/snap/couchdb/common/. The first will be >> forward-copied every time you install a new version, the second is >> unversioned so you won't be duplicating large database files on upgrades. >> >> I'd like to get this into upstream now that it produces a working snap, >> and from there it can be improved as needed based on feedback from users. >> >> Michael Hall >> mhall...@gmail.com >> >> On 09/19/2016 07:36 PM, Robert Newson wrote: >>> Make a separate systemd service for epmd and have the couch one depend on >>> it. There is a parameter you can add to couch's vm.args file to prevent it >>> even trying to start epmd. >>> >>> Sent from my iPhone >>> On 19 Sep 2016, at 22:47, Michael Hall 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 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
Re: CouchDB 2.0 as Snap
Nice work Michael! I noticed your snap.ini overrides the bind address for both the cluster port and the node-local port to have them listen on all interfaces. I think it’s worth discussing whether we want that to be the default for the snap. There’s a reason CouchDB defaults to listening only on the loopback interface. Otherwise it looks good to me. Adam > On Oct 6, 2016, at 8:39 AM, Michael Hall wrote: > > Hey everyone, > > Sorry for the long delay, but I got some help from a coworker and > between the two of us we have fixed the issue with the systemd service. > > If you put the attached files into a directory with the couchdb > directory from ./rel/ you get after building, then run "snapcraft snap" > you will get a ~40MB couchdb_2.0_amd64.snap (or whatever arch you're on) > that, when installed with "snap install couchdb_2.0_amd64.snap > --force-dangerous" will get you a running couchdb instance on > http://localhost:5984 (see attached screenshot). The --force-dangerous > is only needed because it's a local (untrusted) file, once it's being > published into the snap store that won't be needed and user can install > it with a simple "snap install couchdb". > > It's configured to put local.ini and couchdb.log into SNAP_DATA, which > will be /var/snap/couchdb// and the actual database files in > SNAP_COMMON which will be /var/snap/couchdb/common/. The first will be > forward-copied every time you install a new version, the second is > unversioned so you won't be duplicating large database files on upgrades. > > I'd like to get this into upstream now that it produces a working snap, > and from there it can be improved as needed based on feedback from users. > > Michael Hall > mhall...@gmail.com > > On 09/19/2016 07:36 PM, Robert Newson wrote: >> Make a separate systemd service for epmd and have the couch one depend on >> it. There is a parameter you can add to couch's vm.args file to prevent it >> even trying to start epmd. >> >> Sent from my iPhone >> >>> On 19 Sep 2016, at 22:47, Michael Hall 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 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 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 'autotoo
Re: CouchDB 2.0 as Snap
Hey everyone, Sorry for the long delay, but I got some help from a coworker and between the two of us we have fixed the issue with the systemd service. If you put the attached files into a directory with the couchdb directory from ./rel/ you get after building, then run "snapcraft snap" you will get a ~40MB couchdb_2.0_amd64.snap (or whatever arch you're on) that, when installed with "snap install couchdb_2.0_amd64.snap --force-dangerous" will get you a running couchdb instance on http://localhost:5984 (see attached screenshot). The --force-dangerous is only needed because it's a local (untrusted) file, once it's being published into the snap store that won't be needed and user can install it with a simple "snap install couchdb". It's configured to put local.ini and couchdb.log into SNAP_DATA, which will be /var/snap/couchdb// and the actual database files in SNAP_COMMON which will be /var/snap/couchdb/common/. The first will be forward-copied every time you install a new version, the second is unversioned so you won't be duplicating large database files on upgrades. I'd like to get this into upstream now that it produces a working snap, and from there it can be improved as needed based on feedback from users. Michael Hall mhall...@gmail.com On 09/19/2016 07:36 PM, Robert Newson wrote: > Make a separate systemd service for epmd and have the couch one depend on it. > There is a parameter you can add to couch's vm.args file to prevent it even > trying to start epmd. > > Sent from my iPhone > >> On 19 Sep 2016, at 22:47, Michael Hall 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 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 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 >
Re: CouchDB 2.0 as Snap
wow thats super cool! thank you! On Mon, Sep 19, 2016 at 11:47 PM, Michael Hall 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 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 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 > 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 sa
Re: CouchDB 2.0 as Snap
> However at present they have a serious limitation wrt storage that is a > production showstopper - each snap version creates a new copy of > couchdb, and copies across the data files. I can't confirm yet if this BTW damjan on IRC pointed out SNAP_COMMON: writable area persistent across all revisions of the snap at http://snapcraft.io/docs/reference/env which if suitable would be great. A+ Dave
Re: CouchDB 2.0 as Snap
> >>> On Mon, Sep 19, 2016 at 4:47 AM, Michael Hall > >>> 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 Thanks Michael, These sound awesome. Snaps are looking great -- especially compared to the frustration of older debian / centos packaging tools that carry 2 decades of cruft under the hood. However at present they have a serious limitation wrt storage that is a production showstopper - each snap version creates a new copy of couchdb, and copies across the data files. I can't confirm yet if this is copy-on-write or not which at least would not be (initially) too bad, or a naive copy that duplicate disk blocks entirely. I suspect the latter as there is not much choice when it comes to cross-filesystem compatibility. Either way, if you have reasonably sized couches & viewed snaps will put you in a situation of needing to clean up old data to avoid running out of free disk space (e.g. during compaction) due to data kept in old snaps. We're not the only database to experience this constraint however and I'm sure a suitable solution will appear in due course. Go snaps! A+ Dave
Re: CouchDB 2.0 as Snap
Make a separate systemd service for epmd and have the couch one depend on it. There is a parameter you can add to couch's vm.args file to prevent it even trying to start epmd. Sent from my iPhone > On 19 Sep 2016, at 22:47, Michael Hall 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 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 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 >>> 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
Re: CouchDB 2.0 as Snap
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 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 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 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
Re: CouchDB 2.0 as Snap
> 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 > 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 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 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 >>
Re: CouchDB 2.0 as Snap
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? 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 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 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 >>> >> >
Re: CouchDB 2.0 as Snap
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 > 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 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 >>> >> > -- Professional Support for Apache CouchDB: https://neighbourhood.ie/couchdb-support/
Re: CouchDB 2.0 as Snap
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 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 Description: application/yaml
Re: CouchDB 2.0 as Snap
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 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 >
CouchDB 2.0 as Snap
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
