Viber AppImage és a KDE: amikor a linkek makacskodnak
Van az a helyzet, amikor minden működik… kivéve egy teljesen hétköznapi dolog: rákattintasz egy linkre a Viberben, és semmi. KDE alatt ez könnyen előjöhet, főleg AppImage alkalmazásoknál. A felhasználó csak annyit lát, hogy „nem nyílik meg” – a háttérben viszont jóval érdekesebb történet zajlik.
Ebben a bejegyzésben végigmegyek azon, miért nem működik, hogyan lehet gyorsan azonosítani a hibát, és mi a legegyszerűbb, stabil javítás KDE rendszeren.
Mi történik valójában?
A Viber AppImage saját Qt-könyvtárakat csomagol magába. Ez még rendben is lenne – csakhogy amikor fut, beállít egy LD_LIBRARY_PATH környezeti változót, ami minden gyerekfolyamatra is öröklődik.
És itt lép be a csavar: amikor a Viber meghívja a rendszer kde-open parancsát, az is az AppImage Qt-jét próbálja használni. A KDE viszont újabb Qt-verzióval épül (6.8, 6.9), így a hívás azonnal hibába fut.
A terminál ehhez hasonló sorokkal jelzi a problémát:
kde-open: libQt6Core.so.6: version `Qt_6.9' not found
kde-open: libQt6Core.so.6: version `Qt_6.8' not found
Innen már tudni lehet: nem a böngésző a hibás, nem is az xdg-open, hanem a környezet, amiben a kde-open elindul.
Hogyan ellenőrizhető?
Először nézzük meg, van-e rendszer szintű kde-open:
whereis kde-open
Ha például ezt kapod:
kde-open: /usr/bin/kde-open
akkor a megoldás gyakorlatilag adott: a Viber rossz Qt-vel indítja. Nekünk csak arról kell gondoskodnunk, hogy a kde-open tiszta környezetben induljon.
A működő javítás: saját wrapper kde-open
A cél nagyon egyszerű: amikor a Viber hívja a kde-open-t, mi valójában egy olyan kis szkriptet futtassunk, amely:
- kinullázza az AppImage által beállított
LD_LIBRARY_PATH-ot, - majd meghívja a valódi
/usr/bin/kde-open-t.
A wrapper elkészítése
sudo nano /usr/local/bin/kde-open
Tartalom:
#!/bin/sh
unset LD_LIBRARY_PATH
exec /usr/bin/kde-open "$@"
Jogosultság beállítása:
sudo chmod +x /usr/local/bin/kde-open
Ezzel elértük, hogy a kde-open hívást már ne az AppImage környezete befolyásolja. A rendszer Qt-könyvtárai töltődnek be, és a böngésző rendben elindul.
Teszt
Terminálból próbáld ki:
kde-open https://google.com
Ha megnyílik a böngésző, akkor a wrapper működik.
Ezután indítsd el a Vibert AppImage-ből, és kattints egy linkre. Jó eséllyel most már gond nélkül megnyílik.
Miért ez a legjobb megoldás?
Az AppImage-ek saját környezetet csomagolnak, és időnként ez ütközéshez vezet a rendszer könyvtáraival. A KDE különösen érzékeny arra, milyen Qt-verzióval indulnak a komponensei.
Ez a kis wrapper-szkript nem hack, nem kerülőút, hanem egy tiszta, karbantartható megoldás: csak azt biztosítjuk, hogy a rendszerprogramok ne örököljék az AppImage hibás környezetét.
Ha más AppImage-nél is tapasztalsz hasonlót, érdemes megnézni, hogy az LD_LIBRARY_PATH beleszól-e a működésébe. Meglepően gyakran ez a probléma gyökere.