How do distros add support for running AppImages?

Developers
1

I’ve looked through the documentation on appimage.org and on the github wiki. I see docs for AppImage users and AppImage packagers (generally the upstream author is also the AppImage packager). But, I can’t find documentation for distros that want to add support for running AppImage packaged applications.

  • What kernel config is required for running AppImages?
  • I’ve seen mentions of appimaged. What other software would I need to package for a distro to provide the best user experience running AppImage?
  • What libraries (and which version) are expected to be provided by the AppImage host?
  • What are the optional dependencies (like I saw something about appimaged using firejail) that a distro might consider?

I am only asking about requirements for running the AppImages. I’m not talking about how a distro can support creating AppImages (I believe with AppImageKit and pkg2appimage). So, for a distro that is only interested in running (not creating) AppImages, what are the requirements?

Is this documented in the AppImage spec?

2

I had the same issue.

I had the feeling that despite being smaller than competitor it was more fragmented: packages comes from here and there, and no official desktop integration.

In my opinion there should one package that provides the builder and complete desktop integration.

3

Welcome @cognifloyd. That is an excellent question.

Hope this clarifies things a bit, feel free to reach out in #AppImage on irc.freenode.net where ~80 people hang out most of the time to discuss all things AppImage.

May I ask which distro you are working on?

1 Like
4

Hello abique maybe you like https://github.com/probonopd/go-appimage/? Feel free to open issues there if you think that things should be changed.

5

My machine is Gentoo Linux. AppImages seem to work, but I want to make some ebuilds (ebuild = describes how portage, gentoo’s package manager, can build an application from source) for whatever it takes to have top notch integration of AppImage.

I’d also like to be able to build or edit AppImages for use on other platforms (like RHEL/CentOS and Debian) on my gentoo box without pulling up a VM for one of the other Distros. But, that’s secondary and was not part of my question in this thread. :smiley: Once I get ebuilds for AppImageD and maybe a meta package for general appimage support (to grab all the optional deps based on use-flags), then I can work on ebuilds for AppImage creation/editing support.

6

Oh, and the reason I asked about kernel config, is because on Gentoo linux, users compile their own kernels. So, one of the ebuilds needs to check the kernel config to make sure any required options are set and to suggest any optional kernel config.

7

Hmm. On my 5.4.38 kernel that includes the gentoo patchset (ie I use sys-kernel/gentoo-sources), I don’t have debian’s patch for kernel.unprivileged_userns_clone nor do I have kernel.restrict_userns (which I found mentioned on LWN). Does AppImageD require that this be disabled, or is disabling this just a “best practice” for security with the AppImage containers? What are the risks if this kernel or the mainline/vanilla kernel without these patches are used to run AppImages?

I should probably mention that 4.4.221 is the oldest kernel available in gentoo’s main ebuild repo, or if you go purely vanilla (w/o the gentoo patchset), then 5.4.39 is the oldest.

8

OK, I just went through that excludelist to see what packages my meta-package should depend on.
There are a few issues:

  1. libthai is not available on Gentoo. I assume this is only needed if using Thai language support, so I’ll skip it for now.
  2. glibc (v2.30) does not provide: libcidn.so.1, libnss_nisplus.so.2, libnss_nis.so.2
    • For libnss_nis*, I could use this gentoo package: sys-auth/libnss-nis, but it is not stable yet. It seems that it was extracted from glibc at some point.
    • CentOS 8’s glibc (v2.28) and Fedora 30’s glibc (v2.29) also do not provide libcidn or libnss_nis, so Gentoo is not unique here.
    • Debian 10’s libc6 (v2.28) is missing libcidn, but includes libnss_nis*.
    • CentOS 7’s glibc (v2.17) and Debian 9’s libc (v2.24) on the other hand include both libcidn and libnss_nis*.

So, how likely is it that missing these will affect running AppImages?

Also, does the host system need to support things compiled with gcc <3.4? If so, then I need to depend on sys-libs/libstdc++-v3 (v3.3.6), but that is not considered “stable” on gentoo.

9

My machine is Gentoo Linux.

