-
Notifications
You must be signed in to change notification settings - Fork 64
AppImage Notes
The AppImage is a great format for distributing programs on Linux, and I don't think it's wise to switch formats due to how useful and flexible the AppImage is. However, it does have it's quirks and here's what I've discovered.
AppImages (through linuxdeployqt) will contain all necessary libraries the programs contained inside the AppImage need to be ran... except for glibc. For some reason the author says that glibc is universal across installations and therefore including it is redundant. While this is true, the issue is that if the AppImage is made on a more recent version of Ubuntu, older versions won't be able to run it. This doesn't apply to just Ubuntu, as it revolves directly around the glibc version, so this issue will pop up if you try to run an AppImage on an OS with an old version of glibc. The suggested way to get around this issue is to build and compile on said old OS.
The AppImage, in order to run, needs to be able to use FUSE to create a temporary mount point as a non-root user to mount the contents of the AppImage too. This resulting directory is read-only and should be unmounted once the process and subprocess (AppRun) are terminated. However, if one starts a lot of CaPTk processes, the disk space shoots up.
In most cases you might want to suggest to someone to extract the AppImage. What happens is that the contents of the AppImage will be extracted to a folder called squashfs-root, but all of the content is exactly the same as the AppImage, except there's no intermediate layer to defer to the CaPTk executable in squashfs-root/usr/bin
. A user that does not have FUSE or has issues with too many mounts being created would benefit from extracting the AppImage.
CaPTk, 2022 | About CaPTk | Please report any issues here