Re: Any interest in making Emacs available on Flathub?

[Joonas Sarajärvi]

(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