From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?Q?Joonas_Saraj=c3=a4rvi?= Newsgroups: gmane.emacs.devel Subject: Re: Any interest in making Emacs available on Flathub? Date: Thu, 19 Apr 2018 08:53:06 +0300 Message-ID: <725ba9c8-1bde-817a-e74e-bf063eb2c4c0@iki.fi> References: <85e0d7a6-a2e7-7d3e-8230-82cbb968c634@cs.ucla.edu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1524117112 29705 195.159.176.226 (19 Apr 2018 05:51:52 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 19 Apr 2018 05:51:52 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 19 07:51:48 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f92Tz-0007ck-NV for ged-emacs-devel@m.gmane.org; Thu, 19 Apr 2018 07:51:47 +0200 Original-Received: from localhost ([::1]:51219 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f92W4-0008Nr-Tp for ged-emacs-devel@m.gmane.org; Thu, 19 Apr 2018 01:53:56 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42202) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f92VQ-0008NK-GN for emacs-devel@gnu.org; Thu, 19 Apr 2018 01:53:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f92VN-0000Dx-CW for emacs-devel@gnu.org; Thu, 19 Apr 2018 01:53:16 -0400 Original-Received: from mail-wr0-x236.google.com ([2a00:1450:400c:c0c::236]:43200) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f92VN-0000DB-1v for emacs-devel@gnu.org; Thu, 19 Apr 2018 01:53:13 -0400 Original-Received: by mail-wr0-x236.google.com with SMTP id u4-v6so10499655wrg.10 for ; Wed, 18 Apr 2018 22:53:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:references:to:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=4voXQdTTBCWO/E2ceFNYjts9QXkTl2u/pah72eCn3O4=; b=T5ziogIKDBIWAa0Sakj8F94CN4EffKSAI/8DLVEmIwSe/jYZ4PFwY9GJDpt8inQy57 99MW48n24b5hlB+5fTW7nr3BjlvJT93akinybFg39P/FuLkLw7oteXm/I9cDzPnoFVm6 9H3CRs/ZpSni69HyE7Z2V/J6DOOQpjucqdF51n2eZ9CsmfHiKA0tmJqSykoG+7yaV8qr m0RIbxCTUru5CW5qzVyhgmb7xcDCWJK2pprO+/L64bjixUwo6Be1C2nXU1o1tuiQStTT 286TbvFGYOuMGAcdfrDu1d1QfHlxrgcNLYZFipoaXy0t/lqxSLj2PgOZv/4um7fiFkNJ rGxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:references:to:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=4voXQdTTBCWO/E2ceFNYjts9QXkTl2u/pah72eCn3O4=; b=PX+GFgVibvDjH6odzDdfdgmBWLYN7s/eP71W1YTvCvGFwks5t5gsoMYQGhfG+DqDS2 dZhv5JG2YrslL8nxv8KNJSXQ0z0TcPkg+qHpmj6RNzCd4PMN+RlNxAviZJ0G/09LfqIQ CZCXi3I2d1T+ZXCUa3Tdcgps9aw1b8b9hGpYiee3KYmZyLH+csxlisQ2JaHBKqMxaPps cjAlZ7XnpvOBYxDH3ryi9PFHxsEDLYXb7fw4Uh0DwoV5tkN4+6iKMFkU0dFdsXekqljy Bh3D96aRbpJTMG9fSCfZ5TbMXb5aKj+agdHsO1tM5pi5ECYJs87dyRldf5Yqn3+DGBUO JamA== X-Gm-Message-State: ALQs6tB/Zj71Ps05N2+RcXhbfAtWQQu7MhLsRbCUMhy8+MSaWe58lRri Zd34EI3lY1zW6tECZWVA5cA5YJys X-Google-Smtp-Source: AIpwx48K785gCsdAi1gWwLiO+lb+2cqpYv/+fDhjkO7o5DPSKk5L4OaU6faHSsMTwN0QjuU3iIGxYA== X-Received: by 10.80.214.15 with SMTP id x15mr6770551edi.16.1524117191566; Wed, 18 Apr 2018 22:53:11 -0700 (PDT) Original-Received: from [10.0.0.147] (esm-84-240-106-35.netplaza.fi. [84.240.106.35]) by smtp.gmail.com with ESMTPSA id x49sm2069961edb.94.2018.04.18.22.53.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Apr 2018 22:53:10 -0700 (PDT) In-Reply-To: <85e0d7a6-a2e7-7d3e-8230-82cbb968c634@cs.ucla.edu> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:400c:c0c::236 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:224722 Archived-At: (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 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