La gestion des paquets est l'endroit où un système respecte votre temps ou vous le vole discrètement. Deux décisions se prennent généralement ensemble et gagnent à être séparées : ce que fait le gestionnaire de paquets quand une transaction échoue, et le moment où vous payez le changement. 0dyssey est construit sur xbps et une base Void en publication continue. Les deux moitiés de ce raisonnement se généralisent bien au-delà de ces deux choix.
Le premier test : que se passe-t-il à mi-chemin ?
Le moment intéressant d'un gestionnaire de paquets n'est pas l'installation réussie. C'est celle qui meurt au milieu : une connexion coupée, un disque plein, un Ctrl-C à la mauvaise seconde, une coupure de courant pendant une mise à niveau.
Un gestionnaire de paquets réussit ce test quand l'interruption vous laisse exactement là où vous étiez, avec une base de données qui décrit toujours le système que vous avez réellement. Il échoue quand il vous laisse quelque part entre les deux, avec la moitié d'une transaction appliquée et une base qui décrit désormais une machine qui n'existe pas. La procédure de récupération du second cas relève du folklore, et le folklore ne passe pas à l'échelle d'un système que d'autres personnes font tourner.
xbps applique les installations et les suppressions sous forme de transactions : elles aboutissent ou elles sont annulées. Cette propriété unique explique sa présence dans la pile. Il est aussi rapide, parce que le format de paquet et le résolveur de dépendances ont été conçus ensemble plutôt que greffés sur dix ans de rétrocompatibilité, mais la vitesse est un confort et l'atomicité n'en est pas un.
# synchroniser l'index distant, puis mettre à jour le système en une seule transaction
$ sudo xbps-install -Su
# chercher dans les dépôts distants avant d'installer quoi que ce soit
$ xbps-query -Rs compositor
# supprimer les paquets dont plus rien ne dépend
$ sudo xbps-remove -o
# vérifier la base de données des paquets par rapport à ce qui est réellement sur le disque
$ xbps-pkgdb -aLes deux dernières commandes sont révélatrices. Le nettoyage des orphelins et la vérification d'intégrité de la base ne sont pas des fonctionnalités que l'on met sur une page d'accueil. Elles existent parce que les gens qui ont construit l'outil font tourner ce qu'ils ont construit, et qu'à un moment ils ont voulu demander au système s'il correspondait encore à ses propres registres.
Le second test : quand payez-vous le changement ?
Tout système paie le changement. La seule question est de savoir s'il le paie en continu ou d'un seul bloc.
Les versions ponctuelles semblent sûres. On fige un instantané, on le livre, et l'on se dit que l'on a réduit le risque. Ce que l'on a réellement fait, c'est le reporter, puis le payer d'un coup lors d'une gigantesque migration de changement de version qui touche tout simultanément.
Une base figée est réellement la bonne réponse pour un parc qui ne doit pas bouger : un système à l'intérieur d'un périmètre de certification, ou dont la charge de travail est validée pour un ensemble exact de versions. C'est une exigence réelle, et la publication continue serait la mauvaise réponse dans ce cas. Quiconque prétend le contraire n'a pas eu à signer les papiers.
C'est la mauvaise réponse pour un système dont le rôle est de rester à jour avec le matériel et les chaînes d'outils qu'il y a dessous. Une base en publication continue intègre le changement sous forme de flux contre lequel on peut tester en permanence, plutôt que d'une falaise du haut de laquelle on se jette tous les deux ans. Associée à des installations transactionnelles, l'unité de risque devient un paquet à un instant donné, une taille sur laquelle une personne peut réellement raisonner.
Ce que coûte la publication continue, sans détour
- La publication continue exige de la discipline de la part de qui maintient le système. Les mises à jour qui atteignent les utilisateurs doivent être testées d'abord, et cette charge ne s'arrête jamais.
- Il n'y a pas de numéro de version sur lequel fonder une certification, ce qui est un vrai blocage dans les environnements qui en exigent un.
- « Ça marchait hier » cesse d'être un rapport de bogue utile : il faut donc pouvoir dire précisément ce qui a changé et le remettre comme avant.
Le troisième point est ce qui lie les deux décisions. Un modèle en publication continue n'est défendable que sur un gestionnaire de paquets qui revient proprement en arrière. Choisissez l'un sans l'autre et vous avez pris le coût des deux : un changement continu sans possibilité d'annuler.
L'engagement, et ses limites
0dyssey est construit pour hériter de xbps et d'une base en publication continue de Void, avec sa propre couche d'expérience utilisateur par-dessus plutôt qu'un fork de ce qui est dessous. Cette couche est la partie dont nous sommes propriétaires, et l'engagement que nous acceptons de prendre en public est un critère plutôt qu'une promesse de vitesse : une opération sur les paquets doit être une transaction, et une mise à jour doit pouvoir être annulée.
Il n'y a pas encore de build à installer : rien ici n'est donc un benchmark ni le compte rendu d'une machine en fonctionnement. C'est la décision, écrite tant qu'il est encore peu coûteux de la discuter, et elle est écrite comme un critère à dessein. Si un meilleur modèle de paquets apparaît et satisfait les deux tests, le critère survit et le choix en dessous peut changer.