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 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

Attachment: snapcraft.yaml
Description: application/yaml

Reply via email to