Hoe je stap voor stap een AppImage-pakket maakt in GNU/Linux

Als je dagelijks door de wereld van GNU/Linux navigeert, kom je vroeg of laat de beroemde bestanden tegen .AppImage-bestanden. U wilt graag weten wat ze zijn, hoe u ze gebruikt en hoe u stap voor stap uw eigen .AppImage-bestanden kunt maken.Het is niet zomaar "een ander formaat": AppImage heeft een duidelijke filosofie van overdraagbaarheid, minder verbroken afhankelijkheden en minder problemen met bibliotheekversies.

Bovendien, wanneer u uw eigen programma's gaat samenstellen of applicaties voor anderen gaat verpakken, ontdekt u al snel dat het onderhouden van .deb, .rpm en andere formaten voor elke distro zijn een echte hoofdpijnDat is waar AppImage, samen met tools zoals linuxdeploy, AppImageKit en Pkg2appimageHet vormt een zeer krachtig alternatief voor de distributie van desktopsoftware op vrijwel elke moderne distributie.

Wat is precies een AppImage-pakket en waarom is het de moeite waard?

Een AppImage-bestand is in wezen: een zelfstandig uitvoerbaar bestand voor GNU/Linux dat de applicatie en al zijn afhankelijkheden bevat De benodigde bestanden (dynamische bibliotheken, bronnen, pictogrammen, enz.) worden gecomprimeerd tot één image. In plaats van te worden geïnstalleerd zoals een traditioneel pakket dat bestanden over het systeem verspreidt, gedraagt ​​het zich als volgt:

• Een "draagbare" .exe in Windows, die u op een USB-stick kunt bewaren en overal kunt gebruiken.
• Een .dmg-bestand op macOS, die de applicatie bevat die u direct kunt gebruiken, zonder dat u een klassieke installatie hoeft uit te voeren.

Wanneer u een AppImage uitvoert, wordt het systeem intern gemount een gecomprimeerde ISO-image in alleen-lezen-modusHet bereidt de omgeving voor en start het programma erin. Zodra u de applicatie sluit, verdwijnt de tijdelijke koppeling. Er is geen daadwerkelijke "installatie" zoals bij DEB- of RPM-pakketten. Als u het bestand .AppImage verwijdert, verwijdert u ook het programma. zonder sporen achter te laten (behalve enkele configuratie- of integratiebestanden als deze zijn gegenereerd).

Dit formaat valt onder wat bekend staat als “Universele applicaties voor GNU/Linux”, samen met andere systemen zoals Flatpak en Snap (en, in mindere mate, voorstellen zoals OrbitalApps). Het idee is dat de ontwikkelaar Als u het één keer verpakt, kan de gebruiker het op elke moderne GNU/Linux-distributie uitvoeren.het vermijden van de hel die gepaard gaat met het onderhouden van specifieke versies voor Debian, Ubuntu, Fedora, openSUSE, etc.

Tot de interessantste kenmerken van AppImage behoren een aantal die het onderscheiden van traditionele pakketten: draagbaar, vereist geen toestemmingen wortel om uit te voeren en raakt noch de systeembibliotheken noch de algemene voorkeuren aanMet andere woorden: u kunt een AppImage downloaden, er uitvoeringsrechten aan geven en deze starten in een Live-omgeving. USB, in een stabiel systeem met oude repositories of in een vrij recente rolling release, zonder dat er iets gecompileerd hoeft te worden of afhankelijkheden opgelost hoeven te worden.

Voor- en nadelen van het AppImage-formaat in vergelijking met klassieke pakketten

Voordat u zich in het creatieproces verdiept, is het belangrijk om heel duidelijk te zijn over wat dit formaat te bieden heeft en wat de nadelen ervan zijn, vooral als u besluit of u uw applicatie wilt distribueren als een AppImage, als een native pakket of als beide..

Aan de positieve kant is een AppImage een Een zelfstandig binair bestand met de extensie .AppImage dat op vrijwel elke distributie draait zonder dat er iets extra's geïnstalleerd hoeft te worden (in de meeste gevallen behalve FUSE). Dit betekent dat:

