[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Any interest in making Emacs available on Flathub?

From: Joonas Sarajärvi
Subject: Re: Any interest in making Emacs available on Flathub?
Date: Thu, 19 Apr 2018 08:53:06 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

(Sorry Paul, I first sent this only to you but intended to respond to list so here it goes again)

Paul Eggert kirjoitti 18.04.2018 klo 22:31:
It'd be helpful to have Emacs easily distributable via Flatpak. Since I'm not a Flatpak expert, could you help fill us in on what's needed? In your draft <https://bitbucket.org/muep/org.gnu.emacs/> I see three files:

* A patch to src/xterm.c that is installed on Savannah, so this is done already (in the next Emacs version, anyway).

* Adding info about release 25.3 to etc/emacs.appdata.xml. Should this info be all the Emacs releases (see etc/HISTORY) or just the releases tuned for Flatpak? If so, presumably it should start with the first release that works well with Flatpak.

* A file org.gnu.Emacs.json, which I suppose we could copy to etc/org.gnu.Emacs.json in the master Emacs distribution. Or perhaps there's another better place for it? How should this file evolve as Emacs makes further releases? Presumably each release should clear out the patches from the "modules" section?

Just to get an example of what this would finally look like, the setup for LibreOffice [1] looks quite typical. There is a separate git repository with the json file that describes the application to a tool called flatpak-builder, and then some patches. Likely when Emacs gets submitted by someone into Flathub, it would have a similar repository at [2] but currently this does not exist. The Flathub project then runs a build service [3] that detects changes in these repositories and builds and publishes the user-installable flatpak.

Ideally all of these patches would get some corresponding changes in the master emacs distribution, making the separate patches unnecessary.

On new Emacs releases, the only change certainly required in the flatpak packaging is to update the source URL and the sha256 checksum of the source archive in the json. Patches (if any) may need to be dropped or rebased against updated GNU Emacs source.

I am not sure if the org.gnu.Emacs.json should be copied into the Emacs master distribution, but I suppose it is up to the GNU Emacs maintainers. Basically it is just part of choosing what kind of workflow Emacs wants to have on maintenance of this metadata file. As long as it is only a few "outsiders" like me working on it, it might be easier to keep it just in the flathub repository. We can easily keep it so that Emacs is able to later decide that the canonical source of that file is in the Emacs master repository and the one in flathub repository is just copied there when updates need to be released.

A few more questions:

* I notice that your org.gnu.Emacs.json file differs from that of others. Is it important that this file be reasonably standard for everybody's convenience, or is it merely a template for people to configure? Is it something that "make" should construct, when you're building Emacs? That sort of thing.

My impression is that this could easily just be hand-written and kept under version control. The file is pretty short, so I'd expect that it is not very sensitive to style issues either. It could be also generated from a template, so that some program fills in the version number and possibly some other details, but at the moment I do not see much need for that.

* Would it make sense for the top-level Emacs makefile to have a "flatpak" action, so that "make flatpak" does something for Flatpak that "make install" does for a native installation? If so, what should "make flatpak" do?

In my opinion, this would be unnecessary. Flatpak-builder already does adaptation in the other direction, so that it knows how e.g. an usual configure-make-make-install -style installation is done. However, I think such a mechanism could be done if desired.

If this kind of command was done, I think it could run something like:
flatpak-builder --install --user path/to/build/directory path/to/org.gnu.Emacs.json

I am not sure about where everyone would want to have their temporary build directory, but it could be something along those lines.

* If we want to also support AppImage, Snap, etc., how should we arrange for this in an economical and intuitive way in the source?

Again not sure, but I think it is good to keep them clearly separated from application source. So right now I think it makes sense for them to even be outside the master repository, but also in case they get included, they should initially be something that is only used in case someone makes a conscious decision to use them. So maybe have some top-level directory and then under that a directory for flatpak, another for appimage and so on? I am not familiar at all with what kind of files e.g. snap or appimage require, but I'd imagine that there is something that is analogous to the flatpak json file or rpm .spec file or suchlike.

Does Emacs currently include packaging setups e.g. for GNU/Linux distributions? I tried looking for them for a bit but did not find any.

[1] https://github.com/flathub/org.libreoffice.LibreOffice
[2] https://github.com/flathub/org.gnu.Emacs
[3] https://flathub.org/builds

reply via email to

[Prev in Thread] Current Thread [Next in Thread]