Hur man skapar ett AppImage-paket steg för steg i GNU/Linux

Om du navigerar i GNU/Linux-världen dagligen kommer du förr eller senare att stöta på de berömda filerna .AppImage-filer, och du vill förstå vad de är, hur du använder dem och hur du skapar dina egna steg för steg.Det är inte bara "ett annat format": bakom AppImage finns en mycket tydlig filosofi om portabilitet, färre trasiga beroenden och färre huvudvärk med biblioteksversioner.

Dessutom, när du börjar kompilera dina egna program eller paketera applikationer åt andra, upptäcker du snabbt att underhålla .deb, .rpm och andra format för varje distro är en riktig huvudvärkDet är där AppImage, tillsammans med verktyg som linuxdeploy, AppImageKit och Pkg2appimageDet blir ett mycket kraftfullt alternativ för att distribuera skrivbordsprogramvara på nästan vilken modern distribution som helst.

Vad är egentligen ett AppImage-paket och varför är det värt det?

En AppImage-fil är i huvudsak en fristående körbar fil för GNU/Linux som inkluderar applikationen och alla dess beroenden De nödvändiga filerna (dynamiska bibliotek, resurser, ikoner etc.) komprimeras till en enda avbildning. Istället för att installeras som ett traditionellt paket som distribuerar filer i hela systemet, beter sig det på liknande sätt:

• En "bärbar" .exe i Windows, som du kan bära med dig på ett USB-minne och köra var du vill.
• En .dmg-fil på macOS, som innehåller applikationen som är redo att användas utan en klassisk installation.

När du kör en AppImage monteras systemet internt en komprimerad ISO-bild i skrivskyddat lägeDen förbereder miljön och startar programmet inuti. När du stänger programmet försvinner den tillfälliga monteringen. Det finns ingen faktisk "installation" som med DEB- eller RPM-paket. Om du tar bort .AppImage-filen tar du bort programmet. utan att lämna några spår (förutom vissa konfigurations- eller integrationsfiler om de har genererats).

Detta format faller under vad som kallas "Universella applikationer för GNU/Linux", tillsammans med andra system som t.ex. Flatpak och Snap (och, i mindre utsträckning, förslag som OrbitalApps). Tanken är att utvecklaren Paketera det en gång och användaren kan köra det på vilken modern GNU/Linux-distribution som helst.undvika att behöva underhålla specifika versioner för Debian, Ubuntu, Fedora, openSUSE, etc.

Bland de mest intressanta funktionerna i AppImage finns flera som skiljer det från traditionella paket: portabel, kräver inga behörigheter rot att köras och berör varken systembibliotek eller globala inställningarMed andra ord kan du ladda ner en AppImage, ge den körningsbehörigheter och starta den i en Live-miljö. USB, i ett stabilt system med gamla repositories eller i en ganska ny rullande utgåva utan att behöva kompilera något eller lösa beroenden.

Fördelar och nackdelar med AppImage-formatet jämfört med klassiska paket

Innan du fördjupar dig i skapandeprocessen är det viktigt att vara väldigt tydlig med vad det här formatet erbjuder och vilka dess nackdelar är, särskilt om du bestämmer dig för om du vill distribuera din applikation som en AppImage, som ett native-paket eller som båda..

På den positiva sidan är en AppImage en En fristående binärfil med .AppImage-tillägget som körs på praktiskt taget vilken distribution som helst utan att behöva installera något ytterligare (utöver FUSE i de flesta fall). Detta innebär att:

• Du är inte beroende av systembibliotekDe bibliotek som ditt program behöver finns i själva filen.
• Du behöver inte superanvändarbehörigheter för att använda programmet, eftersom filer inte kopieras till systemsökvägar som /usr eller /etc.
• Den är extremt portabelDu kan lägga flera AppImages på ett USB-minne och använda dem på olika datorer och distributioner utan problem.
• De eliminerar många beroendekonflikter, typiskt för "Jag vill använda en ny version av program X på en gammal stabil distribution".
• tillåta använd nya applikationer på LTS eller mycket konservativa distributioner (Debian stable, Ubuntu LTS, etc.) utan att systemet går sönder.
• De är idealiska för testa programvara utan att kompromissa med säkerhetensärskilt om du kombinerar dem med sandboxing (till exempel Firejail).

