Open binary-manu opened 3 years ago
CendioOssman
commented
3 years ago We generally want to avoid having to do packaging work. We'd prefer if we can focus on the software itself. :)
If AppImage:s require custom modifications, then I'm afraid that makes them even less appealing. These days snap and flatpak are the dominant players for contained applications. And they do not require any application modification as far as I know. Have you had a look at them?
binary-manu
commented
3 years ago We generally want to avoid having to do packaging work.
Quite understandable :)
While I have used both snaps and flatpaks, I only skimmed through how to make flatpaks from scratch, so I'm unable to contribute on that at the moment. This may well be the topic for a different feature request, if I ever get a chance to study that subject, or someone else decides to lend a hand.
Meanwhile, since this request has not been closed yet, I'd try and add some more details that may help your decisions.
A recent DistroWatch opinion poll about preferred app packaging standards showed that users tend to equally prefer AppImages and Flatpaks over snaps.
While Flatpaks are great for many things, I think that for a relatively lightweight app such as the VNC viewer, the one file = one app approach wins in simplicity. You don't need client side tools pre-installed (flatpak) to run them. There are no dependencies on runtimes (altough I think Flatpaks can avoid this if every library is bundled with the app itself) and AppImages can go in your USB drive, ready to launch from a read-only filesystem (and maybe flatpaks can do this too altough it seems that the app should still be imported to the local system). For a sysadmin that may need to borrow a desktop to run the VNC viewer and do some stuff, it would be easier to just keep the AppImage on their USB drive.
Maybe it was not clear from the previous comment, but I was proposing to do the required modifications to the VNC viewer myself. A potential PR would include all required modifications to the source code, the CMake build files (if required), helper scripts to build the AppImage and maybe GitHub Actions to automatically test the packaging. Once this modifications are in place, you should be able to forget about AppImage completely, except to build them by running a script at release time. I expect that long-term maintenance effort should be very low. The Appimage spec has remained stable for a while now, and the full doc is probably just as long as an intro to Flatpaks ;)
The key point about modifying the viewer code is that the app should be relocatable, thus independent from CMAKE_INSTALL_PREFIX, and load all its external files relative to the executable. The Windows version already does this, but *NIX code depends on hardwired paths under /usr for some things, like loading locales. While changing this behavior is essential for correct AppImage packaging, it can also be useful on its own, as in the case of the semi-static build, if it is meant to be used as a portable program (which is mentioned in BUILDING.txt). For example, the official Linux release v1.11 found on SourceForge can be unpacked in my home and run, but it won't load locales or icons unless I place the extracted folders under /usr, something I can't do unless I'm root, and something that no good root would do since that is package manager's territory. That is, unless I'm missing something about how the release is to be used (as a source for repackaging, maybe?).
If you agree that making the viewer relocatable is good, turning it into an AppImage is simple. Tools like linuxdeploy make this task almost a breeze since they already create the correct file structure and copy all required libraries inside the AppImage, patching them with an RPATH. As an example, this is an AppImage build script I used for one of my projects.
Let me know.
Rikitik
commented
3 weeks ago I would like this very much too, especially the serve part
Is your feature request related to a problem? Please describe. As a heavy TigerVNC user, I like the idea of portable one-file vncviewer distributions for Linux systems, just like there is a portable executable for Windows. It is easy to keep different versions alongside each other, no problems with missing dependencies and no root privileges required for installation.
Describe the solution you'd like I'd like for official TigerVNC releases to also provide an AppImage version of the VNC viewer component. There are unofficial AppImages out there, but they are behind the latest release.
Describe alternatives you've considered Among the most widespread packaging formats, AppImage gives users something that is largely independent from the lifecycle of the underlying system, is radically simple (one app=one file) and has few system dependencies (basically FUSE). Multiple AppImage versions are easy to manage even from shell scripts. Both snaps and flatpaks are more complex. Also, creating an AppImage is a relatively simple task. That being said, this is highly subjective as different people tend to have strong and diverse ideas about packaging formats.
The next best shot would be the semi-static TigerVNC build as described in the docs, which is also marked as "very fragile" and "may require tweaking". An AppImage is a plain dynamically linked build with RPATHs packaged in a single file. Desktop integration is also easier if appimaged is optionally employed.
Additional context I have some experience with AppImages and could work on this issue in my spare time. However, I would like to know if the maintainers have any real interest in seeing this packaging option added. Deploying an app as an AppImage requires the executable to be relocatable, thus independent from the installation prefix. A quick glance at current vncviewer code shows that this is not the case, as there are a few instances of hardwired paths (icons loading and locale files). Turning them into something dynamic is not a daunting task, but the changes should then be merged upstream. Also, some additions to GitHub Actions will be needed to build the AppImage.
If you guys think this is valuable, drop a line. Otherwise, feel free to close this request.