Derrière ce titre un brin provocateur, je vous le concède volontiers, se cache une réalité indéniable.
Debian est une distribution merveilleuse, bénéficiant d’une architecture magnifique, basée pour l’essentiel sur un principe fort: sa gestion des paquets.
Historiquement, le principe est simple. Une série de dépôts présente un choix divers de paquets, dépendants les uns des autres, formant un tout homogène.
Suivant cette logique simple, une conclusion apparaît évidente. Il n’est, dans une logique classique de gestion des dépôts, pas aisé de bénéficier du choix de la version de l’application à utiliser. C’est tout à la fois la force et la faiblesse de Debian et de son architecture. On est bien dans ses pantoufles, mais rapidement coincé si le besoin se fait pressant de “sortir des clous”. Deux approches sont alors possibles, pour combler ce manque:
- Monter et gérer soit même son propre dépôt, dans lequel on viendra ajouter les paquets, sous la forme d’un “backport” ou d’une mise à niveau effectuée soit-même.
- Forcer la monté de version en utilisant des dépôts issus de versions différentes de la distribution, selon un système de priorités. Apt-pining est un outil permettant cela.
L’objet de ce billet est donc de faire une analyse comparative, argumentée et objective de ces deux approches distinctes. Concernant le troisième pré-requis, vous aurez aisément compris que je n’y parviendrai point !
La première approche parait de facto lourde, complexe à mettre en œuvre, et pas nécessairement simple à maintenir. Tous ces aprioris sont parfaitement et totalement exacts et justifiés. Cette relative complexité trouve ses racines dans la structure et l’architecture d’une distribution Debian (et dérivés).
Il est nécessaire pour mettre ceci en œuvre de:
- Savoir gérer un miroir
- Savoir gérer un dépôt
- Savoir “packager” un minimum
La seconde approche permet, sans avoir à passer par toutes ces turpitudes, d’installer un paquet issu d’une version autre de la distribution, voire de “mélanger” allègrement les deux contenus pour obtenir le résultat souhaité, en établissant une série de priorités, paquet par paquet, entre différents dépôts.
Pourquoi donc, devant une telle “simplicité”, devrais-je m’offusquer et oser un pareil titre ? La réponse est simple: ceci induit la perte de la maîtrise de son système, coupe du support communautaire et/ou professionnel (cas Ubuntu par exemple), tout en “cassant” tous les fondamentaux de ce qui fait la force d’une distribution Debian: son architecture.
Certes, l’approche est séduisante, mais en pratique, du fait même de l’approche technique de la structure d’un paquet Debian, elle n’est pas viable sur le long terme. En effet, un paquet conçu pour un dépôt est généré sur la base de ce même dépôt, et l’ensemble des constituantes de ce paquet sont issues de ce dépôt.
De manière logique, on pourra schématiser la problématique de cette façon de travailler de la manière suivante:
- Un paquet A et un paquet B dépendent d’une librairies C
- Je veux utiliser le paquet A issu de la version la plus récente de mon système
- Celui-ci dépend d’une version plus récente de la librairie C, mais l’ABI de celle-ci n’a pas changé
- Mon paquet B supporte théoriquement cette librairies, du fait d’une dépendance conditionnelle (>=)
- Ma librairie se met à jour en même temps que le paquet A
- J’ai un paquet B qui fonctionne avec une librairie C sans avoir été compilé avec cette version précise de la librairie. Certes l’ABI n’a pas changé, mais personne n’a pu tester cette configuration précise, celle-ci étant iconoclaste
On voit donc qu’en mettant un seul petit paquet à jour, je peux prendre le risque de corrompre la cohérence globale de mon système, et surtout de me mettre dans une situation dans laquelle aucun support communautaire n’est possible.
Il suffit de regarder une seule fois, de prêt, la liste des dépendances d’un paquet comme “apache2″ pour comprendre le risque pris lors de l’utilisation d’un tel procédé.
L’approche classique, qui consiste à créer un “backport” du paquet source plus récent, puis à le placer dans un dépôt personnalisé, entraine de fait une recompilation des sources de ce même paquet à l’aide de la librairie du dépôt courant, et n’engendre donc pas le cas complexe ou deux paquets dépendent techniquement d’une même librairie dans deux version différentes, ce qui va à l’encontre même de l’architecture Unix. Pour fonctionner dans un tel système, il conviendrait d’avoir une approche “Windowsienne” du problème, et que chaque application vienne avec ses propres fichiers DLL.
L’approche lourde et complexe faisant l’objet de mes louanges est certes complexe à appréhender, apprendre, mais permet une gestion pérenne sur le long terme d’un grand nombre de machines.
Le fait simple de devoir apprendre le packaging Debian n’est probablement pas une évidence pour beaucoup d’administrateurs et il n’est certainement pas requis d’en devenir un expert, mais les notions de base permettant de créer un backport et de gérer un petit dépôt personnel peuvent s’acquérir rapidement. Ce travail est de plus une extraordinaire manière d’apprendre et comprendre Debian, et développe une vision beaucoup plus approfondie et juste de la gestion d’une distribution, au sens large.
J’oserai le “troll” suivant, partisant, mais néanmoins sincère: apt-pining est à la gestion des dépôts ce que le WYSIWYG est à la création d’un site Web… Une fausse bonne idée.
