Comment créer un package AppImage étape par étape sous GNU/Linux

Si vous naviguez quotidiennement dans l'univers GNU/Linux, vous finirez tôt ou tard par rencontrer les fameux fichiers Les fichiers .AppImage, et vous voudrez comprendre ce qu'ils sont, comment les utiliser et comment créer les vôtres étape par étape.Il ne s'agit pas simplement d'un « autre format » : derrière AppImage se cache une philosophie très claire de portabilité, de réduction des dépendances cassées et de réduction des problèmes liés aux versions des bibliothèques.

De plus, lorsque vous commencez à compiler vos propres programmes ou à empaqueter des applications pour d'autres, vous découvrez rapidement que la maintenance Les formats .deb, .rpm et autres pour chaque distribution, c'est un vrai casse-tête !C'est là qu'AppImage, ainsi que des outils comme linuxdeploy, AppImageKit et Pkg2appimageElle devient ainsi une alternative très puissante pour la distribution de logiciels de bureau sur presque toutes les distributions modernes.

Qu'est-ce qu'un package AppImage exactement et pourquoi est-il utile ?

Un fichier AppImage est, essentiellement, un exécutable autonome pour GNU/Linux qui inclut l'application et toutes ses dépendances Les fichiers nécessaires (bibliothèques dynamiques, ressources, icônes, etc.) sont compressés dans une seule image. Au lieu de s'installer comme un paquet traditionnel qui distribue les fichiers dans tout le système, son fonctionnement est similaire à celui d'un système d'installation classique.

• Un fichier .exe « portable » dans Windowsque vous pouvez emporter sur une clé USB et exécuter où que vous soyez.
• Un fichier .dmg sur macOS, qui contient l'application prête à l'emploi sans installation classique.

