Emacs as a snap package

Emacs as a snap package

[Alex Murray]

Hi,

I have recently been working on[1] creating a snap[2] package for Emacs
to be distributed via the snapcraft.io store[3] - similar to
Flatpak+Flathub this provides a cross-distribution mechanism for
delivering applications to end users. First some background on snaps etc
and then onto some specific proposals.

The snap ecosystem includes things like multiple 'channels'[4] for a
package ('edge' for daily "unstable" builds, 'stable' for known stable
releases, and 'candidate' and 'beta' for somewhere in between), plus
automatic updating of applications, rollback on failed upgrades etc.

An automatic build service is also available[5] which can provide
automatic builds on new commits, for a variety of architectures (i386,
amd64, armhf, arm64, s390x & ppc64el) which get automatically published
to the 'edge' channel.

I believe this would create a compelling option for providing official
Emacs builds which work across multiple Linux distributions, and could
also serve to more easily allow testing of release candidates etc via
the 'candidate' channel or similar.

To create a snap of a particlar application, a snap recipe is required -
this is a simple yaml description of the build dependencies etc (similar
to a RPM spec file / Debian rules etc) - the current one which I have
created is based on the build deps etc from the emacs 26.1 package in
Debian as can be seen at [1]. This uses the official emacs-26.2 tarball
to build, but it could instead specify a git tree+branch etc.

Finally, to publish a snap in the snapcraft.io store a Ubuntu One
account[6] is required.

I had initially planned to just publish this myself in the snap store[7]
(and would still be happy to do this and maintain it going forward for
future Emacs releases if required) however, if this could be integrated
and maintained directly within the upstream Emacs git repository _and_
published in the Snap store by an official 'GNU Project' or similar
account I think that would make a more compelling offering.

As such I would be keen to get feedback on the following:

1. Maintain an official snapcraft.yaml recipe for Emacs within the Emacs
git tree across both master and the various release branches which can
be used to build 'official' Emacs snaps directly from the git source
tree.

2. Register an official GNU Project account for the Snap store and use
this to publish these official snap builds.

3. Optionally, use the build.snapcraft.io service to provide automated
builds directly (similar to the current emacs-snapshot PPA[8] which is
widely used).

Thanks,
Alex


[1] https://github.com/alexmurray/emacs-snap/
[2] https://docs.snapcraft.io/
[3] https://snapcraft.io/store
[4] https://docs.snapcraft.io/channels
[5] https://build.snapcraft.io
[6] https://login.ubuntu.com/
[7] https://forum.snapcraft.io/t/classic-confinement-name-request-and-aliases-for-emacs/11367
[8] https://launchpad.net/~ubuntu-elisp/+archive/ubuntu/ppa

Re: Emacs as a snap package

[Paul Eggert]

On 5/21/19 6:01 PM, Alex Murray wrote:
> As such I would be keen to get feedback on the following:
>
> 1. Maintain an official snapcraft.yaml recipe for Emacs within the Emacs
> git tree across both master and the various release branches which can
> be used to build 'official' Emacs snaps directly from the git source
> tree.

I assume this has the function of the already-existing .gitlab-ci.yml 
file that Emacs already has in the master branch. That file is for 
GitLab continuous integration builds, whereas snapcraft.yaml would be 
for snap.

This raises the issue: if we start supporting multiple CI platforms, 
perhaps we should put build-instruction files into a new directory 
(build-aux/ci, say), rather than cluttering the toplevel directory with 
such files.


> 2. Register an official GNU Project account for the Snap store and use
> this to publish these official snap builds.
>
> 3. Optionally, use the build.snapcraft.io service to provide automated
> builds directly (similar to the current emacs-snapshot PPA[8] which is
> widely used).

These are topics for RMS to address, I'd think. I'll CC: him.

Re: Emacs as a snap package

[Alex Murray]

On Thu, 2019-05-23 at 03:14:27 +0930, Paul Eggert wrote:

> I assume this has the function of the already-existing .gitlab-ci.yml file
> that Emacs already has in the master branch. That file is for GitLab
> continuous integration builds, whereas snapcraft.yaml would be for snap.
>

Similar but different - snap is both a build and a package mechanism -
so it describes both the dependencies / how to build, plus packaging
info such as version, description, sandboxing requirements etc.

> This raises the issue: if we start supporting multiple CI platforms,
> perhaps we should put build-instruction files into a new directory
> (build-aux/ci, say), rather than cluttering the toplevel directory with
> such files.
>

In general snapcraft.yaml would live in a snap/ subdirectory off the
top-level.

>
>> 2. Register an official GNU Project account for the Snap store and use
>> this to publish these official snap builds.
>>
>> 3. Optionally, use the build.snapcraft.io service to provide automated
>> builds directly (similar to the current emacs-snapshot PPA[8] which is
>> widely used).
>
> These are topics for RMS to address, I'd think. I'll CC: him.