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 tikilou (site web personnel) . En réponse à la dépêche Aeryth : Intégrer une AppImage dans un paquet et le bureau. Évalué à 6. 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.