Que flatpak soit plus simple à générer, c'est possible, ceci étant, je parlais plus haut du fait que pour l'utilisateur final les AppImages sont pratiques, cela fonctionne comme une appli native, et même si le binaire est un peu plus gros qu'un .deb c'est quand même moins pire qu'un flatpak : l'exemple donné sur https://ludocode.com/blog/flatpak-is-not-the-future est édifiant : pour un programme de calculatrice, un appImage fait 150 Mo tandis que le même fera 900 Mo avec flatpak. D'un autre côté MuseScore en AppImage fait aussi 160 Mo donc ça reste acceptable.
Il est vrai.
Mais le appImage n'embarque pas tout. Il a besoin d'un ensemble de libs déjà présentent dans ton système (sinon on aurait pas les problèmes de compat que j'ai cité).
Quelle est la taille de ces libs ?
Tu me répondras qu'on s'en fout parce que c'est déjà là et que c'est partagé avec les autres programmes. Mais c'est exactement la réponse qui est donnée dans cet article: Le flatpak est gros parce qu'il vient avec un sdk, mais ce sdk sera partagé par d'autres appli aussi.
Et c'est un vrai problème quand tu packages un logiciel. Il faut décider d'une limite à partir de laquelle tu assumes que c'est un "standard" de ton système (et si il est versionné ou non).
Si la limite est trop basse, tu assumes trop et ton logiciel ne fonctionne que sur un petit nombre de distrib
Si la limite est trop haute, tu embarques beaucoup de choses qui vont être des duplications de ce qu'il y a dans le système (ou entre plusieurs packages).
AppImage te laisse choisir (pour le pire et le meilleur).
Flatpak prend un chemin intermédiaire:
- Prendre une limite haute et avoir des sdk qui "refont" un système.
- Avoir des applis qui se base sur ces sdk (et donc avoir une limite "basse" du point de vue appli)
- Parier sur la déduplication des données pour ne pas exploser en taille avec la multiplication des sdk.
Sur ce dernier point, je trouve aussi que c'est un peu limite. Flatpak prend effectivement beaucoup de place. Mais il reste quand même que ça "juste marche" contrairement aux autres solutions plus légères.
[^] # Re: Flatseal
Posté par GaMa (site web personnel) . En réponse au journal "dérives sécuritaires" : inconvénients des flatpacks, snap ou environnements sandbox.. Évalué à 4.
Il est vrai.
Mais le appImage n'embarque pas tout. Il a besoin d'un ensemble de libs déjà présentent dans ton système (sinon on aurait pas les problèmes de compat que j'ai cité).
Quelle est la taille de ces libs ?
Tu me répondras qu'on s'en fout parce que c'est déjà là et que c'est partagé avec les autres programmes. Mais c'est exactement la réponse qui est donnée dans cet article: Le flatpak est gros parce qu'il vient avec un sdk, mais ce sdk sera partagé par d'autres appli aussi.
Et c'est un vrai problème quand tu packages un logiciel. Il faut décider d'une limite à partir de laquelle tu assumes que c'est un "standard" de ton système (et si il est versionné ou non).
Si la limite est trop basse, tu assumes trop et ton logiciel ne fonctionne que sur un petit nombre de distrib
Si la limite est trop haute, tu embarques beaucoup de choses qui vont être des duplications de ce qu'il y a dans le système (ou entre plusieurs packages).
AppImage te laisse choisir (pour le pire et le meilleur).
Flatpak prend un chemin intermédiaire:
- Prendre une limite haute et avoir des sdk qui "refont" un système.
- Avoir des applis qui se base sur ces sdk (et donc avoir une limite "basse" du point de vue appli)
- Parier sur la déduplication des données pour ne pas exploser en taille avec la multiplication des sdk.
Sur ce dernier point, je trouve aussi que c'est un peu limite. Flatpak prend effectivement beaucoup de place. Mais il reste quand même que ça "juste marche" contrairement aux autres solutions plus légères.
Matthieu Gautier|irc:starmad