Au revoir Debian, bonjour Debian avec Flatpak

Rédigé par antistress le 10 juin 2019 (mis à jour le 15 juin 2019) - 14 commentaires

Des rangées de cartons de produits plats d'un magasin Ikea

J'avais évoqué, à l'occasion de la sortie de Debian 9 Stretch, la combinaison Debian Stable + Flatpak, que je déclarais gagnante sur le papier… Il est temps de passer à la pratique !

Comment j'en suis arrivé à vouloir flatpak-iser ma Debian ?

Déjà, il faut savoir que je suis le genre de gars qui, quand son installation marche bien, va décider de la modifier. C'est certainement compulsif : par exemple, si ma TV marche sans soucis, je vais quand même aller voir sur le site du fabricant s'il n'y a pas une mise à jour du firmware à faire. Bref.

Il y a quelques années, je testais la session Wayland de GNOME pour voir si c'était utilisable, vu que c'était le futur (spoiler : je n'ai toujours pas fait la bascule, j'attends pour le moment de tester GNOME 3.32 pour voir si les soucis de performances font partie du passé). Je me suis rendu compte que j'allais devoir changer mes habitudes car mon logiciel graphique de gestion des paquets habituel, Synaptic, ne pouvait exister en environnement Wayland. J'ai donc commencé à faire mes mises à jour en ligne de commande. Cela tombait bien car APT, le gestionnaire officiel de paquets en ligne de commandes de Debian, venait de sortir une nouvelle version agréablement simplifiée.

Une fois accoutumé à la ligne de commande pour la gestion des paquets deb, celle des paquets Flatpak n'a rien de sorcier.

J'ai eu l'occasion de m'y frotter pour la première fois lors de mes tests de la version de développement de Pitivi (logiciel de montage vidéo pour GNOME) pour lesquels la méthode Flatpak est recommandée (notamment parce qu'elle permet aux développeurs d'utiliser exactement la même version que l'utilisateur, ce qui facilite le débogage).

Pour ce qui est de comprendre les bases du fonctionnement de Flatpak en ligne de commande, je vous renvoie aux premières pages de ce manuel, et aux nombreux tutos disponibles sur la Toile.

Par ailleurs, depuis mes premiers tests sous Wayland, la logithèque de GNOME a pas mal progressé et offre dorénavant, si vous préférez, l'installation graphique aussi bien de paquets deb que de paquets Flatpak (sous Debian, installer pour cela le paquet gnome-software-plugin-flatpak).

Il existe un dépôt central, Flathub, qui héberge un grand nombre d'applications. C'est là-bas, à la page du logiciel concerné, que je récupère l'identifiant Flatpak des logiciels qui m’intéressent. Au sujet de Flathub, j'ai découvert que certains paquets Flatpak sont préparés par les développeurs de l'application (directement du producteur au consommateur, pourrait-on écrire), comme LibreOffice, GIMP, ou encore Pitivi (pour Firefox, cela avance lentement mais sûrement), tandis que d'autres, comme Transmission, sont générés par l'équipe derrière Flathub indépendamment de ses développeurs. Dans tous les cas, vous remarquerez qu'il ne s'agit pas des développeurs de votre distribution (d'où le titre de ce billet).

Enfin, puisque Flatpak est le futur de la distribution des logiciels, et que je l'utilise déjà pour Pitivi, je me suis dit : pourquoi ne pas installer toutes les applications extérieures au projet GNOME via Flatpak ?

Compte-rendu de mon expérience de flatpak-isation de ma Debian Unstable

Alors déjà je suis sous Debian Unstable (et non pas Stable). Mais même sous Unstable, il est possible d'avoir des versions plus récentes de logiciels en puisant dans Flathub. Sans parler des gains de sécurité – dont certains seront amenés au fur et à mesure des développements de Flatpak – comme un bac à sable, la gestion des permissions d'accès à vos périphériques type webcam, microphone, à la géolocalisation…

Ensuite, je n'ai effectué les substitutions qu'il y a une semaine : le temps de tester un minimum et de remplir quelques rapports de bogues.

