Six distributions, six facons pour un programme d'echouer

Distribuer une application de bureau sous Linux se heurte chaque fois au meme mur : les dependances. Le meme programme, compile une fois, peut refuser de s'installer sur une autre distribution parce que les versions de bibliotheques qu'il attend ne sont pas la, ou parce que les chemins sont ranges autrement. Le message est rarement interessant : un numero et un nom introuvable, et c'est a l'utilisateur de decider lequel des deux systemes est en tort.

La reponse habituelle est un paquet distinct par distribution. Cela multiplie le travail par le nombre de cibles et laisse quand meme les combinaisons bizarres de cote. Flatpak prend un autre chemin.

Emballer l'environnement avec l'application

Son approche consiste a empaqueter l'application avec l'environnement d'execution dont elle a besoin, et a garder cet environnement independant du systeme en dessous. L'application n'emprunte plus les bibliotheques de la distribution, elle apporte les siennes. Le meme paquet s'installe donc de la meme facon et demarre de la meme facon sur des systemes qui ont par ailleurs peu en commun.

Cette independance est toute l'idee, et il vaut la peine de dire precisement ce qu'elle achete. Elle ne rend pas une application transportable dans l'abstrait ; elle fait de l'environnement une quantite fixe, de sorte qu'une seule chose doit etre juste au lieu d'une chaine entiere de paquets systeme. Le prix se trouve de l'autre cote : l'environnement est livre et mis a jour comme un objet a part, donc plus d'espace et plus de mises a jour qu'un paquet natif n'en demanderait.

Un bac a sable entre l'application et le systeme

Entre l'application et le systeme se tient un bac a sable. Par defaut l'application ne voit pas tout le systeme de fichiers et ne detient pas d'acces direct aux peripheriques. S'il lui faut lire ou ecrire un dossier precis, ou utiliser un peripherique precis, cela doit figurer explicitement dans ses droits.

Le modele rend plus claire la frontiere du comportement d'une application, et il permet de voir avant l'installation, grossierement, quelles ressources un programme va toucher. Le gain est modeste en pratique et reel sur le principe : la question de la portee d'un programme cesse d'etre tranchee par la seule confiance.

Des droits plus fins sur les peripheriques en 1.18

La version 1.18 a ajoute des conditions plus fines pour les droits sur les peripheriques. Une application peut demander la seule classe de peripherique dont elle a besoin au lieu d'ouvrir la porte a toutes. Le changement parait petit et ne l'est pas : un acces global aux peripheriques est l'une des raisons pour lesquelles un bac a sable est vite tenu pour decoratif, et le fait de le resserrer transforme la declaration en argument plutot qu'en ligne d'ecran.

Il y a la une lecon generale. Un systeme de droits est pris au serieux quand chaque demande est assez precise pour etre jugee ; la ou tout est demande d'un coup, l'utilisateur apprend a cliquer sans lire.

D'ou viennent les applications

La source la plus courante est Flathub, un depot central qui rassemble un grand nombre d'applications. En ligne de commande une seule instruction d'installation suffit, et les centres de logiciels graphiques l'incluent generalement, si bien que le meme catalogue est joignable des deux cotes.

Hors du depot officiel, des depots tiers peuvent etre ajoutes. Cela merite un avertissement plutot qu'un mode d'emploi : un depot tiers ne passe pas par le meme examen, son origine doit donc etre etablie avant de l'ajouter. La version 1.18 permet aussi d'installer directement depuis des images OCI, et elle ameliore les messages affiches quand une mise a jour echoue. Ce second changement ne compte qu'une fois que quelque chose a deja mal tourne, et c'est precisement la qu'il compte le plus.

Les autres voies, et ce qui les separe

Plusieurs projets travaillent sur la meme classe de probleme avec des poids differents. Une famille place l'application dans un magasin central adosse a un examen et couvre beaucoup de distributions. Une autre est liee de pres a une seule distribution, dont elle emprunte le compte et la mecanique de mise a jour. Une troisieme est la plus simple : un fichier qui tourne tel quel, mais sans mise a jour centrale ni catalogue commun.

Aucune ne remplace le gestionnaire de paquets du systeme, et lire cette comparaison comme une competition est une erreur. Ce qui differe, c'est l'endroit ou va l'effort : couverture et examen, integration a une plateforme, ou empaquetage minimal avec l'entretien laisse a l'utilisateur.

Un arrangement raisonnable

Pour la plupart des utilisateurs de bureau, la combinaison stable est de traiter cela comme un canal d'appoint et de laisser les outils de niveau systeme aux paquets natifs de la distribution. Les applications que la distribution ne fournit pas, ou fournit trop lentement, viennent du paquet ; ce qui touche le systeme lui-meme reste la ou le systeme l'attend.

Trois gestes couvrent le quotidien : installer, mettre a jour, et regarder ce qui a ete accorde a une application. Le troisieme est celui qu'on saute, et c'est lui qui donne son prix au bac a sable.

La valeur de Flatpak est de detacher la question des machines sur lesquelles une application tourne des differences entre distributions, puis de rendre l'installation inspectable par le bac a sable et les droits. Il ne remplace pas le gestionnaire de paquets, il comble la partie qui manquait.