Xpra: Ticket #1748: [Packaging Request] Linux binaries in 'AppImage' format

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:

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

AppImages are relatively simple to package with the help of the AppImageKit tools provided on GitHub here: 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.

Sat, 20 Jan 2018 03:44:26 GMT - Antoine Martin: status, description changed; milestone set

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:

https://imgs.xkcd.com/comics/standards.png 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.

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

Sun, 22 Apr 2018 17:09:18 GMT - Antoine Martin:

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

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: https://xpra.org/trac/browser/xpra/trunk/osx/jhbuild. And maybe we can use jhbuild on centos to leverage the work already done? Worth a try.


Wed, 10 Oct 2018 05:26:58 GMT - Antoine Martin:

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)

Fri, 12 Oct 2018 15:48:03 GMT - Kurt:

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.

Fri, 12 Oct 2018 19:29:12 GMT - Antoine Martin:

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.

Wed, 20 Mar 2019 04:59:10 GMT - Antoine Martin: milestone changed

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

Sat, 23 Jan 2021 05:32:45 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1748