• U bent niet afhankelijk van systeembibliothekenDe bibliotheken die uw programma nodig heeft, bevinden zich in het bestand zelf.
• Je hebt geen superuser-rechten nodig om de applicatie te gebruiken, aangezien bestanden niet worden gekopieerd naar systeempaden zoals /usr of /etc.
• Het is uiterst draagbaarU kunt meerdere AppImages op een USB-stick zetten en ze zonder problemen op verschillende computers en distributies gebruiken.
• Ze elimineren veel afhankelijkheidsconflicten, typisch voor “Ik wil een nieuwe versie van programma X gebruiken op een oude stabiele distributie”.
• Ze laten het toe gebruik recente applicaties op LTS of zeer conservatieve distributies (Debian stable, Ubuntu LTS, etc.) zonder het systeem te slopen.
• Ze zijn ideaal voor software testen zonder de veiligheid in gevaar te brengenvooral als je ze combineert met sandboxing (bijvoorbeeld Firejail).

Maar er zijn niet alleen maar voordelen. AppImage heeft ook zijn zwakke punten ten opzichte van de traditionele repositories van elke distributie. Bijvoorbeeld, applicaties al hun bibliotheken opnemende uiteindelijke maat is meestal groter dan die van een native pakket die gedeelde bibliotheken hergebruikt die al in het systeem aanwezig zijn. Verder:

