AppImageCommunity/pkg2appimage

libnsl.so.1 no longer part of glibc in Fedora 28, what to do?

Opened this issue ยท 15 comments

According to knapsu/plex-media-player-appimage#13, libnsl.so.1is no longer part of the glibc package and no longer installed by default in F28.

What to do? Is it safe to bundle?
Currently we are not bundling any libraries that are contained in the Ubuntu glibc package since we assume that they don't like version mismatches. Is libnsl an exception?

Any update on this?

It just highlights the ever continuing problem of making binary bundles for Linux distros. If you want to run Plex Media Player on Fedora 28 you need to build it from source yourself (or install the flatpak package which tingping made) until this AppImage is fixed.

Wonder why flatpak wasn't a consideration as it ensures this isn't an issue. AppImage isn't universal if you need to fix it with every new distro version. That is why you need sandboxing to make sure that what runs inside dosn't have to know or care about what runs on the host system.

That is why you need sandboxing to make sure that what runs inside dosn't have to know or care about what runs on the host system.

While that may be a workaround, we really need to get the underlying platform issues fixed rather than worked around. The real problem is that distributions just change stuff randomly in Linux userland without adhering to platform guarantees. It's an example of https://gitlab.com/probono/platformissues.

As for now, I'd say let's bundle libnsl.so.1 and see what happens.

flatpack or snap are definitively not the solution. This approach [0] is going in the right direction.

[0] https://www.gnu.org/software/guix/blog/2017/creating-bundles-with-guix-pack/

To resolve an issue with missed libnsl.1.0 library on Fedora 28 you have to install the libnsl package. Fedora 28 - by default - installs the libnsl2 packages (x64, x86).

...and complain at Fedora for not doing that by default anymore, hence breaking existing applications that rely on it "just being there"

@it-praktyk how does that help creating binaries for linux? Obviously you can also compile any foss software from source, I don't see how that resolves the problem.

Obviously you can also compile any foss software from source

Compiling is for developers.

Users need binaries.

Fedora 29 seems to no longer include it by default, but it apparently worked in previous versions: Calinou/godot-builds-ci#11

In my experience (with other software, not "AppImage") soft linking libnsl2 shared object to the missing one works. Unless there's good reason not to, new versions of these sorts of libraries are backwards compatible. YMMV.

"AppImage" itself doesn't use it; it's some of the payload software that is distributed inside AppImages.

Downloading libnsl.i686 and libX11.i686 packages resolved my issue

@pnaraya4 The point of AppImages is that they should work on fresh Linux installations, without requiring the installation of additional packages ๐Ÿ™‚

Being able to work around it is better than nothing still, but it makes for a poorer experience.

In any case, we no longer have it on the excludelist, so it should be bundled with the applications. If this is working, then I think we can close this issue?