Lorsque vous exécutez une AppImage, le système effectue un montage interne. une image ISO compressée en mode lecture seuleIl prépare l'environnement et lance le programme. Une fois l'application fermée, le montage temporaire disparaît. Il n'y a pas d'« installation » à proprement parler, comme avec les paquets DEB ou RPM. Si vous supprimez le fichier .AppImage, vous supprimerez le programme. sans laisser aucune trace (à l'exception de certains fichiers de configuration ou d'intégration s'ils ont été générés).

Ce format relève de ce que l'on appelle « Applications universelles pour GNU/Linux », ainsi que d'autres systèmes tels que Flatpak et Snap (et, dans une moindre mesure, des propositions comme OrbitalApps). L'idée est que le développeur Il suffit de le conditionner une seule fois et l'utilisateur peut l'exécuter sur n'importe quelle distribution GNU/Linux moderne.éviter le calvaire que représente la maintenance de versions spécifiques pour Debian, Ubuntu, Fedora, openSUSE, etc.

Parmi les caractéristiques les plus intéressantes d'AppImage, on peut citer plusieurs qui la différencient des packages traditionnels : portable, ne nécessite pas d'autorisations racine s'exécute sans toucher aux bibliothèques système ni aux préférences globalesAutrement dit, vous pouvez télécharger une AppImage, lui accorder les autorisations d'exécution et la lancer dans un environnement Live. USB, dans un système stable avec d'anciens dépôts ou dans une version à mise à jour continue assez récente, sans avoir à compiler quoi que ce soit ni à résoudre les dépendances.

Avantages et inconvénients du format AppImage par rapport aux packages classiques

Avant de vous plonger dans le processus de création, il est important de bien comprendre ce que ce format offre et quels sont ses inconvénients, surtout si vous êtes en train de décider. choisir de distribuer votre application sous forme d'AppImage, de package natif ou des deux..

Du côté positif, une AppImage est une Un fichier binaire autonome avec l'extension .AppImage qui fonctionne sur pratiquement toutes les distributions. sans avoir besoin d'installer quoi que ce soit de plus (à part FUSE dans la plupart des cas). Cela signifie que :

• Vous n'êtes pas dépendant des bibliothèques systèmeLes bibliothèques nécessaires à votre programme sont contenues dans le fichier lui-même.
• Vous n'avez pas besoin des droits de superutilisateur. pour utiliser l'application, car les fichiers ne sont pas copiés dans les chemins système tels que /usr ou /etc.
• Il est extrêmement portableVous pouvez placer plusieurs AppImages sur une clé USB et les utiliser sans problème sur différents ordinateurs et distributions.
• Ils éliminent de nombreux conflits de dépendance., typique de « Je veux utiliser une nouvelle version du programme X sur une ancienne distribution stable ».
• Ils permettent utiliser des applications récentes sur des distributions LTS ou très conservatrices (Debian stable, Ubuntu LTS, etc.) sans endommager le système.
• Ils sont idéaux pour tester les logiciels sans compromettre la sécuritésurtout si vous les combinez avec le sandboxing (par exemple, Firejail).

Cependant, tout n'est pas sans inconvénients. AppImage présente également des faiblesses par rapport aux dépôts traditionnels de chaque distribution. Par exemple, les applications y compris toutes leurs bibliothèquesla taille finale est généralement supérieur à celui d'un package natif qui réutilise des bibliothèques partagées déjà présentes dans le système. De plus :

• L'intégration au bureau n'est pas toujours parfaite.Il existe des outils comme AppImageD ou AppImageLauncher pour améliorer cela, mais dans de nombreux cas, un travail manuel est nécessaire (menus, associations de fichiers, etc.).
• Les Les applications AppImage mettent généralement un peu plus de temps à démarrer.car l'image compressée doit d'abord être montée, même si une fois ouverte, elle fonctionne normalement.
• Les mises à jour automatiques ne sont pas toujours bien implémentées.Il existe des outils comme AppImageUpdate ou la prise en charge de zsync, mais de nombreux logiciels nécessitent encore le téléchargement de la nouvelle AppImage et le remplacement manuel de l'ancienne.
• El Le catalogue d'applications au format AppImage n'est pas très étendu. comme celle des dépôts officiels des principales distributions, bien qu'elle inclue de plus en plus de projets importants (Krita, GIMP, Kdenlive, LibreOffice, etc.).
• En général, on considère que Les paquets hébergés dans les dépôts officiels font généralement l'objet d'un examen de sécurité supplémentaire. Concernant les fichiers binaires téléchargés directement depuis un site web, il convient d'être vigilant quant à l'origine des AppImages que nous utilisons.

Néanmoins, dans de nombreux cas, AppImage constitue une solution très pratique : par exemple, Exécuter des applications qui ne figurent pas dans les dépôts de votre distribution, ignorer des dépendances absurdes ou utiliser des logiciels récents sur des machines anciennes.Du point de vue du développeur, le fait de proposer une seule AppImage pour toutes les distributions permet de gagner beaucoup de temps.

Structure interne d'une AppImage : le répertoire AppDir

La plupart des outils qui génèrent des AppImages fonctionnent à partir d'un concept de base : AppDir, un répertoire dont la structure est reconnue par l'écosystème AppImageTout ce qui se retrouvera dans le fichier .AppImage est d'abord organisé dans cette arborescence de répertoires.

Dans sa forme minimale, un AppDir nécessite au moins trois fichiers clés dans votre répertoire racine:

• Apprun: L' scénario ou un exécutable qui se lance lorsque vous faites ./MiPrograma.AppImageIl est responsable de la préparation de l'environnement (PATH, LD_LIBRARY_PATH, etc.) et de l'exécution de l'application proprement dite.
• Un fichier .desktop: contient les métadonnées de l'application (nom, commentaire, catégories, icône, commande d'exécution…) conformément à la spécification Desktop Entry de freedesktop.org.
• Une icône (généralement .png ou .svg) : utilisé à la fois pour afficher l’icône du fichier AppImage dans les explorateurs de fichiers et pour les lanceurs d’applications intégrés au système.

