Aeryth : Intégrer une AppImage dans un paquet et le bureau

Posté par  (site web personnel) . Édité par Benoît Sibaud et Arkem. Modéré par Julien Jorge. Licence CC By‑SA.
Étiquettes :
13
15
juil.
2025
Linux

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 deux soucis :

  1. Intégration bureau (menus, icônes) absente au sein de l'environnement.
  2. 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.sh

Feuille de route

  • Détection automatique des nouvelles versions AppImage.
  • CI : tests sur Debian 12, Ubuntu 24.04, Arch stable.

Ressources

Aller plus loin

  • # Commentaire supprimé

    Posté par  . É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  . Évalué à 2 (+2/-1). 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  (site web personnel) . Évalué à 6 (+5/-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.

    • [^] # Re: Zones d'ombre

      Posté par  . Évalué à 7 (+6/-0).

      Pas mal des problèmes mentionnés viennent du format AppImage lui-même, pas d’Aeryth.

      L’intérêt ici, c’est de générer un .deb propre à intégrer dans un dépôt maison. Du coup, déploiement et mise à jour centralisée sur un parc, sans sortir du gestionnaire de paquets.

      OK, ce n’est pas du packaging « propre » façon Debian, mais ça permet d’avoir des applis récentes, sans casser la distro, ni jouer avec les backports.

      • [^] # Re: Zones d'ombre

        Posté par  (site web personnel) . Évalué à 5 (+4/-0).

        C'est exactement ça 🙂
        En entreprise on veut simplement quelque chose de simple et fonctionnel, stable.

      • [^] # Re: Zones d'ombre

        Posté par  . Évalué à 3 (+1/-0).

        L’intérêt ici, c’est de générer un .deb propre à intégrer dans un dépôt maison. Du coup, déploiement et mise à jour centralisée sur un parc, sans sortir du gestionnaire de paquets.

        Dans ce cas quel intérêt d'utiliser l'appimage ? Il me semble aussi simple et plus fiable de partir du code source et de générer un paquet avec checkinstall.

        • [^] # Re: Zones d'ombre

          Posté par  . Évalué à 3 (+2/-1).

          Je pense que l'intérêt, c'est quand la personne qui utilise aeryth n'est pas la même que celles qui a produit l'appimage.
          Le développeur produit uniquement un appimage, parce qu'il ne veut pas s'occuper des détails d'empaquetage des différentes distributions, un utilisateur sous debian (ou dérivé) convertit cet appimage en deb pour qu'il apparaisse dans sa liste de paquets installé.

  • # Alien ?

    Posté par  (site web personnel) . Évalué à 9 (+6/-0).

    C'est un logiciel différent ok, mais en quoi ça ne pourrait pas être une extension du logiciel alien qui fait déjà des conversions deb/rpm/tgz ?

    Cf https://wiki.debian.org/Alien

  • # Test non concluant

    Posté par  . Évalué à 4 (+2/-0).

    J’ai voulu tester ce script que je trouve potentiellement très utile, mais sur ma Debian 12.11, quand je l’exécute il n’affiche rien et retourne un code d’erreur (127). Si je l’exécute en précisant l’option --target=deb il finit sans erreur en n’affichant que « Abandonné ».

    J’ai donc moi aussi abandonné l’idée de l’utiliser. Ce n’est pas tant le fait que le script ne fonctionne pas qui me frustre, mais le fait qu’il semble cacher les erreurs du shell et afficher ses propres messages d’erreur trop succincts, ce qui limite toute tentative de débogage.

    Du coup, je ne peux pas faire de retour d’expérience ni de rapport de bug utile. Je me contenterais donc de dire que je trouve l’idée de ce script vraiment utile et que je suis sûr que s’il avait tourné chez moi, je le trouverais super !

  • # securité ?

    Posté par  . Évalué à 1 (+1/-0). Dernière modification le 17 août 2025 à 11:08.

    Bonjour,

    C'est une bonne idée, mais au niveau sécurité, y a t'il des vérifications dans cette transformation?
    Récemment des alertes sécurité m'ont un peu refroidi sur l'utilisation des AppImage.
    voir alerte Arch Linux

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.