Det är dock inte alla fördelar. AppImage har också sina svagheter jämfört med de traditionella arkiven för varje distribution. Till exempel applikationer inkludera alla deras bibliotekden slutliga storleken är vanligtvis större än ett nativt paket vilket återanvänder delade bibliotek som redan finns i systemet. Dessutom:

• Desktop-integration är inte alltid perfektDet finns verktyg som appimaged eller AppImageLauncher för att förbättra detta, men i många fall krävs en del manuellt arbete (menyer, filassociationer etc.).
• den AppImage-applikationer tar vanligtvis lite längre tid att starta.eftersom den komprimerade bilden först måste monteras, även om de fungerar normalt när de väl öppnats.
• Automatiska uppdateringar är inte alltid väl implementeradeDet finns verktyg som AppImageUpdate eller stöd för zsync, men mycket programvara kräver fortfarande att den nya AppImage laddas ner och att den gamla ersätts manuellt.
• El Katalogen över applikationer i AppImage-format är inte särskilt omfattande. som de officiella arkiven för de stora distributionerna, även om den i allt högre grad inkluderar viktiga projekt (Krita, GIMP, Kdenlive, LibreOffice, etc.).
• I allmänhet anses det Paket som lagras i officiella arkiv genomgår vanligtvis en extra säkerhetsgranskning. När det gäller binärfiler som laddas ner direkt från en webbplats måste vi vara försiktiga med ursprunget för de AppImages vi använder.

Ändå är AppImage en mycket praktisk lösning för många scenarier: till exempel, Köra applikationer som inte finns i din distributions repositories, hoppa över absurda beroenden eller använda aktuell programvara på gamla maskinerOch ur utvecklarens synvinkel sparar det mycket arbete att paketera en enda AppImage för alla distributioner.

Hur en AppImage är strukturerad internt: AppDir-katalogen

De flesta verktyg som genererar AppImages fungerar utifrån ett grundläggande koncept: AppDir, en katalog med en struktur som känns igen av AppImage-ekosystemetAllt som hamnar i .AppImage-filen organiseras först i det katalogträdet.

I sin minimala form behöver en AppDir minst tre nyckelfiler i din rot:

• AppRun: Den skript eller körbar kod som startar när du gör det ./MiPrograma.AppImageDen ansvarar för att förbereda miljön (PATH, LD_LIBRARY_PATH, etc.) och för att köra själva applikationen.
• En .desktop-filinnehåller programmets metadata (namn, kommentar, kategorier, ikon, körkommando...) enligt Desktop Entry-specifikationen för freedesktop.org.
• En ikon (vanligtvis .png eller .svg): används både för att visa AppImage-filikonen i filutforskare och för systemintegrerade programstartare.

Utöver den minimibasen följer AppDir vanligtvis en struktur som liknar den hos ett konventionellt GNU/Linux-system, med respekt för FHS (Filesystem Hierarchy Standard). Det vill säga, Skapa underkataloger som ./usr/bin, ./usr/lib eller ./usr/shareDu ska placera följande inuti dem:

• En usr/bin/, den huvudsakliga binärfilen för din applikation (till exempel hello-world, Rectball, nvim, Etc.).
• En usr/lib/, de delade biblioteken (.so) som ditt program behöver och som du inte bör anta att användaren har installerat på sitt system.
• En usr/share/applications/, filen .desktop som beskriver applikationen.
• En usr/share/icons/hicolor/ (och liknande rutter), applikationsikonerna i olika storlekar.

Det är viktigt att den körbara filen är oberoende av platsen i filsystemetOm ditt program antar absoluta sökvägar som dessa: /usr/bin/miapp o /usr/share/miappDu kommer att få problem med att köra AppImage eftersom den vid körning är monterad på en annan tillfällig plats. Rätt tillvägagångssätt är arbeta med relativa rutter eller bygga dem dynamiskt från den faktiska sökvägen till binärfilen eller AppRun-skriptet.

En mer komplett AppDir kan se ut så här i en kataloglista:

$ 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/…

När du väl har den här strukturen, verktyg som linuxdeploy eller appimagetool (från AppImageKit) De kommer att ansvara för att konvertera din AppDir till den slutliga .AppImage-filen.

.desktop-fil och grundläggande skrivbordsintegration

.desktop-filen är en nyckelkomponent, både för AppImage och för att integrera alla skrivbordsapplikationer i GNU/Linux. Det är en enkel textfil med lämplig formatering. Skrivbordsinmatning som kan redigeras med en vanlig textredigerare eller med grafiska menyredigeringsverktyg.

