Convertir proprement une AppImage en paquet ? Aeryth le fait en une commande : ce script Bash GPL v3 emballe votre AppImage en .deb ou .tar.zst, ajoute icône et lanceur, et s’installe/désinstalle via apt ou pacman.
Pourquoi Aeryth ?
Le format AppImage simplifie la distribution d’applications Linux, mais pose trois soucis :
- Intégration bureau (menus, icônes) absente au sein de l'environnement.
- Mises à jour invisibles pour le gestionnaire de paquets.
Aeryth règle ces points : il transforme toute AppImage en véritable paquet Debian (.deb) ou Arch (.tar.zst) prêt à être executé, et offre des options d'intégration d'un AppImage complet ou extrait au sein du paquet. 🤝
La documentation est très explicite sur le dépôt git sur GitLab, l'outil peut être au choix totalement ou partiellement interactif, ou 100% CLI utilisable des arguments et intégrable. 🙂
Il est en outre pensé multi-platforme, avec une gestion chroot et deboostrap pour pouvoir générer des paquets deb ou archlinux sur les deux familles de distributions, il est même possible de forcer le chroot pour ne pas devoir "polluer" la distribution actuellement utilisée même si elle peut générer nativement les paquets.
Il est pensé pour s'adapter à des utilisateurs néophytes ou confirmés. 😉
Fonctions principales
| Fonction | Description |
|---|---|
| Double cible | Génère un paquet .deb ou .tar.zst
|
| Multilingue | Interface interactive : FR · EN · ES · IT · DE |
| Respect FHS | Copie l’AppImage sous /opt/<app>/, wrapper dans /usr/bin
|
| Licence | GPL v3 |
Installation rapide
git clone https://gitlab.com/pepinature/aeryth.git
cd aeryth
chmod +x aeryth.shFeuille de route
- Détection automatique des nouvelles versions AppImage.
- CI : tests sur Debian 12, Ubuntu 24.04, Arch stable.
Ressources
- Dépôt : https://gitlab.com/pepinature/aeryth
- Aide rapide :
./aeryth.sh --help
Aller plus loin
- Dépôt (21 clics)
# Commentaire supprimé
Posté par MarinaCarreno . Évalué à -1 (+0/-1). Dernière modification le 15 juillet 2025 à 20:26.
Ce commentaire a été supprimé par l’équipe de modération.
# Zones d'ombre
Posté par Vincent Danjean . Évalué à 1 (+0/-0). Dernière modification le 15 juillet 2025 à 22:53.
Bonjour,
Pour moi, à partir de la description et du dépôt git indiqué, il reste plusieurs zones d'ombre sur le fonctionnement de ce logiciel :
ré-empaqueter un AppImage dans un .deb (par exemple) permet que les fichiers installés soient visibles par le gestionnaire de paquet. Mais ça ne change rien aux mises à jour ? Elles sont toujours invisibles avec APT (par exemple) puisqu'il faut explicitement recréer un nouveau .deb à partir d'un nouveau AppImage
je ne vois pas comment le boulot des mainteneurs de paquets pourra être fait automatiquement par aeryth : comment s'assurer que les bibliothèques systèmes sont utilisées et compatibles avec le logiciel AppImage (ou comme gérer quand l'AppImage apporte une bibliothèque déjà présente sur le système), comment s'assurer que le logiciel est bien compatible avec le reste des logiciels installés (système de son, etc.), …
Si c'est juste pour dépaqueter le AppImage dans /opt/, ça respecte peut-être le FSH, mais pas le standard des .deb officiels par exemple (et ça ne fait rien contre la multiplication des bibliothèques et donc de l'empreinte mémoire de ces bibliothèques en RAM qui ne peuvent plus partager leur code, ni pour la sécurité par mise à jour des bibliothèques problématiques)
[^] # Re: Zones d'ombre
Posté par tikilou (site web personnel) . Évalué à 1 (+0/-0). Dernière modification le 16 juillet 2025 à 00:21.
Bonjour Vincent,
Merci pour ces questions pertinentes. Je précise :
Aeryth ne se substitue pas aux gestionnaires de mises à jour intégrés : l’utilisateur final doit recréer et réinstaller manuellement le paquet à partir de la nouvelle AppImage. (Ceci dit, rien n'interdit à quiconque de créer un système de dépôt appelant le script)
L’intérêt est de bénéficier d’un paquet reconnu par le gestionnaire de son système pour l’installation, la désinstallation et l’intégration avec le bureau, pas de remplacer APT ou pacman.
Le script respecte le FHS en installant dans /opt/… et en créant un lanceur standard, mais n’a pas vocation à égaler les paquets de distribution en termes de gestion fine des dépendances ou de vérification formelle des bibliothèques. C’est un compromis : simplicité et intégration légère pour l’utilisateur plutôt qu’un empaquetage complet professionnel.
Il est par ailleurs impossible de limiter l’empreinte mémoire d’une AppImage sans recompilation, celle-ci dépendant directement des bibliothèques embarquées et du mode d’exécution, c'est là le rôle des dépôts de distribution officiels. (Mais qui n'ont pas tout et ne sont pas toujours à jour, contrairement aux AppImage de plus en plus proposées par divers projets comme source "universelle")
Enfin, Aeryth peut également faciliter la vie de ceux qui souhaitent proposer une AppImage sous forme de paquet Debian ou Arch Linux, et peut aussi être utilisé avec l’AUR pour simplifier l’empaquetage et la maintenance d’AppImages via makepkg.
Votre retour souligne bien les limites actuelles. L’objectif n’est pas de concurrencer les paquets officiels, mais de proposer aux utilisateurs non experts une approche plus ordinaire qu’un simple clic sur une AppImage, avec une expérience similaire à l'usage à un paquet installé depuis un dépôt, sans devoir se soucier de la compatibilité avec la distribution utilisée.
Je précise que j'ai développé ce script pour mes propres besoins au sein de mon environnement de travail dans ma pépinière, car rien d'équivalent n'existait et que je voulais quelque chose qui fonctionne et puis c'est tout. Je l'ai ensuite publié sous GPL3. Ce n'est pas un projet que j'ai développé pour répondre aux attentes des uns et des autres.
Je n'ai d'ailleurs pas suivi la grande mode du python parce que cet environnement ne cesse d'évoluer et casser la compatibilité avec les anciennes versions et réclament constamment un suivi. Le bash, c'est généralement stable et fonctionnel sans se soucier de ça.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.