Remove libp11-kit.so from excludelist if possible

[2011]

I recently came across an AppImage that lacked this library (and I do not have it on my system, so the AppImage won't run). The commit adding it to the excludelist does not explain why:

https://github.com/AppImageCommunity/pkg2appimage/commit/ac19f2a00490ea7895334dbb014b0d56349aae04#diff-9ae84c69e3e8924a88be23fd753ea6424e1af71fba14443402102b24be82ffb2R87

[probonopd]

Thanks @2011. If it is on the excludelist without further explanation, then this means that at the time the list was originally created, all mainstream Linux distributions where shipping this library.

Is this no longer the case? Which distribution doesn't ship it?

[2011]

@probonopd I have a source distribution which doesn't include pkcs11 support.

The relevant AppImage includes libgnutls.so.30 which links to libp11-kit.so.0.

$ ldd /tmp/squashfs-root/usr/lib/libgnutls.so.30 
        linux-vdso.so.1 (0x00007ffe7618e000)
        libp11-kit.so.0 => not found
        libidn2.so.0 => /usr/lib64/libidn2.so.0 (0x00007f6b06dce000)
        libunistring.so.2 => not found
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f6b0721a000)
        libtasn1.so.6 => /usr/lib64/libtasn1.so.6 (0x00007f6b07205000)
        libnettle.so.6 => not found
        libhogweed.so.4 => not found
        libgmp.so.10 => /usr/lib64/libgmp.so.10 (0x00007f6b06d4f000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f6b071fe000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f6b06ba8000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f6b0722e000)
        libunistring.so.5 => /usr/lib64/libunistring.so.5 (0x00007f6b069f0000)

Note that the AppImage includes (in /tmp/squashfs-root/usr/lib/, which explains why ldd doesn't pick them up) libunistring.so.2, ibnettle.so.6, and libhogweed.so.4. The maintainer doesn't include libp11-kit.so.0 because it appears on the excludelist, yet includes a libgnutls dynamically linked to it. To me, it seems safer for an AppImage that includes libgnutls (which I don't believe that the application itself requires, but many other included libraries, particularly libQt6*, link to it), to also include libp11-kit, if for no other reason than to make certain the library versions match.

To further emphasize that last point, the /tmp/squashfs-root/usr/lib/ includes (all dynamically linked from libgnutls): libunistring.so.2 (I have libunistring.so.5 installed) libnettle.so.6 (I have libnettle.so.8 installed) libhogweed.so.4 (I have libhogweed.so.6 installed)

So even if I had libp11-kit installed, the AppImage (assuming that it provides libgnutls) should include libp11-kit to make certain of compatibility with the provided libgnutls.

[probonopd]

I have a source distribution

Well, AppImage targets "mainstream desktop distributions" such as Debian, Ubuntu, Linux Mint, etc. In your case, would installing that library in your system resolve the issue? Basically you should install all libraries listed in the excludelist to your source distro in order to make your source distro compatible with the AppImages out there.

[2011]

Well, AppImage targets "mainstream desktop distributions" such as Debian, Ubuntu, Linux Mint, etc.

AppImage should target a wide variety of distributions. Certainly it doesn't need to target "specialized" distributions, but it should run on as many general desktop distributions as possible.

Basically you should install all libraries listed in the excludelist to your source distro in order to make your source distro compatible with the AppImages out there.

Libraries that require other libraries (excluding basic system libraries) should include those libraries. What makes libp11-kit (which to my understanding, basically exists to provide smartcard support - something relatively specialized) unique when compared to libnettle (requried by gnutls) or libunistring? It seems quite arbitrary to me. In fact, I would assume virtually every desktop distribution would have gnutls, so why doesn't that appear on the exclude list (using the system libgnutls would work fine for me)?

I don't see the negatives of removing libp11-kit from the exclude list, which would no longer discourage AppImage maintainers from including that library if they desired.

[probonopd]

It's a tradeoff space vs. reliability. If you value the latter most, then you can even make an AppImage that bundles all libraries, including glibc. (pkg2appimage doesn't do this, though.)

It seems quite arbitrary to me

The orginal excludelist was made by comparing the libraries that mainstream desktop distributions where shipping at the time.

[2011]

The orginal excludelist was made by comparing the libraries that mainstream desktop distributions where shipping at the time.

1. Desktops didn't ship gnutls then?

2. Shouldn't the excludelist get updated as default packages change?

[probonopd]

Desktops didn't ship gnutls then?

Possibly they didn't agree on a major version at the time, don't remember the specifics.

The excludelist should hopefully mature to a stable state at some point in time, but yes, currently we still need to tweak it from time to time, as the underlying operating systems are unfortunately "moving targets". For this reason, I am leaning more and more to bundling everything (= not using an excludelist at all), even though this adds a few MB of overhead.

[2011]

For this reason, I am leaning more and more to bundling everything (= not using an excludelist at all), even though this adds a few MB of overhead.

I wouldn't object to that (should provide a better user experience). Building some of the libraries statically (in this case, I believe libgnutls wouldn't get included at all) could reduce the size of many AppImages, although that might require a significant amount of extra work.

This convesation might have enough information for the AppImage maintainer that brought my attention to the excludelist to include libp11-kit in the relevant AppImage anyway, though I would still appreciate it if you could remove libp11-kit from the excludelist at the present time. :) I believe that the benefit of ensuring ABI consistency alone justifies that in this case.

[probonopd]

Done. Thanks for pointing this out!