• Desktopintegratie is niet altijd perfectEr zijn hulpmiddelen zoals appimaged of AppImageLauncher die dit kunnen verbeteren, maar in veel gevallen is er toch wat handmatig werk nodig (menu's, bestandskoppelingen, etc.).
• De AppImage-applicaties hebben doorgaans iets langer nodig om te starten.omdat de gecomprimeerde afbeelding eerst gemonteerd moet worden. Als de afbeelding eenmaal geopend is, werken ze echter normaal.
• Automatische updates zijn niet altijd goed geïmplementeerdEr zijn hulpmiddelen zoals AppImageUpdate en ondersteuning voor zsync, maar bij veel software moet u nog steeds de nieuwe AppImage downloaden en de oude handmatig vervangen.
• El De catalogus met applicaties in AppImage-formaat is niet erg uitgebreid. zoals die van de officiële repositories van de grote distributies, hoewel deze steeds vaker belangrijke projecten bevat (Krita, GIMP, Kdenlive, LibreOffice, enz.).
• Over het algemeen wordt dat overwogen Pakketten die in officiële repositories worden bewaard, ondergaan doorgaans een extra beveiligingscontrole Wat betreft binaire bestanden die rechtstreeks van een website worden gedownload, moeten we voorzichtig zijn met de oorsprong van de AppImages die we gebruiken.

Toch is AppImage voor veel scenario's een zeer praktische oplossing: bijvoorbeeld, Toepassingen uitvoeren die niet in de repositories van uw distributie staan, absurde afhankelijkheden overslaan of actuele software gebruiken op oude machinesEn vanuit het oogpunt van de ontwikkelaar bespaart het een hoop werk als er één AppImage voor alle distributies wordt verpakt.

Hoe een AppImage intern is gestructureerd: de AppDir-directory

De meeste tools die AppImages genereren, werken volgens een basisconcept: AppDir, een directory met een structuur die wordt herkend door het AppImage-ecosysteemAlles wat in het .AppImage-bestand terechtkomt, wordt eerst in die directorystructuur georganiseerd.

In zijn minimale vorm heeft een AppDir minimaal nodig drie sleutelbestanden in uw root:

• AppRun: el script of uitvoerbaar bestand dat wordt gestart wanneer u dat doet ./MiPrograma.AppImageHet is verantwoordelijk voor het voorbereiden van de omgeving (PATH, LD_LIBRARY_PATH, enz.) en voor het uitvoeren van de daadwerkelijke toepassing.
• Een .desktop-bestand: bevat de toepassingsmetagegevens (naam, opmerking, categorieën, pictogram, uitvoeringsopdracht…) volgens de Desktop Entry-specificatie van freedesktop.org.
• Een icoon (meestal .png of .svg): wordt gebruikt om het AppImage-bestandspictogram weer te geven in bestandsverkenners en voor systeemgeïntegreerde applicatiestarters.

Naast deze minimale basis volgt de AppDir doorgaans een structuur die vergelijkbaar is met die van een conventioneel GNU/Linux-systeem, met inachtneming van de FHS (Filesystem Hierarchy Standard). Dat wil zeggen, Maak submappen zoals ./usr/bin, ./usr/lib of ./usr/shareJe plaatst het volgende erin:

• En usr/bin/, het belangrijkste binaire bestand van uw applicatie (bijvoorbeeld, hello-world, Rectball, nvim, Enz.).
• En usr/lib/, de gedeelde bibliotheken (.so) die uw programma nodig heeft en waarvan u niet mag aannemen dat de gebruiker deze op zijn systeem heeft geïnstalleerd.
• En usr/share/applicaties/, het bestand .desktop die de applicatie beschrijft.
• En usr/share/icons/hicolor/ (en vergelijkbare routes), de applicatie-iconen in verschillende formaten.

Het is essentieel dat het uitvoerbare bestand onafhankelijk van de locatie in het bestandssysteemAls uw programma absolute paden aanneemt zoals deze: /usr/bin/miapp o /usr/share/miappJe zult problemen ondervinden bij het uitvoeren van de AppImage, omdat deze tijdens runtime op een andere tijdelijke locatie is gemount. De juiste aanpak is: werken met relatieve routes of ze dynamisch opbouwen vanuit het werkelijke pad van het binaire bestand of het AppRun-script.

Een completere AppDir zou er in een directorylijst als volgt uit kunnen zien:

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

Als je eenmaal deze structuur hebt, kun je gebruikmaken van hulpmiddelen zoals linuxdeploy of appimagetool (van AppImageKit) Zij zijn verantwoordelijk voor het converteren van uw AppDir naar het uiteindelijke .AppImage-bestand.

.desktop-bestand en basis-desktopintegratie

Het .desktop-bestand is een belangrijk onderdeel, zowel voor AppImage als voor de integratie van elke desktopapplicatie in GNU/Linux. Het is een eenvoudig tekstbestand met de juiste opmaak. Bureaubladinvoer die bewerkt kunnen worden met een eenvoudige teksteditor of met grafische menubewerkingshulpmiddelen.

Een eenvoudig voorbeeld van inhoud zou kunnen zijn:

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

In dit voorbeeld is de sleutel Exec geeft de uit te voeren opdracht aan (zonder absoluut pad) en, indien in uw AppRun configureert het PATH om ${HERE}/usr/binHet systeem zal het binaire bestand zonder problemen vinden. Het is belangrijk om te benadrukken dat:

• Het veld Categorieën is verplicht voor veel hulpmiddelen die gerelateerd zijn aan AppImage (sommige varianten van linuxdeploy mislukken bijvoorbeeld als deze niet is gedefinieerd).
• De sleutel Pictogram Het wordt meestal toegewezen aan een bestandstype nombre.png o nombre.svg die toegankelijk zou moeten zijn in de verwachte pictogrammappen (bijvoorbeeld in de AppDir onder usr/share/icons of naast de .desktop, afhankelijk van de workflow).

In sommige echte AppImages zie je dat de Icon-toets ontbreekt of iets anders wordt gebruikt. Toch is het de moeite waard als je verrassingen wilt voorkomen (bijvoorbeeld dat pictogrammen niet correct worden weergegeven bij gebruik van .png in plaats van .svg). Definieer het pictogram expliciet en controleer of het er op verschillende distributies goed uitziet..

Het AppRun-script: het hart van de uitvoering in AppImage

het bestand AppRun Dit is het startpunt voor de AppImage. Wanneer de gebruiker het .AppImage-bestand uitvoert, wordt AppRun in de gekoppelde AppDir gestart. Dit script kan een eenvoudig shellscript zijn dat:

• Bepaal het daadwerkelijke pad van waaruit het wordt uitgevoerd (rekening houdend met symbolische koppelingen en tijdelijke samenstellingen).
• Omgevingsvariabelen voorbereiden zoals PATH, LD_LIBRARY_PATH en andere die uw programma nodig heeft om bibliotheken of bronnen te vinden.
• Start het daadwerkelijke uitvoerbare bestand (hetzij door de Exec-sleutel van het .desktop-bestand te lezen, hetzij door het rechtstreeks aan te roepen usr/bin/miapp).

Een veelvoorkomend patroon, dat je in AppImageKit tegenkomt, ziet er ongeveer zo uit:

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

Deze aanpak zoekt dynamisch naar de waarde van Exec in het .desktop-bestand en voert het uit met de door de gebruiker meegegeven argumenten, wat zeer flexibel is. Andere projecten kiezen voor nog eenvoudigere versies. Zo gebruikt Neovim's AppImage een minimalistische AppRun zoals deze:

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

Welke variant u ook gebruikt, het idee is dat AppRun Het is niet afhankelijk van absolute systeempaden en kan op elke locatie correct functioneren. waar de AppImage is gemonteerd.

Hulpmiddelen voor het maken van AppImages: linuxdeploy, AppImageKit en Pkg2appimage

Bij het maken van uw eigen AppImage-pakket heeft u verschillende hoofdtools tot uw beschikking, elk met een eigen focus. De meest aanbevolen tool voor moderne workflows is linuxdeployhoewel AppImageKit en Pkg2appimage nog steeds hun plaats hebben.

linuxdeploy zorgt voor Analyseer uw uitvoerbare bestand, detecteer de afhankelijkheden en bouw automatisch de AppDir-structuur. geschikt (het kopiëren van bibliotheken naar usr/lib(bestanden organiseren, enz.). Dit is vooral handig als je al een werkend binair bestand hebt en dit wilt verpakken zonder al te veel na te denken over welke bibliotheken je moet toevoegen.

Van haar kant, AppImageKit Het biedt onder andere de tool appimagetooldie een reeds gekoppelde AppDir als invoer gebruikt en daaruit het .AppImage-bestand genereert. Je kunt appimagetool rechtstreeks downloaden van de GitHub-repository; interessant genoeg, Het wordt gedistribueerd als een AppImageEen typisch gebruik zou zijn:

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

In omgevingen zoals Docker of CI is het belangrijk om in gedachten te houden dat AppImageKit vereist FUSE om de image intern te kunnen mounten. Als FUSE niet beschikbaar is in de container of op de machine, kan het proces mislukken. Het is daarom raadzaam dit te controleren voordat u builds automatiseert.

Het derde belangrijke stuk is PKg2appafbeelding, ontworpen voor gevallen waarin u al een bestaand pakket heeft (bijvoorbeeld tar.gz, .deb of zelfs PPA-repositoriesen je wilt het omzetten naar een AppImage. Deze tool wordt aangestuurd via een .yml-beschrijvingsbestand, waar u definieert waar de software wordt gedownload, hoe de pakketten worden geïnstalleerd en welke bestanden in de resulterende AppDir terechtkomen.

De typische manier om met Pkg2appimage te werken is ongeveer als volgt:

1. Kloon een repository met het juiste .yml-bestand. voor de applicatie die u wilt converteren (bijvoorbeeld een aangepaste Packet Tracer YAML).
2. Download Pkg2appimage vanuit je GitHub-repository en geef het uitvoeringsrechten met chmod +x.
3. Pas het .yml-bestand aan om gewijzigde download-URL's of nieuwe afhankelijkheden bij te werken.
4. Gooien ./pkg2appimage NombreArchivo.yml en wacht tot de definitieve AppDir en AppImage zijn gegenereerd.

Deze aanpak is zeer praktisch voor Recycle bestaande pakketten die niet goed werken op uw distributie of die complexe bibliotheekdowngrades vereisen. Pkg2appimage automatiseert veel van dat werk en geeft u een kant-en-klare .AppImage voor verschillende systemen.

Maak stap voor stap een AppImage van uw eigen uitvoerbare bestand

Stel je voor dat je een eenvoudig programma hebt, bijvoorbeeld een project genaamd Hallo Wereld, met zijn binaire in bin/ en hun bibliotheken in lib/U kunt het inpakken als een .zip, leer hoe u een .deb- of .rpm-bestand genereert, maar u kunt ook Maak van de gelegenheid gebruik om het te verpakken als een AppImageDe workflow van LinuxDeploy is doorgaans vrij eenvoudig.

De basisstappen zijn als volgt: belangrijkste stappen

1. Bereid de omgeving voor en verkrijg LinuxDeploy

Het eerste is Download de linuxdeploy-tool en maak deze uitvoerbaar.Meestal wordt het gedistribueerd als kant-en-klare binaire bestanden (bijvoorbeeld als een AppImage). terminalzoiets als:

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

Als u bovendien van plan bent om efficiënte updates via zsyncU kunt het hulpprogramma zsync bijvoorbeeld op Debian/Ubuntu-gebaseerde systemen installeren met:

sudo apt-get install zsync

2. Bouw de AppDir-structuur

Vervolgens maakt u een directory aan die zal functioneren als een AppDir (bijvoorbeeld MiApp.AppDiren binnenin organiseer je de minimale structuur Dit is noodzakelijk. Je kunt het handmatig doen of een deel ervan door LinuxDeploy laten genereren. Het idee is:

• Plaats uw belangrijkste uitvoerbare bestand in MiApp.AppDir/usr/bin/. Bijvoorbeeld MiApp.AppDir/usr/bin/hello-world.
• Laat linuxdeploy automatisch de vereiste bibliotheken kopiëren a MiApp.AppDir/usr/lib/ wanneer u het uitvoert met de juiste opties.
• Maak het .desktop-bestand binnen MiApp.AppDir/usr/share/applications/ met de juiste velden: Naam, Commentaar, Uitvoering, Icoon, Categorieën, etc.
• Bereid de pictogrammen voor en plaats ze op typische routes MiApp.AppDir/usr/share/icons/hicolor/, waarbij u ervoor zorgt dat de waarde van de Icon-toets in het .desktopbestand overeenkomt met de bestandsnaam (zonder de extensie).

Het is belangrijk om te onthouden dat in het .desktop-veld Exec moet naar de naam van het uitvoerbare bestand verwijzen, precies zoals LinuxDeploy ernaar zal zoeken usr/bin. Als u gebruikt Exec=hello-world, linuxdeploy zal ervan uitgaan dat in usr/bin Dat uitvoerbare bestand bestaat.

3. Voer linuxdeploy uit om de applicatie te verpakken

Met de AppDir-structuur op zijn plaats, geef de route aan naar AppDir en, optioneel, specifieke modules of plug-ins (bijvoorbeeld om pictogrammen, .desktop-bestanden, enz. te integreren). linuxdeploy verwerkt:

• Scan het belangrijkste binaire bestand en detecteren welke dynamische bibliotheken nodig zijn.
• Kopieer die bibliotheken naar usr/lib binnen de AppDir, mits het geen bibliotheken zijn waarvan wordt aangenomen dat ze al in het systeem van de gebruiker aanwezig zijn.
• Maak de AppDir gereed zodat het later een AppImage kan worden (soms kan linuxdeploy zelf de AppImage genereren in combinatie met plugins).

Na dit proces heeft u een bestand met de extensie in de huidige map. .AppAfbeelding, zoals bijvoorbeeld hello-world-x86_64.AppImagedie u kunt kopiëren waar u maar wilt en kunt uitvoeren op andere compatibele GNU/Linux-systemen.

4. Maak het uitvoerbaar en test het op verschillende distributies

Wanneer linuxdeploy (of appimagetool) de AppImage genereert, is het zeer goed mogelijk dat in het begin heb de uitvoeringsbit niet ingesteldIn dat geval doet u het volgende:

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

Het wordt ten zeerste aanbevolen dat Test uw AppImage op verschillende distributies en versiesDit omvat een relatief oude versie binnen het bereik dat u wilt ondersteunen (bijvoorbeeld de minimale versie van Ubuntu of Debian die u wilt ondersteunen). Zo weet u zeker dat u geen belangrijke afhankelijkheden vergeet en dat het uitvoerbare bestand overal hetzelfde werkt.