couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: CouchDB 2.0 as Snap
Date Mon, 19 Sep 2016 17:19:11 GMT

> On 19 Sep 2016, at 19:13, Michael Hall <mhall119@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
> mhall119@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 <mhall119@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
>>> mhall119@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 <mhall119@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
>>>>> mhall119@gmail.com
>>>>> 
>>>> 
>>> <snapcraft.yaml>
>> 

-- 
Professional Support for Apache CouchDB:
https://neighbourhood.ie/couchdb-support/


Mime
View raw message