AppImage csomag létrehozása lépésről lépésre GNU/Linuxban

Ha nap mint nap GNU/Linux-szal dolgozol, előbb-utóbb rábukkansz a híres .AppImage fájlokra, és meg akarod érteni, hogy mik is ezek, hogyan kell használni őket, és hogyan hozhatod létre a sajátodat lépésről lépésre . Ez nem csak "egy másik formátum": az AppImage mögött a hordozhatóság, a kevesebb hibás függőség és a kevesebb fejfájás a függvénykönyvtár-verziókkal járóan rejlik.

Továbbá, amikor elkezdjük saját programjainkat fordítani vagy alkalmazásokat csomagolni mások számára, gyorsan rájövünk, hogy a .deb, .rpm és más formátumok karbantartása minden egyes disztribúcióhoz igazi fejfájást okoz . Itt válik az AppImage, olyan eszközökkel együtt, mint a linuxdeploy, az AppImageKit és a Pkg2appimage , nagyon hatékony alternatívává az asztali szoftverek terjesztéséhez szinte bármilyen modern disztribúción.

Mi is pontosan az AppImage csomag, és miért érdemes használni?

Az AppImage fájl lényegében egy önálló futtatható fájl GNU/Linux számára, amely egyetlen képfájlba tömöríti az alkalmazást és annak összes szükséges függőségét (dinamikus könyvtárak, erőforrások, ikonok stb.). Ahelyett, hogy egy hagyományos csomagként települne, amely a fájlokat a rendszerben elosztja, hasonlóan viselkedik:

• Egy „hordozható” .exe fájl a Windows, amit USB-meghajtón hordozhatsz, és bárhol futtathatsz.
• .dmg fájl macOS rendszeren, amely a klasszikus telepítés nélküli, használatra kész alkalmazást tartalmazza.

Amikor egy AppImage-et futtatsz, a rendszer belsőleg csatol egy tömörített ISO-képet írásvédett módban , előkészíti a környezetet, és elindítja a programot. Az alkalmazás bezárása után az ideiglenes csatolás eltűnik. Nincs tényleges "telepítés", mint a DEB vagy RPM csomagoknál: ha törlöd az .AppImage fájlt, akkor teljesen eltávolítottad a programot (kivéve az esetlegesen létrehozott konfigurációs vagy integrációs fájlokat).

Ez a formátum az úgynevezett „univerzális GNU/Linux alkalmazások ” kategóriájába tartozik, más rendszerekkel, mint például a Flatpak és a Snap (és kisebb mértékben olyan javaslatokkal, mint az OrbitalApps). Az ötlet az, hogy a fejlesztő csak egyszer csomagolja be az alkalmazást, és a felhasználó bármilyen modern GNU/Linux disztribúción futtathatja , elkerülve a Debian, Ubuntu, Fedora, openSUSE stb. specifikus verzióinak karbantartásával járó kellemetlenségeket.

Az AppImage legérdekesebb tulajdonságai között számos olyan is szerepel, amelyek megkülönböztetik a hagyományos csomagoktól: hordozható , futtatásához nem szükséges root jogosultság , és nem befolyásolja a rendszerkönyvtárakat vagy a globális beállításokat . Más szóval, letölthetsz egy AppImage-et, végrehajtási jogosultságokat adhatsz neki, és futtathatod Live USB- ről , egy stabil rendszerről régebbi adattárakkal, vagy egy viszonylag új, gördülő kiadásról anélkül, hogy bármit is le kellene fordítanod vagy függőségeket kellene feloldanod.

Az AppImage formátum előnyei és hátrányai a klasszikus csomagokhoz képest

Mielőtt belemerülnénk a létrehozási folyamatba, fontos tisztázni, hogy mit kínál ez a formátum, és mik a hátrányai, különösen akkor, ha azon gondolkodik, hogy AppImage-ként, natív csomagként vagy mindkettőként terjeszti-e az alkalmazását.

Pozitívumként említhető, hogy az AppImage egy önálló bináris fájl az .AppImage kiterjesztéssel, amely gyakorlatilag bármilyen Linux disztribúción fut anélkül, hogy bármi továbbit telepíteni kellene (a legtöbb esetben a FUSE-on kívül). Ez azt jelenti, hogy:

