[Packaging Request] Linux binaries in 'AppImage' format

[totaam]

Issue migrated from trac ticket # 1748

component: packaging | priority: major

2018-01-19 18:29:54: pdfkungfoo created the issue

---

I would like to use the latest+greatest Xpra version on Debian Linux (Stretch) and openSUSE Tumbleweed.

However, on Debian it is version 0.17.6 only which I can obtain through the official repository. For Tumbleweed, I cannot find xpra at all!

An very user-friendly option would be a Linux binary packaged as an "AppImage". If you never heard of that: you can compare this to a .dmg package for macOS, with the difference that:

• where the DMG requires (a very simple) installation process, the AppImage does not need "installation" at all (only setting the executable bit) and
• where the installed .dmg expands into an "*.app" directory, an AppImage remains a compressed SquashFS file system packaged into a single file even during execution time (when it is automatically FUSE-mounted to a temporary mount point and run via simple embedded "AppRun" helper binary).

AppImages implement the elegant "One App == One File" paradigm. They have the following properties:

• do not need root privileges to get them working;
• do not need a package management system to get them "installed";
• do not need any pre-requisite "platform" or package manager to work;
• one and the same AppImage can work on multiple Linux distributions released in the last 3-4 years;
• AppImages work from any location (even thumbdrives or remotely mounted SMB/Samba, SSHFS, NFS or other shares);
• AppImages can be automatically upgraded to the newest version via a (zsync-powered) binary delta download mechanism if the AppImage packagers embed a suitable "updateinfo" string into the package).

AppImages are relatively simple to package with the help of the AppImageKit tools provided on GitHub here: AppImageKit on GitHub and linuxdeployqt on GitHub.

I'm sure the AppImageKit developers hanging around in IRC will be happy to help should you be interested to implement this: #AppImage channel on Freenode.

[totaam]

I would like to use the latest+greatest Xpra version on Debian Linux (Stretch) and openSUSE Tumbleweed.

FYI: the latest version of xpra is always available in the xpra repositories for all distribution supported, including Debian Stretch.

As for supporting appimage or even flatpak, it would be great but there are a number of issues:

• first and foremost:
  We will need to continue to package for the ~50 platform+distro+arch combinations we support, only adding to the packaging workload and maintenance burden.
• this is not a workable solution for servers, which need to integrate with the system as a service (logind+udev, selinux, printing integration, etc)

On the other hand, it may simplify the issue of supporting out of date distros like centos6.

[totaam]

centos6 could be used as a base for the appimage, the difficulty is that we would need to build:

• python 2.7 (or even python 3.6 if we want to target gtk3)
• latest gtk2
• dozens of media libraries
• gstreamer 1.x (since 0.10 is no longer supported in xpra)
• ~50 python modules

The total number of packages we would need to build is probably similar to what we do on macos, and that's ~130!
This can be used as reference too, see the jhbuild modulesets.
And maybe we can use jhbuild on centos to leverage the work already done? Worth a try.

---

Flatpak: FLATPAK IN DETAIL, PART 2

[totaam]

This captures my thoughts on this perfectly: Flatpak - a security nightmare: The way we package and distribute desktop applications on Linux surely needs to be rethinked, sadly flatpak is introducing more problems than it is solving
(and the same goes for appimage)

[totaam]

2018-10-12 16:48:04: pdfkungfoo commented

---

One of the problems concerning Flatpak is described as (my paraphrasing) "bugs and security problems which were fixed upstream long ago still are not fixed in the Flathub packages".

The same certainly does not go for AppImage, because one of the non-technical, philosophical core ideas of AppImage is that the upstream developers can use it to provide their own self-built binaries (not just source code) remaining firmly under their own control to whoever wants them, downloadable from their own website and working on most recent and not-so-recent Linux distributions. Which is what this packaging request ticket asks for....

Your conclusion "same as for Flatpak goes for AppImage" is solely yours, not to be found on the flatkill.org site. I would like to see some corrobating evidence for your conclusion, if there is. Maybe I'm wrong, but currently don't see how.

[totaam]

The same does apply to appimage, because the end result is the same: appimage also bundles libraries, there is absolutely no hope that we can make a new image release every time there is an update to any of the ~150 libraries we depend on. Which means that the images would be out-of-date by default, with the security responsibility becoming ours instead of the distros.
It is foolish to think that individual applications can possibly take on the role of a distribution, yet that's what bundling requires if you care about the security aspect.

[totaam]

Unless someone else steps up, I don't have time for this.

[totaam]

Apart from the important points raised above, the best summary of why this is unlikely to happen is Flatpak Is Not the Future

[brechtm]

Related: I tried building Xpra using spack, but got stuck at the pycairo dependency.