Skelets numériques

Accueil du blog Posts Fiches de lecture Recettes Phrases Compte mastodon Compte bookwyrm À propos

Les frictions avec la gestion de paquet usuelle

Cela fait plusieurs mois (à date du 17-11-2024) que mon ordinateur perso est sous NixOS. NixOS est une distribution Linux basée sur le gestionnaire de paquet Nix. La définition en une ligne extraite du site officiel : « declarative build and deployments ». On est pas beaucoup plus avancés, ceci dit.

Initialement, ce billet comptait n’être qu’un retour d’expérience sur mon usage accompagné de quelques exemples. Mais comme il se fait tard à la rédaction de ce billet et, qu’apparemment, j’ai envie de dire beaucoup de choses, je vais séparer ce post en plusieurs plus petits. Dans un premier (celui-ci), on parlera des limites que je perçois dans les distributions Linux existantes. Avant de parler d’un outil, intéressons nous aux problèmes qu’il tente de résoudre. Dans le deuxième, j’aborderai comment NixOS résout ces problèmes, et les petites fioritures agréables qu’il apporte (ce que je kiffe, quoi). Dans un troisième, je parlerai des défauts que je trouve à NixOS et sa communauté, ses limitations et ses idiosyncrasies. Enfin, parce qu’un logiciel s’inscrit dans un contexte politique donné, je ferai un autre post qui parlera des relations que NixOS sous-entend, de la place politique que je lui trouve, et revenir sur quelques points de l’histoire récente de NixOS.

Distribuer du logiciel ?

Une distribution Linux, c’est un machin un peu bancal constitué de tout un tas différents de logiciels. On peut les séparer en très gros en deux catégories:

1. les programmes “finaux”, dédiés aux utilisateur·ices (Mozilla Firefox, LibreOffice, VLC Media Player, Discord, Steam…)
2. tout ce qui est nécessaire pour les faire marcher (par exemple, l’interface graphique de Firefox est développée séparément des composants qui gèrent la connexion internet)

Sans trop mentir, on peut appeler les second des dépendances des premiers. Un travail nécessaire à la maintenance d’une distribution Linux, c’est de s’assurer que les logiciels et leurs dépendances soient correctement… distribuées. Ce mot peut signifier beaucoup de choses. Ici, on prend ces éléments:

• s’assurer que quand on installe un logiciel, on installe également toutes ses dépendances (pour continuer l’exemple, installer un Firefox sans sa dépendance qui gère le réseau, ça serait dommage pour un navigateur internet)
• symétriquement, quand on désinstalle un logiciel, supprimer les dépendances utilisées par ce logiciel désormais inutiles
• quand une mise à jour de sécurité est corrigée dans une dépendance, fournir des versions des logiciels finaux intégrant ces correctifs
• instrumenter les dépendances communes à plusieurs logiciels (toujours dans l’exemple, le composant réseau de Firefox pourrait être utilisé par Steam)

C’est une tâche proprement monumentale. À titre d’exemple, il y a plus de 140000 logiciels disponibles sur la distribution Ubuntu¹. Un outillage automatique est donc nécessaire - d’autant plus que les personnes qui travaillent à une distribution Linux sont souvent non rémunérés ², il y a un enjeu d’économie de la force de travail évident.

Gestionnaires de paquets

Un tel outil s’appelle un gestionnaire de paquet (c’est aussi un logiciel, avec ses propres dépendances, mais on peut le considérer comme un seul bloc pour la suite).

Pour qui a déjà utilisé un Linux ou un mac, il y a des chances que ce mot ne soit pas inconnu. yum pour macOS, apt pour ubuntu/debian, dnf pour fedora … ces outils ont pour objectif d’installer des programmes et leurs dépendances pour que ça se passe bien sur nos machines (et le serveur qui héberge ce blog, d’ailleurs).

Pour les gens sous Windows qui me lisent, le concept peut sembler un peu éloigné de l’expérience finale. Quand j’utilisais windows, j’avais plutôt tendance à installer un programme en récupérant un installateur quelque part (sur CD, sur le web), double-cliquer sur setup.exe et attendre que le magicien d’installation finisse son oeuvre. Comme ça fait plusieurs années que je n’utilise pas Windows et que je suis complètement ignorant de son fonctionnement interne, je n’en parlerai pas ici.

Les soucis avec les gestionnaires de paquet existant

Mettre à jour c’est un peu casser son système