Au-delà de cette base minimale, le répertoire d'application (AppDir) adopte généralement une structure similaire à celle d'un système GNU/Linux classique, respectant la norme FHS (Filesystem Hierarchy Standard). Autrement dit, Créez des sous-répertoires tels que ./usr/bin, ./usr/lib ou ./usr/shareVous y placerez les éléments suivants :

• En utilisateur/bin/, le fichier binaire principal de votre application (par exemple, hello-world, Rectball, nvim, Etc).
• En utilisateur/lib/, les bibliothèques partagées (.so) dont votre programme a besoin et que vous ne devez pas supposer que l'utilisateur a installées sur son système.
• En utilisateur/partage/applications/, l'archive .desktop qui décrit l'application.
• En usr/share/icons/hicolor/ (et itinéraires similaires), les icônes de l'application en différentes tailles.

Il est essentiel que l'exécutable soit indépendamment de l'emplacement dans le système de fichiersSi votre programme suppose des chemins absolus comme celui-ci : /usr/bin/miapp o /usr/share/miappVous rencontrerez des problèmes lors de l'exécution de l'AppImage car, au moment de l'exécution, elle est montée dans un emplacement temporaire différent. La méthode correcte est la suivante : travailler avec des itinéraires relatifs ou les construire dynamiquement à partir du chemin réel du fichier binaire ou du script AppRun.

Un répertoire AppDir plus complet pourrait ressembler à ceci dans une liste de répertoires :

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

Une fois cette structure en place, des outils comme linuxdeploy ou appimagetool (depuis AppImageKit) Ils seront chargés de convertir votre fichier AppDir en fichier .AppImage final.

fichier .desktop et intégration de base au bureau

Le fichier .desktop est un élément essentiel, tant pour AppImage que pour l'intégration de toute application de bureau sous GNU/Linux. Il s'agit d'un simple fichier texte correctement formaté. Entrée de bureau qui peut être modifié avec un simple éditeur de texte ou avec des utilitaires d'édition de menus graphiques.

Un exemple simple de contenu pourrait être :

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

Dans cet exemple, la clé Exec indique la commande à exécuter (sans chemin absolu) et, si dans votre AppRun configure le PATH pour inclure ${HERE}/usr/binLe système trouvera le fichier binaire sans problème. Il est important de souligner que :

• L'entrée dans la catégorie est obligatoire. pour de nombreux outils liés à AppImage (par exemple, certaines variantes de linuxdeploy échouent si celui-ci n'est pas défini).
• La clé Icône Il est généralement associé à un type de fichier nombre.png o nombre.svg qui devraient être accessibles dans les répertoires d'icônes attendus (par exemple, dans le répertoire AppDir sous usr/share/icons ou en parallèle du .desktop selon le flux de travail).

Dans certaines AppImages réelles, vous constaterez que la clé Icon est omise ou gérée différemment. Malgré cela, si vous souhaitez éviter les mauvaises surprises (par exemple, des icônes qui ne s'affichent pas correctement avec l'extension .png au lieu de .svg), cela vaut la peine. Définissez explicitement l'icône et vérifiez qu'elle s'affiche correctement sur plusieurs distributions..

Le script AppRun : le cœur de l’exécution dans AppImage

L'archive Apprun Il s'agit du point d'entrée de l'AppImage. Lorsque l'utilisateur exécute le fichier .AppImage, c'est en réalité AppRun qui est lancé dans le répertoire AppDir monté. Ce script peut être un simple script shell qui :

• Déterminez le chemin d'accès réel à partir duquel il s'exécute. (en tenant compte des liens symboliques et des assemblages temporels).
• Préparer les variables d'environnement comme PATH, LD_LIBRARY_PATH et autres variables dont votre programme a besoin pour trouver des bibliothèques ou des ressources.
• Lancez le fichier exécutable. (soit en lisant la clé Exec à partir du fichier .desktop, soit en invoquant directement) usr/bin/miapp).

