Tu cites déjà la réponse dans ton journal. Je pense que Flatpak, si le projet continue dans la bonne direction (ça a l'air d'être le cas pour l'instant), peut être la solution au problème cité.
Note que je ne considère absolument pas que le système de paquet par distribution est cassé pour autant, ni qu'il disparaîtra. C'est simplement complémentaire. L'écosystème logiciel GNU est simplement devenu trop important pour que tous les logiciels intéressants soient inclus dans les paquets gérés par la distrib (on peut voir cela comme un succès du "bureau Linux" si on veut alimenter le troll! :P). Donc il faut trouver des solutions pour répartir mieux le travail, et ça veut en général dire que les développeurs doivent s'y mettre. Par contre — on le sait bien depuis le temps — faire un paquet par distribution n'est pas gérable, surtout si ce sont des logiciels faits sur le temps libre (cas non rare dans le logiciel libre!). Un format standard comme flatpak, utilisable sur toute distribution GNU/Linux, est donc une très bonne alternative.
Mais là, qui va s'assurer que tout vos containers utilisent bien la dernière version patchée d'une bibliothèque critique ?
Alors je sais pas comment ça marche pour Docker que tu cites aussi, mais j'imagine bien qu'y a pas de mise-à-jour automatique (surtout parce que c'est fait pour les serveurs et on veut pas voir des trucs genre maj auto en prod!). Par contre Flatpak a un système de dépôt. En gros, chaque projet aura désormais un mini-dépôt de paquets pour ses logiciels et mettra à jour ses dépendances (note: il est aussi possible de faire des Flatpak standalone, sans dépôt, mais ce n'est pas la procédure conseillée).
Ainsi quand le projet mettra à jour son paquet, l'ensemble des gens qui auront installé ce paquet recevront des notifications qu'une mise-à-jour est dispo. Personne ne se baladera avec des applis et dépendances trouées (tant que le projet upstream est maintenu). Note que le projet n'a même pas à maintenir l'ensemble des dépendances possibles d'un logiciel puisque Flatpak fonctionne par "niveaux" de runtime. Ainsi le projet Flatpak lui-même maintient un runtime "Freedesktop" qui à lui seul contient déjà environ 200 dépendances de base qui vont suffire pour énormément de projets. Le projet GNOME aussi maintient un runtime, basé sur celui Freedesktop et qui ajoute environ 50 dépendances. Le projet KDE aussi maintient un runtime. Un logiciel doit simplement choisir un runtime sur lequel se baser.
Pour énormément de projet, celui signifie qu'il n'y aura peut-être aucune dépendance supplémentaire à ajouter dans le Flatpak (et donc à maintenir), ou très peu. Cela dilue énormément la tâche tout en permettant de rester sécurisé.
Ainsi pour les distributions, ça ne change pas grand chose: elles peuvent continuer à proposer les logiciels les plus notables notamment, et avoir des mises-à-jour fonctionnelles pas forcément au taquet (mais une fois tous les 6 mois ou 1 an en fonction du cycle de sortie de la distrib). Ça sera suffisant pour la majorité des logiciels.
Les développeurs eux auront moins de travail puisqu'il n'y aura plus qu'un seul paquet à maintenir pour être dispo partout.
Enfin tout le monde aura accès à des mises-à-jour immédiates fonctionnelles ET de sécurité si on choisit d'installer le paquet Flatpak upstream.
En tous cas, le projet GIMP par exemple fournira désormais un paquet Flatpak upstream que je crée et maintiens. Je pense que c'est vraiment une avancée car jusqu'à ce jour, les gens sous Windows ont un installeur, ceux sous OSX un DMG, et sous Linux... on leur disait d'attendre le paquet de leur distrib ou de compiler. Ça fait limite "citoyens de seconde zone" (bon c'est pas vrai, hein. Quasi tous les dévs de GIMP sont sous Linux, et donc ça veut dire notamment que la version nux est bien plus stable que les autres! Mais bon on pourrait croire). Ben plus maintenant. Tant que je serai dév de GIMP, les linuxiens auront leur Flatpak (bon à part si une alternative encore mieux fait son apparition bien sûr, ou si je découvre un truc horrible qui me fait changer d'avis sur l'utilité... espérons que non, mais on sait jamais!) et seront toujours des citoyens de première zone! :-D
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Flatpak pour les paquets de logiciels de bureau
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal La multiplicité des gestionnaires de paquets. Évalué à 10.
Tu cites déjà la réponse dans ton journal. Je pense que Flatpak, si le projet continue dans la bonne direction (ça a l'air d'être le cas pour l'instant), peut être la solution au problème cité.
Note que je ne considère absolument pas que le système de paquet par distribution est cassé pour autant, ni qu'il disparaîtra. C'est simplement complémentaire. L'écosystème logiciel GNU est simplement devenu trop important pour que tous les logiciels intéressants soient inclus dans les paquets gérés par la distrib (on peut voir cela comme un succès du "bureau Linux" si on veut alimenter le troll! :P). Donc il faut trouver des solutions pour répartir mieux le travail, et ça veut en général dire que les développeurs doivent s'y mettre. Par contre — on le sait bien depuis le temps — faire un paquet par distribution n'est pas gérable, surtout si ce sont des logiciels faits sur le temps libre (cas non rare dans le logiciel libre!). Un format standard comme flatpak, utilisable sur toute distribution GNU/Linux, est donc une très bonne alternative.
Alors je sais pas comment ça marche pour Docker que tu cites aussi, mais j'imagine bien qu'y a pas de mise-à-jour automatique (surtout parce que c'est fait pour les serveurs et on veut pas voir des trucs genre maj auto en prod!). Par contre Flatpak a un système de dépôt. En gros, chaque projet aura désormais un mini-dépôt de paquets pour ses logiciels et mettra à jour ses dépendances (note: il est aussi possible de faire des Flatpak standalone, sans dépôt, mais ce n'est pas la procédure conseillée).
Ainsi quand le projet mettra à jour son paquet, l'ensemble des gens qui auront installé ce paquet recevront des notifications qu'une mise-à-jour est dispo. Personne ne se baladera avec des applis et dépendances trouées (tant que le projet upstream est maintenu). Note que le projet n'a même pas à maintenir l'ensemble des dépendances possibles d'un logiciel puisque Flatpak fonctionne par "niveaux" de runtime. Ainsi le projet Flatpak lui-même maintient un runtime "Freedesktop" qui à lui seul contient déjà environ 200 dépendances de base qui vont suffire pour énormément de projets. Le projet GNOME aussi maintient un runtime, basé sur celui Freedesktop et qui ajoute environ 50 dépendances. Le projet KDE aussi maintient un runtime. Un logiciel doit simplement choisir un runtime sur lequel se baser.
Pour énormément de projet, celui signifie qu'il n'y aura peut-être aucune dépendance supplémentaire à ajouter dans le Flatpak (et donc à maintenir), ou très peu. Cela dilue énormément la tâche tout en permettant de rester sécurisé.
En tous cas, le projet GIMP par exemple fournira désormais un paquet Flatpak upstream que je crée et maintiens. Je pense que c'est vraiment une avancée car jusqu'à ce jour, les gens sous Windows ont un installeur, ceux sous OSX un DMG, et sous Linux... on leur disait d'attendre le paquet de leur distrib ou de compiler. Ça fait limite "citoyens de seconde zone" (bon c'est pas vrai, hein. Quasi tous les dévs de GIMP sont sous Linux, et donc ça veut dire notamment que la version nux est bien plus stable que les autres! Mais bon on pourrait croire). Ben plus maintenant. Tant que je serai dév de GIMP, les linuxiens auront leur Flatpak (bon à part si une alternative encore mieux fait son apparition bien sûr, ou si je découvre un truc horrible qui me fait changer d'avis sur l'utilité... espérons que non, mais on sait jamais!) et seront toujours des citoyens de première zone! :-D
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]