Une première limitation commune à tous les gestionnaires de paquets que je connais, c’est que les mises à jour sont destructives. Qu’est-ce que ça veut dire? Si on fait une mise à jour, on remplace l’état courant du système sans pouvoir revenir en arrière. Si je mets Firefox à jour d’une version X à la version Y, je n’ai plus accès à la version X - ni aux versions des dépendances correspondantes. Ça peut entraîner des problèmes assez pénibles à gérer. Utilisateur d’Archlinux (btw) pendant six ans et d’Ubuntu pendant huit, il m’est très souvent arrivé de devoir corriger un dysfonctionnement par une mise à jour dans mon système (ou alors, une mise à jour lancée alors que je n’avais plus assez de batterie. Ou plus assez de place pour stocker les fichiers temporaires, ou une nouvelle version du noyau). Ça prend du temps que j’aimerais bien dédier à autre chose, ça demande des compétences assez pointues et, souvent, une clef USB. Il n’y a pas d’équivalent d’un CTRL-Z / Undo avec la gestion de paquets.

Concrètement, ça rend les mises à jour système moins prévisibles. Donc j’ai moins envie de les faire, parce qu’elles peuvent potentiellement ficher en l’air mon système. C’est dommageable quand des mises à jour de sécurité régulières sont nécessaires ³.

Une autre conséquence directe,c’est qu’on ne peut pas retourner facilement à un état précédent du système. Si je foire quelque chose et que mon système est dans un état dysfonctionnel, je ne peux pas restaurer aisément l’état précédent, vu qu’il n’existe plus. Ça limite mon envie d’expérimenter (on me répondra que je pourrais mettre en place une machine virtuelle pour m’amuser, mais ça nécessite d’installer et lancer un logiciel pour “expérimenter”. C’est lourd, et ma curiosité n’aime pas se confronter à la lourdeur).

Une seule version autorisée

La plupart des gestionnaires de paquets n’autorisent qu’une seule bibliothèque du même nom installée en même temps. Les raisons sont tout à fait raisonnables mais j’aurais du mal à les transcrire de manière claire (et puis, il est tard). Citons donc ces deux concepts: dynamic linking et gestion de l’intégrité. En très gros, le premier est une manière de partager les ressources (vous vous souvenez, Steam et Firefox qui utilisent la même dépendance pour le réseau); le second s’assure qu’un logiciel distribué est bien celui qui a été fourni; un nom unique est une manière de s’assurer de ça (adossé à des technologies de chiffrement⁴).

Tout cela est bien fondé. Sauf que ça donne un problème connu par les mainteneur·euses: l’enfer des dépendances (DLL Hell). Supposons qu’une nouvelle version Y de Firefox demande la dernière version de sa dépendance en charge de l’affichage graphique. La mise à jour doit donc supprimer l’ancienne version de cette dépendance pour la remplacer par la nouvelle. On peut imaginer que cette nouvelle version propose des fonctionnalités plus intéressantes - et en retire d’autres. Tous les autres programmes qui dépendent de ces fonctionnalités retirées cassent; avant qu’ils soient mis à jour pour gérer cette nouvelle dépendance. À titre personnel, j’ai souvent eu des applications comme Discord ou Steam qui refusaient de marcher après la mise à jour de certaines dépendances systèmes à priori pas liées.

Il faut préciser que l’activité de packaging est en grande partie effectuée par des humains. la disponibilité d’un paquet dépend d’un travail souvent non rémunéré de volontaires. Donc des oublis dans des spécifications de dépendance existent. Et souvent, spécifier entièrement une dépendance n’est pas possible (pour des considérations techniques d’expressivité : si on spécifie une dépendance, on ne donne aucune info sur comment elle devrait se comporter (« quels programmes tu me donnes ? quels tests tu respectes ?»)).

Un frein à l’assistance mutuelle

Un dernier exemple tiré d’un cas concret que j’ai eu: j’ai un·e camarade qui est récemment passé sous la dernière version d’Ubuntu (24.04). Cette version intègre Wayland ⁵. Pour des raisons techniques qui ne m’intéressent pas, il n’est pas possible d’utiliser la fonctionnalité d’autotype de son gestionnaire de mot de passe (émuler des frappes de clavier dans des champs dédiés) ⁶. À l’heure actuelle, les solutions offertes sont donc de se retrouver à… contourner Wayland en parlant directement au noyau (c’est une vraie suggestion par les développeurs d’un gestionnaire de mot de passe célèbre, et ça me terrifie), ou retourner sous Xorg en créant une nouvelle session. Ces deux approches sont, à leur manière, de nouvelles altérations du système sans possibilité de revenir en arrière. De plus, il est difficile de se souvenir pourquoi elles ont été prises dans quelque mois, à moins d’avoir une discipline de documentation pré-existante (que je n’ai que sur mes machines d’hébergement). Et surtout… on est encore à mobiliser un ensemble de compétence différents pour faire marcher des versions différentes d’un logiciel (ici, une session graphique). Tout cela est donc fort insatisfaisant.

Ressources supplémentaires

L’introduction de la thèse (en anglais) d’Eeco Dolstra (un des créateurs de Nix) offre une vision plus détaillée - et un peu plus technique des limitations des gestionnaires de paquets.