Sans plus attendre, voici les paquets deb que j'ai choisi de remplacer par leur équivalent Flatpak, et les éventuels problèmes auxquels j'ai été confronté (en gras, les plus gênants – en fait un seul qui empêche l'usage du logiciel) :

  • Transmission : Je l'ai installé via la Logithèque de GNOME : tout semble fonctionner si ce n'est que l'interface était restée en anglais. J'ai donc dû installer les traductions du logiciel en ligne de commande (ajouter « .Locale » à la fin de l'identifiant du logiciel pour installer ses traductions) (rapports de bogue ici, ici et ).
  • Shotwell : Tout semble ok, si ce n'est que seuls mes dossiers Musique et Téléchargements (parmi tous mes xdg-user-dirs) apparaît (rapport de bogue).
  • Audacity : Comme pour Transmission, pour avoir une version francisée, j'ai dû passer par la ligne de commande (rapports de bogue ici et ). Plus embêtant : l'icône du pointeur est manquant, remplacé par un carré noir qui empêche une sélection précise sur la piste (rapport de bogue). Comme quoi un bogue assez mineur peut rendre un logiciel à peu près inutilisable.
  • Avidemux : Tout semble ok (je me retrouve avec un choix de codecs un peu plus réduit via Flathub que via le dépôt deb-multimedia.org mais bon : osef). À noter aussi que le runtime de KDE (KDE Application Platform) est installé dans le cas de la version Flatpak, alors que j'avais juste des dépendances à Qt via le dépôt deb-multimedia.org : c'est inévitable pour limiter les efforts de maintenance à trois runtimes : freedesktop, GNOME et KDE. Par ailleurs il n'apparaît pas dans la liste « Ouvrir avec une autre application » du menu contextuel de Nautilus (rapport de bogue).
  • Pitivi : Là c'est nickel, d'autant que vous pouvez choisir votre version : dernière stable, ou celle en développement.
  • Calibre : Tout semble ok (mais je ne l'utilise pas, c'est au cas où).
  • GIMP : Pour le moment c'est la dernière version stable qui est proposée en Flatpak, mais il est prévu que la future version (tirant partie de GTK3) puisse être testée ainsi. Pas de problème particulier semble t-il pour GIMP, à moins que vous n'utilisiez des greffons. Pour ma part, j'avais l'habitude d'installer le paquet deb gimp-plugin-registry (qui fournit notamment le greffon "Save for Web" que j'affectionne) en même temps que la version deb de ce bon vieux GIMP, mais gimp-plugin-registry n'est pas proposé sur Flathub. J'ai donc dû retourner un peu le web et j'ai appris (mieux vaut tard que jamais !) que GIMP propose un système manuel d'installation des greffons ! D'ailleurs, je me souviens maintenant que Jehan a, de longue date, un plan pour améliorer la gestion des extensions dans GIMP. En attendant le résultat de ce travail, j'ai dû compiler le greffon "Save for Web" en suivant les instructions présentes dans l'archive officielle. L'exécutable webexport est alors copié dans /home/mon_user/.config/GIMP/2.10/plug-ins/ (à noter que normalement il faudrait le déplacer manuellement dans /home/mon_user/.var/app/org.gimp.GIMP/config/GIMP/2.10/plug-ins/ pour coller à l'organisation spécifique de Flatpak, mais il y a une difficulté à régler – rapport de bogue). À noter également que je n'ai pas réussi à franciser le greffon.
  • FileZilla : Comme pour Transmission et Audacity, pour avoir une version francisée, j'ai dû passer par la ligne de commande (rapports de bogue ici et ).
  • LibreOffice : Tout semble ok. Petit détail : le menu Outils->Options est très long à se lancer (plus de 5 secondes à attendre) (rapport de bogue).
  • Frozen Bubble : Tout semble ok.
  • VLC : Tout semble ok.
  • Rhythmbox : Tout semble ok, si ce n'est que seul mon dossier Musique (parmi tous mes xdg-user-dirs) apparaît (rapports de bogue ici et ).

Par ailleurs, certains logiciels que j'utilise ne sont pas (encore ?) sur Flathub : Deja Dup, Brasero, DevedeNG, Imagination, Liferea, MComix, Firefox (c'est prévu), Thunderbird (c'est prévu, après Firefox).

En ce qui me concerne, je ne vois que des avantages à utiliser les versions Flatpak de mes logiciels usuels. Et pour celles qui ne fonctionnent pas correctement, et bien, il suffit de rester sur la version fournie par votre distribution en attendant que le problème soit réglé !

14 commentaires

#1  - Ose Effe a dit :

S'il y avait MS Office en flatpak, ou la suite adobe, tu l'installerais ?

Répondre
#2  - aeris a dit :

Bienvenue dans un monde sans sécurité du coup ^_^

Répondre
#3  - antistress a dit :

Salut aeris,
Ce propos mériterait d'être développé ;)

Répondre
#4  - x a dit :

http://flatkill.org/

Répondre
#5  - antistress a dit :

Sérieusement ?

Répondre
#6  - Le fromagé a dit :

Faire ça c'est comme enlever la croûte des fromages avant de le manger, c'est jeter tout le travail de l'affineur à la poubelle.

Répondre
#7  - skc a dit :

Un des soucis que je vois avec flatpak, c'est les interactions entre logiciels.

Par exemple avec Ubuntu 18, lorsque je clique sur un document dans LibreOffice, et que je fais "Editer dans Gimp"; gimp se lance et me dit qu'il ne trouve pas le fichier (il est dans un sous-répertoire de /tmp).

On pourrait probablement définir qu'un répertoire doit être partagé, comme le $HOME de l'utilisateur, mais dans ce cas, quel est l'intérêt de la protection ?

Répondre
#8  - jonjon a dit :

Pour moi flatpak est à éviter, pareil pour Snap. Si je devais choisir je prendrais Appimage.

Flatpak vient avec son lot de problèmes notamment de sécurité qui le disqualifie d'office.
Au delà de ses limitations, Snap est voué à disparaitre à plus ou moins court terme comme la plupart des projets par canonical pour canonical.

Appimage a l'avantage d'être supporté par défaut sur la plupart des distributions existantes, y compris en live usb ou live iso, est basé sur le modèle communautaire et n'est pas dépendant du modèle économique d'une compagnie (red hat pour flatpak et canonical pour snap).

Pour une comparaison entre les 3 je recommande la lecture de cette page: https://github.com/AppImage/AppImageKit/wiki/Similar-projects#comparison

Répondre
#9  - XataZ a dit :

Je suis d'accord avec toi, je préfère largement Appimage, car "natif", c'est juste un exécutable qui intègre tout, contrairement à snap et flatpak qui nécessite un daemon ou des outils en plus. Appimage est très pratique pour créer un clé USB avec des applis portable dessus, un peu à la windows pour avoir ces outils de dépannage.

Après, pour moi ça reste des outils à éviter, notamment avec le fait que ça reste une boite noir, on ne sais pas trop ce qu'il y a dedans, et si ce n'est pas régulièrement maintenu. De plus c'est assez complexe à maintenir, gérer ces propres "Images" est plus compliqué que du docker avec les dockerfiles (utilisations différentes certes).

Répondre
#10  - antistress a dit :

klik (devenu Appimage) est évoqué par le créateur de Flatpak comme source d'inspiration initiale :
https://blogs.gnome.org/alexl/2018/06/20/flatpak-a-history/

De ce que je comprends, en termes de sécurité (comment gérer les mises à jour des bibliothèques embarquées avec chaque logiciel ?) et d'espace occupé (les mêmes bibliothèques dans chaque paquet), ça me paraît nettement moins abouti que Flatpak

Répondre
#11  - XataZ a dit :

Oui c'est moins abouti niveau gestion d'espace, c'est sur, mais comme dit, appimage c'est juste un binaire qui contient tout, point, pour être portable. C'est a dire tu exécutes ton binaire sur toutes machines, en ayant rien besoin de plus.
Flatpak nécessite un binaire pour être exécuté, snap un daemon, mais donc la transportabilité n'est plus aussi évidente, car il faut que flatpak ou snap sois packager sur le système hôte.

Ensuite, niveau mise à jour ce n'est pas dit que ce sois plus simple, car ce n'est pas parce qu'une base est mis à jour, que l'image firefox par exemple va l'utiliser.
Prenons l'exemple de pitivi, qui à été builder pour la dernière fois le 20 Aout 2018, il est basé sur le runtime org.gnome.Platform (géré par gnome), qui lui est basé sur le runtime org.freedesktop.Platform (géré par flatpak il me semble). Dans ces deux runtimes, il y a forcément des composants qui ont été patcher (bug ou faille) ou mis à jour depuis (du moins je l'espère), ba ton appli pitivi ne les intègres pas, puisqu'il n'a pas été mis à jour depuis.
Le seul moyen de vraiment être sécure, ce serais de gérer toute la chaine toi même, mais flatpak ou snap, c'est plutôt complexe, ou que ce sois vraiment la même personne qui la gère.

Pour l'instant, c'est pas trop démocratiser, mais on pourrait par exemple voir dans le futur, des images basé sur d'autre, qui serons basé sur d'autre et ainsi de suite, et là on complexifiera encore plus la chaine de construction. Et on finira comme docker, avec des images non à jour dans tout les sens, bourré de faille etc ...

appImage, même si beaucoup plus complexe à mettre en oeuvre, n'a pas se problème, car tu construis tout directement. Par contre effectivement, ça monte très vite en espace disque.

Répondre
#12  - antistress a dit :

@ XataZ : Je ne te suis pas sur deux points : les runtimes flatpak sont mis à jour régulièrement* ! Et je ne vois pas en quoi nécessiter la présence d'un exécutable pour exécuter les flatpak est un problème en pratique, cela me paraît d'avantage une position de principe ;)

*https://blogs.gnome.org/alexl/2018/08/10/the-birth-of-a-new-runtime/

Répondre
#13  - lolop a dit :

As-tu regardé l'espace disque occupé par ces différentes installations?

J'avais fait un essai avec snap… c'était (pour moi) catastrophique.

Répondre
#14  - antistress a dit :

/var/lib/flatpak c'est 4,5 Go chez moi

Répondre

Fil RSS des commentaires de cet article

Écrire un commentaire

NB : en publiant votre commentaire, vous acceptez qu'il soit placé sous la licence CC BY-SA comme indiqué aux conditions d'utilisation du site

Quelle est la première lettre du mot dlnzc ?