Replace own "native" packaging entirely with AppImage
TheAssassin opened this issue · 4 comments
Instead of spending time on various "native" packaging formats such as .deb (which are built with tools that aren't intended to build packages for public use), this project should completely settle on AppImage.
A list of arguments why providing AppImages is a good idea is provided in #565:
- Applications packaged as an AppImage can run on many distributions (including Ubuntu, Fedora, openSUSE, CentOS, elementaryOS, Linux Mint, and others)
- One app = one file = super simple for users: just download one AppImage file, make it executable, and run
- No unpacking or installation necessary
- No root needed
- No system libraries changed
- Works out of the box, no installation of runtimes needed
- Optional desktop integration
- Optional binary delta updates, e.g., for continuous builds (only download the binary diff) using AppImageUpdate
- Can optionally sign your AppImages (inside the file) using gpg2
- Works on Live ISOs
- Can use the same AppImages when dual-booting multiple distributions
- Can be listed in the AppImageHub central directory of available AppImages
- Can double as a self-extracting compressed archive with the
--appimage-extractparameter
As you can see, there are some major advantages of providing fully portable bundles. Since I joined the project, AppImage has become a widespread and popular bundling format and most users either already know how to use them or can learn it with little effort.
Maintaining distribution-specific packages on the other hand doesn't make any sense for projects any more. It's anachronistic. You will always forget some distribution people want to use. You need the same amount of testing you need with a portable bundle. You do not have full control over all ingredients if you add, e.g., the JVM as a dependency. I could continue this list forever.
If you have little experience with AppImage and are sceptical, I highly advise you try it out! Please try this VisiCut AppImage built from the lastest master: https://transfer.assassinate-you.net/SHz0R2e2ve/VisiCut-1.9-184-gd9f022b8+devel-x86_64.AppImage
I get the point of having AppImage as an additional format. It is good to have a Linux equivalent to the "Portable Apps" from the Windows world.
However, I totally disagree with dropping other kinds of packages. AppImage has some systematic limitations and problems which make it impossible to use in certain scenarios. Experience from the Inkscape project shows that there are users for which an AppImage is not the appropriate target.
- From time to time, there are library incompatibilities because it bundles "half" of the desktop system but loads the other half from the host, see https://gitlab.com/inkscape/inkscape/-/issues/491 for one of the issues that Inkscape has had problems with this. Flatpak and Snap seem to avoid these issues by bundling almost everything.
- It is no proper packaging format, but rather a "portable app". For example, consider a classroom scenario with multiple computers. I can easily deploy a DEB package to multiple machines using ansible and everything works out of the box, e.g., start menu integration, "open file with" association, availibility for all users, et cetera. With AppImage there is much more effort.
From time to time, there are library incompatibilities because it bundles "half" of the desktop system but loads the other half from the host, see https://gitlab.com/inkscape/inkscape/-/issues/491 for one of the issues that Inkscape has had problems with this. Flatpak and Snap seem to avoid these issues by bundling almost everything.
Can be done with AppImage, too. For a vast majority of applications, however, "bundling everything" is unnecessary. Only a few non-glibc distributions (like Alpine and some really esoteric ones) require this approach. Otherwise, just building on some old CentOS or Ubuntu LTS does the trick.
That issue you linked is a bad example anyway, since it's most likely been fixed by bundling tools like linuxdeploy in the meantime.
It is no proper packaging format, but rather a "portable app". For example, consider a classroom scenario with multiple computers. I can easily deploy a DEB package to multiple machines using ansible and everything works out of the box, e.g., start menu integration, "open file with" association, availibility for all users, et cetera. With AppImage there is much more effort.
I work for an open-source company as a desktop application developer and we also found this problem recently. We're considering converting AppDirs (AppImage payload) into .debs and .rpms. This might solve the problem.
That said, the AppImage team is interested in developing better distribution and integration solutions for corporate environments. Unfortunately, these people rarely work with free software teams and do not communicate their requirements very well. AppImageLauncher has rudimentary support for a global /Applications directory, though.
I can provide one real-world example of a VisiCut AppImage deployment: I assist maintaining the IT infra in a lab nearby which uses VisiCut to operate some laser cutter. We use linuxmuster.net to build and distribute OS images to all the computers. We use AppImageLauncher as an integration helper, and deploy the master VM with ansible. It's not an issue at all to download the AppImage and have AppImageLauncher integrate it, as we can do this on a per-user basis.
If you insist on having "native packages" (for whatever reason, even if it's just "we've always had them and people depend on them"), then I suggest getting rid of checkinstall and building them properly.
To sum up the discussion: There are goods reasons to have both traditional app packages and AppImages. Each have their own limitations. So I am rejecting the request to drop all old packaging formats. --> Closing as "Won't fix".
Feel free to implement AppImage in parallel to the other formats, as a separate part of the GitHub Actions CI. For example you can take the output of the "Platform independent ZIP" and shuffle it around to get the AppImage.