Sorry to say, but that is already a red flag right there. No 2 Gentoo machines ever seem to be entirely identical, so Gentoo appears to be more a “moving target” than a stable platform.

I want to make some ebuilds (ebuild = describes how portage, gentoo’s package manager, can build an application from source) for whatever it takes to have top notch integration of AppImage

Please be aware that because Gentoo is a “moving target”, it is not one of the supported distributions for the AppImage format. Many AppImages may run, but it’s coincidence. We have no way to test it, because if I test it on my Gentoo machine it may still fail on yours.

Oh, and the reason I asked about kernel config, is because on Gentoo linux, users compile their own kernels.

This is what I mean with “moving target”. It’s hopeless imho. I would not be surprised if some Gentoo users don’t have FUSE support in their kernel and then complain because they don’t understand what is going on when their AppImage cannot mount itself.

So, one of the ebuilds needs to check the kernel config to make sure any required options are set and to suggest any optional kernel config.

Best suggestion I can give is to 1:1 copy the Ubuntu kernel config, as most users are using some variant of Ubuntu and that is what we mainly optimize for.

libthai is not available on Gentoo. I assume this is only needed if using Thai language support, so I’ll skip it for now.

Then AppImages needing it will fail.

glibc (v2.30) does not provide: libcidn.so.1 , libnss_nisplus.so.2 , libnss_nis.so.2

Do you know whether earlier versions provided them? I am not sure what do do about this situation, but I am really unhappy that the most fundamental of all packages besides the kernel is apparently still a “moving target”.

So, how likely is it that missing these will affect running AppImages?

I don’t know. The distributions I am running do ship those, so I didn’t have to worry so far. We didn’t hear complaints from users either.

libstdc++-v3

Have never heard about this one. Most apps these days are concerned with libstdc++6.

I appreciate your energy, but I do feel you are working on a lost cause. The point of Gentoo is that users can configure everything like they want to, and as a result the system is unsupportable.

The most pragmatic approach to run an AppImage is to pop in a (X,…)ubuntu Live ISO (= a known system) and run your AppImages there.

10

Do you know whether earlier versions provided them? I am not sure what do do about this situation, but I am really unhappy that the most fundamental of all packages besides the kernel is apparently still a “moving target”.

As of glibc v2.28, libcidn.so was removed due to security issues. That’s why it is misisng for Debian 10, CentOS 8, and Fedora 30+.

CVE-2016-6261, CVE-2016-6263, CVE-2017-14062: Various vulnerabilities have
been fixed by removing the glibc-internal IDNA implementation and using
the system-provided libidn2 library instead.

So, the replacement for glibc’s internal idn implemnetation (libcidn) is libidn or libidn2. Removing something considered “internal” in favor of a specialized system package, for a security issue makes sense to me.

libnss_nis and libnss_nisplus were deprecated in v2.26:

The NIS(+) name service modules, libnss_nis, libnss_nisplus, and
libnss_compat, are deprecated, and will not be built or installed by
default.

The NIS(+) support library, libnsl, is also deprecated. By default, a
compatibility shared library will be built and installed, but not headers
or development libraries. Only a few NIS-related programs require this
library. (In particular, the GNU C Library has never required programs
that use ‘gethostbyname’ to be linked with libnsl.)

Replacement implementations based on TIRPC, which additionally support
IPv6, are available from https://github.com/thkukuk/. The configure
option --enable-obsolete-nsl will cause libnsl’s headers, and the NIS(+)
name service modules, to be built and installed.

That’s why some distros have it and some don’t. Fedora 30+ and CentOS 8 use >v2.26 but do not override the default, and so don’t include the deprecated libnss_nis or libnss_nisplus. Debian 10 on the other hand does override the default. I don’t know when the deprecation will result in full removal.

11

Yes, as long as no external libraries or executables directly link to it (I dont’t know the answer to this but you say “internal” so I hope that only glibc had linked to it in the past).

libnss_nis and libnss_nisplus were deprecated in v2.26

This I find highly problematic - to deprecate anything in glibc at this point without doing a major version bump (indicate an ABI-breaking change). glibc is being relied on by hundred of thousands of applications…