• Nem vagy függve a rendszerkönyvtáraoktólA programodhoz szükséges könyvtárak magukban a fájlban találhatók.
• Nincs szükséged szuperfelhasználói jogosultságokra az alkalmazás használatához, mivel a fájlok nem kerülnek másolásra rendszerútvonalakra, például az /usr vagy az /etc könyvtárba.
• Rendkívül hordozhatóTöbb AppImage fájlt is elhelyezhetsz egy USB-meghajtón, és problémamentesen használhatod őket különböző számítógépeken és disztribúciókon.
• Számos függőségi konfliktust kiküszöbölnek, tipikusan a „Az X program egy új verzióját szeretném használni egy régi stabil disztrón” típusú probléma esetén.
• lehetővé használjon legújabb alkalmazásokat LTS-en vagy nagyon konzervatív disztribúciókon (Debian stabil, Ubuntu LTS, stb.) a rendszer feltörése nélkül.
• Ideálisak szoftver tesztelése a biztonság feláldozása nélkülkülönösen, ha sandboxinggal kombinálod őket (például Firejail).

Azonban nem csak előnyökről van szó. Az AppImage-nek vannak gyengeségei is az egyes disztribúciók hagyományos tárházaihoz képest. Például, mivel az alkalmazások tartalmazzák az összes könyvtárukat , a végső méret általában nagyobb, mint egy natív csomagé , amely újrahasznosítja a rendszerben már meglévő megosztott könyvtárakat. Továbbá:

• Az asztali integráció nem mindig tökéletesVannak olyan eszközök, mint az appimaged vagy az AppImageLauncher, amelyekkel ezt javítani lehet, de sok esetben némi manuális munkára van szükség (menük, fájltársítások stb.).
• az Az AppImage alkalmazások indítása általában egy kicsit tovább tart.mivel a tömörített képet először csatolni kell, bár megnyitás után normálisan működnek.
• Az automatikus frissítések nem mindig vannak megfelelően implementálvaVannak olyan eszközök, mint az AppImageUpdate vagy a zsync támogatása, de sok szoftverhez továbbra is le kell tölteni az új AppImage-et, és manuálisan kell lecserélni a régit.
• El Az AppImage formátumú alkalmazások katalógusa nem túl kiterjedt. mint a főbb disztribúciók hivatalos tárolóié, bár egyre inkább fontos projekteket is tartalmaz (Krita, GIMP, Kdenlive, LibreOffice stb.).
• Általában úgy tartják, hogy A hivatalos adattárakban tárolt csomagok általában extra biztonsági ellenőrzésen esnek át. A közvetlenül egy weboldalról letöltött bináris fájlok esetében körültekintően kell eljárnunk az általunk használt AppImages eredetét illetően.

Ennek ellenére sok esetben az AppImage nagyon praktikus megoldás: például olyan alkalmazások futtatására, amelyek nem szerepelnek a disztribúció tárolóiban, a felesleges függőségek megkerülésére vagy a jelenlegi szoftverek használatára régebbi gépeken . Fejlesztői szempontból pedig egyetlen AppImage csomagolása az összes disztribúcióhoz sok munkát takarít meg.

Az AppImage belső strukturálása: az AppDir könyvtár

A legtöbb AppImage fájlokat generáló eszköz egy alapvető koncepció alapján működik: az AppDir egy könyvtár, amelynek szerkezetét az AppImage ökoszisztéma felismeri . Minden, ami az .AppImage fájlba kerül, először ebbe a könyvtárfába rendeződik.

Minimális formájában egy AppDir-nek legalább három kulcsfájlra van szüksége a gyökérkönyvtárában :

• AppRun: kéz forgatókönyv vagy futtatható fájl, amely akkor indul el, amikor ezt teszed ./MiPrograma.AppImageFelelős a környezet (PATH, LD_LIBRARY_PATH stb.) előkészítéséért és a tényleges alkalmazás futtatásáért.
• Egy .desktop fájl: tartalmazza az alkalmazás metaadatait (név, megjegyzés, kategóriák, ikon, végrehajtási parancs…) a freedesktop.org Desktop Entry specifikációjának megfelelően.
• Egy ikon (általában .png vagy .svg): az AppImage fájl ikonjának megjelenítésére szolgál a fájlkezelőkben és a rendszerbe integrált alkalmazásindítókban is.

Ezen a minimális alapon túl bevett gyakorlat, hogy az AppDir-en belül egy, a hagyományos GNU/Linux rendszerhez hasonló struktúrát tartanak fenn, tiszteletben tartva az FHS-t (Filesystem Hierarchy Standard). Ez azt jelenti, hogy olyan alkönyvtárakat kell létrehozni, mint a ./usr/bin, ./usr/lib vagy ./usr/share . Ezeken belül a következőket kell elhelyezni:

• En usr/bin/, az alkalmazás fő bináris fájlja (például hello-world, Rectball, nvim, Stb.)
• En usr/lib/, a megosztott könyvtárak (.so), amelyekre a programodnak szüksége van, és amelyekről nem szabad feltételezni, hogy a felhasználó telepítette a rendszerére.
• En usr/share/applications/, a fájl .asztal amely leírja az alkalmazást.
• En usr/share/icons/hicolor/ (és hasonló útvonalakon), az alkalmazásikonok különböző méretben.

Lényeges, hogy a végrehajtható fájl független a fájlrendszerben elfoglalt helyétőlHa a programod abszolút elérési utakat feltételez, mint ez: /usr/bin/miapp o /usr/share/miappProblémák lesznek az AppImage futtatásával, mert futásidőben egy másik ideiglenes helyre van csatolva. A helyes megközelítés a következő: relatív útvonalakkal való munka vagy dinamikusan felépítheti őket a bináris fájl vagy az AppRun szkript tényleges elérési útjából.

Egy teljesebb AppDir így nézhet ki egy könyvtárlistában:

$ ls -l
AppRun
miaplicacion.desktop
miaplicacion.svg
usr/

$ ls -R usr
usr/bin/miaplicacion
usr/lib/…
usr/share/applications/miaplicacion.desktop
usr/share/icons/hicolor/…

Miután elkészült ez a struktúra, olyan eszközök, mint a linuxdeploy vagy az appimagetool (az AppImageKitből), felelősek lesznek az AppDir konvertálásáért a végső .AppImage fájllá.

.desktop fájl és alapvető asztali integráció

A .desktop fájl kulcsfontosságú összetevője mind az AppImage-nek, mind bármely asztali alkalmazás GNU/Linuxba integrálásának. Ez egy egyszerű szövegfájl Desktop Entry formátumban , amely sima szövegszerkesztővel vagy grafikus menüszerkesztő segédprogramokkal szerkeszthető.

Egy egyszerű példa a tartalomra lehet:

[Desktop Entry]
Type=Application
Name=Rectball
Comment=Match gems and collect points in this puzzle game
Categories=Game;
Exec=Rectball
Icon=rectball

Ebben a példában a kulcs Végrehajt jelzi a végrehajtandó parancsot (abszolút elérési út nélkül), és ha a Az AppRun úgy konfigurálja a PATH-ot, hogy tartalmazza a következőket: ${HERE}/usr/binA rendszer gond nélkül megtalálja a bináris fájlt. Fontos hangsúlyozni, hogy:

• A Kategóriák bejegyzés kitöltése kötelező számos, az AppImage-hez kapcsolódó eszköz esetében (például a linuxdeploy egyes változatai sikertelenek, ha nincs definiálva).
• A kulcs ikon Általában egy fájltípushoz van rendelve nombre.png o nombre.svg amelynek elérhetőnek kell lennie a várt ikonkönyvtárakban (például az AppDir mappában a usr/share/icons vagy a .desktop mellett, a munkafolyamattól függően).

Néhány valódi AppImage-ben láthatod, hogy az Icon billentyű kimarad, vagy kissé eltérően kezelik. Ennek ellenére, ha el szeretnéd kerülni a meglepetéseket (például, hogy az ikonok nem jelennek meg helyesen .png fájl használatakor .svg helyett), érdemes explicit módon definiálni az Icon billentyűt, és ellenőrizni, hogy jól néz-e ki több disztribúción is.

Az AppRun szkript: a végrehajtás lelke az AppImage-ben

Az AppRun fájl az AppImage belépési pontja. Amikor a felhasználó futtatja az .AppImage fájlt, valójában az AppRun indul el a felcsatolt AppDir-en belül. Ez a szkript lehet egy egyszerű shell szkript, amely:

• Oldja fel a tényleges útvonalat, ahonnan fut (figyelembe véve a szimbolikus linkeket és az időbeli összeállításokat).
• Környezeti változók előkészítése például a PATH, LD_LIBRARY_PATH és mások, amelyekre a programnak szüksége van a könyvtárak vagy erőforrások megtalálásához.
• Indítsa el a tényleges futtatható fájlt (akár az Exec kulcs beolvasásával a .desktop fájlból, akár közvetlenül meghívással) usr/bin/miapp).

