libthai in excludelist causes problems

[krushia]

pkg2appimage/excludelist

Line 119 in c302f81

libthai.so.0

This breaks several appimages by assuming a Thai language library will be present on any host system. Known to be missing on several installs of Arch, Debian, Gentoo, Nix, and Slackware. A small sampling of references:

tauri-apps/tauri#4930
pineappleEA/pineapple-src#85
xournalpp/xournalpp#4660
cjcliffe/CubicSDR#852
https://discourse.appimage.org/t/how-do-distros-add-support-for-running-appimages/1648/8

[bashfulrobot]

While this is my own. I wanted to add another example where it breaks an appimage.

But it looks like it is on it's way in. 👍

[probonopd]

• If we don*t bundle it, target systems that don't have it installed get an issue
• If we bundle it, target systems that have a newer version installed get an issue

So we would need a way to determine, at runtime, which one is newer; the one on the system or the one in the AppImage.

[phil294]

If we bundle it, target systems that have a newer version installed get an issue

sorry, but why? How is libthai different from any other package on the excludelist? In other words, why does this problem not exist for others?

[probonopd]

Good question.

[ImUrX]

So we would need a way to determine, at runtime, which one is newer; the one on the system or the one in the AppImage.

is this something that is done already? that you just have an array of and we can just append another package in? Or should this be done with a custom handler just for libthai?

[probonopd]

So we would need a way to determine, at runtime, which one is newer; the one on the system or the one in the AppImage.

is this something that is done already?

I don't remember that anyone has done that yet, but maybe @TheAssassin or @azubieta have a solution for that.
Ideally we would find a way that would work with all libraries.

(Please note that pkg2appimage is only a last resort solution; it's better to ask the application author to provide an officially made, tested, and supported AppImage.)

[ImUrX]

I'm one of the app authors, but the ones providing the solution to packing the appimage is the framework we using which is Tauri.

(You can see the issue from Tauri that references it in tauri-apps/tauri#4930)

[azubieta]

Hi @probonopd, I had somethingo done for libc (glibc) abd libc++ but not for libthai, it would require a special launcher that compares the library versions and pics the correct one.

[TheAssassin]

I guess people who need this need to handle this in their deployment specifically. https://github.com/darealshinji/linuxdeploy-plugin-checkrt for instance allows bundling a libstdc++ implementing a version check to load it only when needed. This really sounds like there is a need for a linuxdeploy-plugin-libthai. It can't be fixed here.

[probonopd]

..or a modified ld-linux loader that compares the versions inside and outside the bundle for all libraries...

[TheAssassin]

Sounds like a recipe for disaster...

[probonopd]

...indeed. Scary!

[TheAssassin]

If we bundle it, target systems that have a newer version installed get an issue

Is that confirmed? I don't see any references in this issue. As far as I can see it, it shouldn't matter, really.

Edit: the only comment that ever mentioned problems is #538 (comment), but there is no reference to some concrete issue or a minimal example to reproduce...

[probonopd]

pkg2appimage/excludelist

Lines 123 to 126 in 48a9bbf

	libthai.so.0
	# Workaround for:
	# audacity: /tmp/.mount_AudaciUsFbON/usr/lib/libthai.so.0: version `LIBTHAI_0.1.25' not found (required by /usr/lib64/libpango-1.0.so.0)
	# on openSUSE Tumbleweed

[TheAssassin]

That just means we have to bundle both libpango and libthai, doesn't it?

[koppor]

I am tryting the AppImage of gitbutler and run into the same issue. Did you find some recipe to work-around this?

[probonopd]

One way would be to use a tool that can bundle everything, like go-appimage -s deploy.