Ett enkelt exempel på innehåll kan vara:

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

I det här exemplet är nyckeln Exec anger kommandot som ska köras (utan absolut sökväg) och, om i din AppRun konfigurerar PATH-filen för att inkludera ${HERE}/usr/binSystemet kommer att hitta binärfilen utan problem. Det är viktigt att betona att:

• Kategorierna är obligatoriska för många verktyg relaterade till AppImage (till exempel misslyckas vissa varianter av linuxdeploy om det inte definieras).
• Nyckeln Resultat för tillverkarlista Den är vanligtvis mappad till en filtyp nombre.png o nombre.svg vilket borde vara tillgängligt i de förväntade ikonkatalogerna (till exempel i AppDir under usr/share/icons eller bredvid .desktop beroende på arbetsflödet).

I vissa riktiga AppImages ser du att ikontangenten utelämnas eller hanteras något annorlunda. Ändå, om du vill undvika överraskningar (till exempel att ikoner inte visas korrekt när du använder .png istället för .svg) är det värt det. Definiera ikonen explicit och kontrollera att den ser bra ut på flera distributioner..

AppRun-skriptet: kärnan i körningen i AppImage

Filen AppRun Detta är startpunkten för AppImage. När användaren kör .AppImage-filen startas AppRun i den monterade AppDir. Det här skriptet kan vara ett enkelt skalskript som:

• Lös upp den faktiska sökvägen från vilken den körs (med hänsyn till symboliska länkar och temporala sammansättningar).
• Förbered miljövariabler såsom PATH, LD_LIBRARY_PATH och andra som ditt program behöver för att hitta bibliotek eller resurser.
• Starta den faktiska körbara filen (antingen genom att läsa Exec-nyckeln från .desktop eller genom att direkt anropa usr/bin/miapp).

Ett mycket vanligt mönster, som du hittar i AppImageKit, ser ut ungefär så här:

#!/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}" "$@"

Denna metod söker dynamiskt värdet av Exec i .desktop-filen och kör den med de argument som användaren anger, vilket är mycket flexibelt. Andra projekt väljer ännu enklare versioner. Till exempel använder Neovims AppImage en minimalistisk AppRun så här:

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

Oavsett vilken variant du använder är tanken att AppRun Den är inte beroende av absoluta systemsökvägar och kan fungera korrekt på vilken plats som helst. där AppImage är monterad.

Verktyg för att skapa AppImages: linuxdeploy, AppImageKit och Pkg2appimage

När du skapar ditt eget AppImage-paket har du flera huvudverktyg till ditt förfogande, vart och ett med sitt eget fokus. Det mest rekommenderade för moderna arbetsflöden är linuxdistributionäven om AppImageKit och Pkg2appimage fortfarande har sin plats.