Un modèle très courant, que vous trouverez dans AppImageKit, ressemble à ceci :

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

Cette approche recherche dynamiquement la valeur de Exec dans le fichier .desktop et l'exécute avec les arguments transmis par l'utilisateur, ce qui offre une grande flexibilité. D'autres projets optent pour des versions encore plus simples. Par exemple, l'AppImage de Neovim utilise un AppRun minimaliste comme celui-ci :

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

Quelle que soit la variante utilisée, l'idée est qu'AppRun Il ne dépend pas des chemins système absolus et peut fonctionner correctement quel que soit l'emplacement. où l'AppImage est montée.

Outils pour la création d'AppImages : linuxdeploy, AppImageKit et Pkg2appimage

Lors de la création de votre propre package AppImage, vous disposez de plusieurs outils principaux, chacun ayant sa propre spécificité. Le plus recommandé pour les flux de travail modernes est : linuxdeploybien qu'AppImageKit et Pkg2appimage conservent leur utilité.

linuxdeploy il est chargé de Analysez votre exécutable, détectez ses dépendances et construisez automatiquement la structure AppDir. approprié (copie des bibliothèques vers usr/lib(organisation des fichiers, etc.). C'est particulièrement utile lorsque vous disposez déjà d'un binaire fonctionnel et que vous souhaitez le conditionner sans trop vous soucier des bibliothèques à inclure.

Pour sa part, AppImageKit Il fournit, entre autres, l'outil outil d'image d'applicationqui prend en entrée un répertoire AppDir prémonté et génère le fichier .AppImage à partir de celui-ci. Vous pouvez télécharger appimagetool directement depuis son dépôt GitHub ; chose intéressante, Il est distribué sous forme d'AppImage.Une utilisation typique serait :

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

Dans des environnements comme Docker ou CI, il est important de garder à l'esprit que AppImageKit nécessite FUSE Pour pouvoir monter l'image en interne. Si FUSE n'est pas disponible dans le conteneur ou sur la machine, le processus risque d'échouer ; il est donc conseillé de vérifier ce point avant d'automatiser les builds.

Le troisième élément important est pkg2appimage, conçu pour les cas où vous disposez déjà d'un package existant (par exemple, dépôts tar.gz, .deb ou même PPAet vous souhaitez le convertir en AppImage. Cet outil est contrôlé par un fichier de description .yml, où vous définissez l'emplacement de téléchargement du logiciel, la manière dont les paquets sont installés et les fichiers qui se retrouvent dans le répertoire AppDir résultant.

La méthode classique pour travailler avec Pkg2appimage ressemble à ceci :

1. Clonez un dépôt contenant le fichier .yml approprié. pour l'application que vous souhaitez convertir (par exemple, un fichier YAML Packet Tracer personnalisé).
2. Télécharger Pkg2appimage depuis votre dépôt GitHub et accordez-lui les permissions d'exécution avec chmod +x.
3. Modifiez le fichier .yml pour mettre à jour les URL de téléchargement qui ont changé ou les nouvelles dépendances.
4. Jeter ./pkg2appimage NombreArchivo.yml et attendez que le programme génère les fichiers AppDir et AppImage finaux.

Cette approche est très pratique pour Réutilisez les paquets existants qui ne fonctionnent pas correctement sur votre distribution. ou qui nécessitent des rétrogradations complexes de bibliothèques. Pkg2appimage automatise une grande partie de ce travail et vous fournit un fichier .AppImage prêt à l'emploi pour différents systèmes.

Créez une AppImage à partir de votre propre exécutable, étape par étape.

Imaginez que vous ayez un programme simple, par exemple un projet appelé Bonjour le monde, avec son binaire dans bin/ et leurs bibliothèques dans lib/Vous pouvez le compresser au format .zip, apprendre à générer un fichier .deb ou .rpm, mais vous pouvez aussi Profitez-en pour le conditionner en tant qu'AppImage.Le processus avec linuxdeploy est généralement assez simple.

Les étapes de base seraient les suivantes : étapes clés

1. Préparez l'environnement et obtenez linuxdeploy

La première est Téléchargez l'outil linuxdeploy et rendez-le exécutable.Il est généralement distribué sous forme de fichiers binaires prêts à l'emploi (par exemple, sous forme d'AppImage). terminalquelque chose comme :

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

De plus, si vous prévoyez d'offrir Mises à jour efficaces via zsyncVous pouvez installer l'utilitaire zsync, par exemple sur les systèmes basés sur Debian/Ubuntu, avec :

sudo apt-get install zsync

2. Construire la structure AppDir

Ensuite, vous créez un répertoire qui servira de répertoire d'application (par exemple, MiApp.AppDiret à l'intérieur vous organisez le structure minimale C'est nécessaire. Vous pouvez le faire manuellement ou laisser linuxdeploy en générer une partie. L'idée est la suivante :

• Placez votre fichier exécutable principal dans MiApp.AppDir/usr/bin/. Par exemple, MiApp.AppDir/usr/bin/hello-world.
• Autoriser linuxdeploy à copier automatiquement les bibliothèques requises a MiApp.AppDir/usr/lib/ lorsque vous l'exécutez avec les options appropriées.
• Créez le fichier .desktop dans MiApp.AppDir/usr/share/applications/ avec les champs corrects : Nom, Commentaire, Direction, Icône, Catégories, etc.
• Préparer les icônes et les placer sur des itinéraires typiques MiApp.AppDir/usr/share/icons/hicolor/, en veillant à ce que la valeur de la clé Icon dans le fichier .desktop corresponde au nom du fichier (sans l'extension).

Il est important de se rappeler que dans le champ .desktop Exec doit pointer vers le nom de l'exécutable exactement tel que linuxdeploy le recherchera. usr/bin. Si vous utilisez Exec=hello-worldlinuxdeploy supposera que dans usr/bin Ce fichier exécutable existe.

3. Exécutez linuxdeploy pour empaqueter l'application.

Avec la structure AppDir en place, indiquer l'itinéraire vers AppDir et, éventuellement, des modules ou plugins spécifiques (par exemple, pour intégrer des icônes, des fichiers .desktop, etc.). linuxdeploy gère :

• Analyser le binaire principal et détecter les bibliothèques dynamiques dont il a besoin.
• Copiez ces bibliothèques dans usr/lib dans le répertoire AppDir, à condition qu'il ne s'agisse pas de bibliothèques supposées déjà présentes dans le système de l'utilisateur.
• Préparez le répertoire d'applications afin qu'elle puisse ultérieurement devenir une AppImage (parfois, linuxdeploy lui-même peut générer l'AppImage en combinaison avec des plugins).

Après ce processus, vous aurez un fichier avec l'extension dans le répertoire courant. .AppImage, comme par exemple hello-world-x86_64.AppImageque vous pouvez copier où vous le souhaitez et exécuter sur d'autres systèmes GNU/Linux compatibles.

4. Rendez-le exécutable et testez-le sur différentes distributions.

Lorsque linuxdeploy (ou appimagetool) génère l'AppImage, il est très possible qu'au début le bit d'exécution n'est pas activéDans ce cas, il vous suffit de procéder comme suit :

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

Il est fortement recommandé Testez votre AppImage sur différentes distributions et versionsCela inclut une version relativement ancienne parmi celles que vous souhaitez prendre en charge (par exemple, la version minimale d'Ubuntu ou de Debian que vous prévoyez de prendre en charge). Cela garantit qu'aucune dépendance importante n'a été omise et que l'exécutable se comporte de la même manière sur tous les systèmes.