Egy nagyon gyakori minta, amelyet az AppImageKitben találhatsz, valahogy így néz ki:

#!/bin/sh
SELF=$(readlink -f "$0")
HERE=${SELF%/*}

export PATH="${HERE}/usr/bin:$PATH"
export LD_LIBRARY_PATH="${HERE}/usr/lib:$LD_LIBRARY_PATH"

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

Ez a megközelítés dinamikusan kikeresi az `Exec` értékét a `.desktop` fájlban, és végrehajtja azt a felhasználó által átadott argumentumokkal, ami nagyon rugalmas. Más projektek még egyszerűbb verziókat választanak. Például a Neovim AppImage egy minimalista `AppRun`-t használ, mint ez:

#!/bin/bash
unset ARGV0
exec "$(dirname "$(readlink -f "${0}")")/usr/bin/nvim" ${@+"$@"}

Bármelyik változatot is használjuk, az AppRun lényege, hogy nem függ abszolút rendszerútvonalaktól, és bárhol képes megfelelően működni, ahol az AppImage fel van csatolva.

Eszközök AppImage-ek létrehozásához: linuxdeploy, AppImageKit és Pkg2appimage

Saját AppImage csomag létrehozásakor számos fő eszköz áll rendelkezésedre, mindegyiknek megvan a saját megközelítése. A modern munkafolyamatokhoz leginkább ajánlott a linuxdeploy , bár az AppImageKit és a Pkg2appimage továbbra is megállja a helyét.

linuxtelepítés gondoskodik Elemezze a végrehajtható fájlt, észlelje a függőségeit, és automatikusan felépítse az AppDir struktúrát. megfelelő (könyvtárak másolása ide usr/lib(fájlok rendszerezése stb.). Különösen hasznos, ha már van egy működő bináris fájlod, és anélkül szeretnéd becsomagolni, hogy túlságosan törnéd a fejed azon, hogy mely könyvtárakat illesszd be.

Az AppImageKit a maga részéről többek között az appimagetool mappát biztosítja , amely egy előre telepített AppDir mappát fogad bemenetként, és abból generálja az .AppImage fájlt. Az appimagetool mappát közvetlenül a GitHub repositoryból lehet letölteni; érdekes módon AppImage formátumban is terjesztik . Egy tipikus felhasználási eset a következő lenne:

./appimagetool-x86_64.AppImage MiApp.AppDir MiApp-x86_64.AppImage

Olyan környezetekben, mint a Docker vagy a CI, ne feledd, hogy az AppImageKit FUSE-t igényel a képfájl belső csatlakoztatásához. Ha a FUSE nem érhető el a konténerben vagy a gépen, a folyamat sikertelen lehet, ezért ajánlott ezt ellenőrizni a buildek automatizálása előtt.

A harmadik fontos komponens a Pkg2appimage , amelyet olyan esetekre terveztek, amikor már van egy meglévő csomagod (például tar.gz, .deb vagy akár PPA tárolók ), és azt AppImage-vé szeretnéd konvertálni. Ez az eszköz egy .yml leírófájlon keresztül vezérelhető , ahol meghatározhatod, hogy honnan töltődik le a szoftver, hogyan települnek a csomagok, és mely fájlok kerüljenek a kapott AppDir-be.

A Pkg2appimage használatával általában így kell dolgozni:

1. Klónozz egy adattárat a megfelelő .yml fájllal. az átalakítani kívánt alkalmazáshoz (például egy testreszabott Packet Tracer YAML).
2. Pkg2appimage letöltése a GitHub repóból, és adj neki végrehajtási jogosultságokat a következővel: chmod +x.
3. A .yml fájl módosítása a megváltozott letöltési URL-címek vagy az új függőségek frissítéséhez.
4. Dobás ./pkg2appimage NombreArchivo.yml és várja meg, amíg létrehozza a végső AppDir és AppImage fájlokat.

Ez a megközelítés nagyon praktikus a disztródon nem jól működő , vagy összetett könyvtár-visszalépéseket igénylő meglévő csomagok újrahasznosításához. A Pkg2appimage automatizálja a munka nagy részét, és egy használatra kész .AppImage fájlt hagy maga után a különböző rendszerekhez.

Hozz létre egy AppImage-et saját futtatható fájlból lépésről lépésre

Képzelj el egy egyszerű programot, például egy projektet, amit úgy hívnak, hogy Helló Világ, a binárisával bin/ és könyvtáraikban lib/Csomagolhatod .zip formátumban, megtanulhatod, hogyan generálhatsz .deb vagy .rpm fájlt, de azt is megteheted, hogy Ragadd meg a lehetőséget, és csomagold be AppImage-kéntA linuxdeploy használata általában meglehetősen egyszerű.

Az alapvető lépések a következők lennének: kulcsfontosságú lépések

1. Készítse elő a környezetet és szerezze be a linuxdeploy-t

Az első lépés a linuxdeploy eszköz letöltése és futtathatóvá tétele . Általában használatra kész bináris fájlokként terjed (például AppImageként). A terminálból valami ilyesmit kell tenned:

wget https://github.com/linuxdeploy/linuxdeploy/releases/.../linuxdeploy-x86_64.AppImage
chmod +x linuxdeploy-x86_64.AppImage

Továbbá, ha hatékony frissítéseket szeretne biztosítani a zsync segítségével , telepítheti a zsync segédprogramot például Debian/Ubuntu alapú rendszerekre a következő paranccsal:

sudo apt-get install zsync

2. Az AppDir struktúra felépítése

Ezután létrehoz egy könyvtárat, amely AppDir-ként fog működni (például: MiApp.AppDirés belül megszervezed a minimális szerkezet Ez szükséges. Megteheted manuálisan, vagy hagyhatod, hogy a linuxdeploy generálja a részét. Az ötlet a következő:

• Helyezze el a fő futtatható fájlt MiApp.AppDir/usr/bin/. Például MiApp.AppDir/usr/bin/hello-world.
• Engedélyezze a linuxdeploy számára a szükséges könyvtárak automatikus másolását a MiApp.AppDir/usr/lib/ amikor a megfelelő opciókkal futtatod.
• Hozza létre a .desktop fájlt belül MiApp.AppDir/usr/share/applications/ a megfelelő mezőkkel: Név, Megjegyzés, Végrehajtó, Ikon, Kategóriák stb.
• Készítsd elő az ikonokat és helyezze el őket a tipikus útvonalakon MiApp.AppDir/usr/share/icons/hicolor/, ügyelve arra, hogy a .desktop fájlban található Icon kulcs értéke megegyezzen a fájlnévvel (a kiterjesztés nélkül).

Fontos megjegyezni, hogy a .desktop mezőben Az Exec függvénynek pontosan úgy kell mutatnia a végrehajtható fájl nevére, ahogyan a linuxdeploy fogja keresni. usr/bin. Ha használja Exec=hello-worldA linuxdeploy feltételezi, hogy a usr/bin A futtatható fájl létezik.

3. Futtassa a linuxdeploy parancsot az alkalmazás becsomagolásához

Miután az AppDir struktúra a helyén van, adja meg az AppDir elérési útját , és opcionálisan a kívánt modulokat vagy bővítményeket (például ikonok, .desktop fájlok stb. integrálásához). A linuxdeploy kezelői:

• A fő bináris fájl beolvasása és azonosítja, hogy mely dinamikus könyvtárakra van szüksége.
• Másolja ezeket a könyvtárakat a usr/lib az AppDir-en belül, feltéve, hogy nem olyan könyvtárakról van szó, amelyekről feltételezzük, hogy már léteznek a felhasználó rendszerében.
• Készítse elő az AppDir-t hogy később AppImage képpé válhasson (néha maga a linuxdeploy is képes AppImage-et generálni bővítményekkel kombinálva).

A folyamat után egy kiterjesztésű fájl lesz az aktuális könyvtárban. .AppImagemint például hello-world-x86_64.AppImageamit bárhová másolhatsz, és más kompatibilis GNU/Linux rendszereken futtathatsz.

4. Tedd futtathatóvá és teszteld különböző disztribúciókon

Amikor a linuxdeploy (vagy az appimagetool) létrehozza az AppImage-et, nagyon valószínű, hogy a végrehajtási bit kezdetben nincs beállítva . Ebben az esetben egyszerűen tegye a következőket:

chmod +x hello-world-x86_64.AppImage
./hello-world-x86_64.AppImage

Erősen ajánlott az AppImage-et különböző disztribúciókon és verziókon tesztelni , beleértve egy viszonylag régebbi verziót is a támogatni kívánt verziótartományon belül (például az Ubuntu vagy a Debian minimális támogatni kívánt verzióját). Ez biztosítja, hogy ne hagyj ki fontos függőségeket, és hogy a futtatható fájl mindenhol ugyanúgy viselkedjen.