linuxdistribution tar hand om Analysera din körbara fil, identifiera dess beroenden och bygg automatiskt AppDir-strukturen. lämplig (kopiera bibliotek till usr/lib(organisera filer, etc.). Det är särskilt användbart när du redan har en fungerande binärfil och vill paketera den utan att behöva fundera alltför mycket över vilka bibliotek som ska inkluderas.

För sin del, AppImageKit Den tillhandahåller bland annat verktyget appimagetoolvilket tar en redan monterad AppDir som indata och genererar .AppImage-filen från den. Du kan ladda ner appimagetool direkt från dess GitHub-arkiv; intressant nog, Den distribueras som en AppImageEn typisk användning skulle vara:

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

I miljöer som Docker eller CI är det viktigt att komma ihåg att AppImageKit kräver FUSE för att kunna montera avbildningen internt. Om FUSE inte är tillgängligt i containern eller på maskinen kan processen misslyckas, så det är lämpligt att kontrollera detta innan du automatiserar byggen.

Den tredje viktiga delen är Pkg2app, utformad för fall där du redan har ett befintligt paket (till exempel, tar.gz, .deb eller till och med PPA-arkivoch du vill konvertera den till en AppImage. Det här verktyget styrs via en .yml-beskrivningsfil, där du definierar var programvaran laddas ner ifrån, hur paketen installeras och vilka filer som hamnar i den resulterande AppDir.

Det typiska sättet att arbeta med Pkg2appimage är något i stil med detta:

1. Klona ett arkiv med lämplig .yml-fil. för det program du vill konvertera (till exempel en anpassad Packet Tracer YAML).
2. Ladda ner Pkg2appimage från ditt GitHub-arkiv och ge det körbehörigheter med chmod +x.
3. Justera .yml-filen för att uppdatera nedladdnings-URL:er som har ändrats eller nya beroenden.
4. Kasta ./pkg2appimage NombreArchivo.yml och vänta på att den slutliga AppDir och AppImage genererar.

Denna metod är mycket praktisk för Återvinn befintliga paket som inte fungerar bra på din distribution eller som kräver komplexa nedgraderingar av biblioteket. Pkg2appimage automatiserar mycket av det arbetet och ger dig en färdig .AppImage-fil för olika system.

Skapa en AppImage från din egen körbara enhet steg för steg

Tänk dig att du har ett enkelt program, till exempel ett projekt som heter Hej världen, med dess binära inställning i bin/ och deras bibliotek i lib/Du kan paketera den som en .zip-fil, lära dig hur man genererar en .deb- eller .rpm-fil, men du kan också Ta chansen att paketera den som en AppImageFlödet med linuxdeploy är vanligtvis ganska enkelt.

De grundläggande stegen skulle vara dessa: viktiga steg

1. Förbered miljön och hämta linuxdeploy

Den första är Ladda ner linuxdeploy-verktyget och gör det körbart.Den distribueras vanligtvis som användningsfärdiga binärfiler (till exempel som en AppImage). terminalanågot i stil med:

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

Dessutom, om du planerar att erbjuda effektiva uppdateringar via zsyncDu kan installera verktyget zsync, till exempel på Debian/Ubuntu-baserade system med:

sudo apt-get install zsync

2. Bygg AppDir-strukturen

Sedan skapar du en katalog som ska fungera som en AppDir (till exempel MiApp.AppDiroch inuti organiserar du minimistruktur Detta är nödvändigt. Du kan göra det manuellt eller låta linuxdeploy generera en del av det. Idén är:

• Placera din huvudsakliga körbara fil i MiApp.AppDir/usr/bin/. Till exempel, MiApp.AppDir/usr/bin/hello-world.
• Tillåt linuxdeploy att automatiskt kopiera de nödvändiga biblioteken a MiApp.AppDir/usr/lib/ när du kör den med lämpliga alternativ.
• Skapa .desktop-filen inom MiApp.AppDir/usr/share/applications/ med rätt fält: Namn, Kommentar, Exekvering, Ikon, Kategorier, etc.
• Förbered ikonerna och placera dem på typiska rutter MiApp.AppDir/usr/share/icons/hicolor/, och se till att värdet på ikontangenten i .desktop matchar filnamnet (utan filändelsen).

Det är viktigt att komma ihåg att i .desktop-fältet Exec ska peka på det körbara namnet exakt som linuxdeploy letar efter det i usr/bin. Om du använder Exec=hello-worldlinuxdeploy kommer att anta att i usr/bin Den körbara filen finns.

3. Kör linuxdeploy för att paketera programmet

Med AppDir-strukturen på plats, ange rutten till AppDir och, valfritt, specifika moduler eller plugins (till exempel för att integrera ikoner, .desktop-filer, etc.). linuxdeploy hanterar:

• Skanna huvudbinärfilen och identifiera vilka dynamiska bibliotek den behöver.
• Kopiera dessa bibliotek till usr/lib inom AppDir, förutsatt att de inte är bibliotek som antas redan finnas i användarens system.
• Förbered AppDir så att den senare kan bli en AppImage (ibland kan linuxdeploy självt generera AppImage i kombination med plugins).

Efter denna process kommer du att ha en fil med tillägget i den aktuella katalogen. .AppImage, som till exempel hello-world-x86_64.AppImagesom du kan kopiera vart du vill och köra på andra kompatibla GNU/Linux-system.

4. Gör den körbar och testa den på olika distributioner

När linuxdeploy (eller appimagetool) genererar AppImage är det mycket möjligt att i början har inte exekveringsbiten sattI så fall gör du helt enkelt följande:

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

Det rekommenderas starkt Testa din AppImage på olika distributioner och versionerDetta inkluderar en relativt gammal version inom det intervall du vill stödja (till exempel den lägsta versionen av Ubuntu eller Debian som du avser att stödja). Detta säkerställer att du inte har utelämnat några viktiga beroenden och att den körbara filen beter sig likadant överallt.