appimage - fix "no version information available" error

[DetachHead]

fixes #2625

through trial and error i found out that deleting ${HERE}"/lib/x86_64-linux-gnu/ from LD_LIBRARY_PATH made the error go away (tested on linux mint 22.3 x86_64)

but honestly i have no idea if this is the correct fix. cc @ivan-hc @Samueru-sama they seem to know a lot about appimages

[ivan-hc]

Personally, I try to avoid exposing LD_LIBRARY_PATH in my AppRuns, except in rare cases. With the new AppImage runtimes currently available, programs should work right away, without specifying so many environment variables.

But I don't use VSCodium. Perhaps it has other requirements to be packaged this way.

And if it works for you with this change, I don't see why it shouldn't work for others.

[DetachHead]

alight i'll get rid of the variable entirely. i did try that and verified that it still worked on my machine, but i wasn't sure if it meant i was just making it rely more on my system libraries or not lol

[daiyam]

Here the PR #773 and its comment that have introduced that variable:

Fixing python in AppImage (#773)

• overwrite AppRun to remove the env variables PYTHONHOME and PYTHONPATH
• update building script to it can be build manually in docker

[daiyam]

Here my almost 5 years old question AppImageCommunity/pkg2appimage#486 about those variables....

[ivan-hc]

Here the PR #773 and its comment that have introduced that variable:

Fixing python in AppImage (#773)

Python variables are relative to Python, just as LD_LIBRARY_PATH is relative to libraries, PATH to executables, and so on.

Aside from that, Python behaves differently depending on the version. If a program is written to run on Python 3.13, it will rarely run on the Python 3.14 installed on the system. It might even work, but not always.

In any case, Python requires its own variables: PYTHONPATH (the path to specific libraries and modules) and PYTHONHOME (typically /usr or /usr/share). If the app needs to run on multiple systems but requires its own version of Python or has modules compiled with a specific version of Python, these variables must be set.

But PATH, XDG_DATA_DIRS, LD_LIBRARY_PATH... have almost nothing to do with any of this.

At most, if a specific library doesn't want to load, you need to put it in LD_PRELOAD, but that's not always necessary. It depends on the case.

Every variable has its purpose. And for years, I created my AppImages by copying and pasting the base template of an AppRun (from pkg2appimage) in this same way. And I was wrong. That's why I'm telling you.

[ivan-hc]

Here my almost 5 years old question AppImageCommunity/pkg2appimage#486 about those variables....

Furthermore, pkg2appimage still depends on the old runtime that depends on libfuse2. The "old" Type2. Now there's the "new" Type2 (don't ask me why they didn't call it Type3; you'll have to ask @probonopd). I assure you, getting AppImage packages to work with the new runtime is even easier.

I also use pkg2appimage sometimes, but only to download packages. I pair it with the new appimagetool and therefore the new type2-runtime, with custom AppRun.

pkg2appimage needs a revamp btw.

[daiyam]

I agree but it was the only solution at the time, for me. And I'm not an appimage user...

So I welcome any better solution with or without pkg2appimage. 😉

[ivan-hc]

So I welcome any better solution with or without pkg2appimage. 😉

I know a packager of AppImages that is ways better than me: @Samueru-sama

[Samueru-sama]

I talked about these issues in #2538 (comment)

PYTHONHOME and PYTHONPATH hasn't been needed since like python 3.10 btw, the binary now figures out the pyhondir location on its own. Not to mention I don't think this app even uses python???

If VSCodium is an electron app, you should really not have to set any env variable, electron bundled are already portable on their own, basically just make the AppRun execute the binary and that's all.

EXEC=$(grep -e '^Exec=.*' "${HERE}"/*.desktop | head -n 1 | cut -d "=" -f 2- | sed -e 's|%.||g')

This is also like the worst way possible to find the name of the binary to be launched, here is a more efficient way:

EXEC=$(awk -F'=| ' '/^Exec=/{print $2; exit}' "${HERE}"/*.desktop)

But also if we know the name of the binary there is no need find it, just code it directly in the AppRun.

[DetachHead]

And if it works for you with this change, I don't see why it shouldn't work for others.

@daiyam would it be ok if we merge this PR as-is, as a temporary solution since it at least resolves #2625, until somebody more experienced with appimages can contribute a proper fix?

[probonopd]

The "old" Type2. Now there's the "new" Type2 (don't ask me why they didn't call it Type3; you'll have to ask @probonopd)

Type 2 is referring to one of the allowed image formats as per the spec. What you are calling "new" is just a new implementation of the runtime that supports the same spec. We don't want to change the spec often to keep it stable.