From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alex Murray Newsgroups: gmane.emacs.devel Subject: Emacs as a snap package Date: Wed, 22 May 2019 10:31:13 +0930 Message-ID: <87o93vnvza.fsf@canonical.com> Reply-To: alex.murray@canonical.com Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="19173"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: mu4e 1.2.0; emacs 26.2 To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 22 03:17:53 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hTFt9-0004qE-Dz for ged-emacs-devel@m.gmane.org; Wed, 22 May 2019 03:17:51 +0200 Original-Received: from localhost ([127.0.0.1]:33812 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hTFt8-00074q-Bo for ged-emacs-devel@m.gmane.org; Tue, 21 May 2019 21:17:50 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:49493) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hTFsL-0006P6-SD for emacs-devel@gnu.org; Tue, 21 May 2019 21:17:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hTFdA-0006oL-2e for emacs-devel@gnu.org; Tue, 21 May 2019 21:01:21 -0400 Original-Received: from youngberry.canonical.com ([91.189.89.112]:44266) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hTFd9-0006nL-TI for emacs-devel@gnu.org; Tue, 21 May 2019 21:01:20 -0400 Original-Received: from 1.general.amurray.us.vpn ([10.172.65.220] helo=slate) by youngberry.canonical.com with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1hTFd7-00024r-CG for emacs-devel@gnu.org; Wed, 22 May 2019 01:01:18 +0000 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 91.189.89.112 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:236875 Archived-At: 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