Les branches Debian et l'APT Pinning

"Debian ? C'est nul, les logiciels sont dépassés."

Combien de fois ai-je entendu cela. Il est vrai que la version Stable a toujours des softs ayant un ou deux ans d'ancienneté. Elle est loin d'être "à la pointe", et c'est tout simplement sa raison d'être : ce que l'on recherche avec une Debian Stable, c'est la stabilité et la sécurité, deux facteurs que des versions nouvelles ne peuvent garantir. Évidemment, pour ce qui est de la sécurité, les "vieux" logiciels sont suivis de près par l'équipe Sécurité de Debian, qui patchera la moindre faille décelée.

Tout cela est parfait pour un serveur.

Pour un poste client, les besoins sont différents. La stabilité est un facteur moins critique et il est agréable d'avoir les dernières versions de nos logiciels pour apprécier leurs nouvelles fonctionnalités. Alors, Debian sur poste client, pas adapté ? Faux.

Les branches de Debian

Il en existe plusieurs, chacune ayant une structure et des mécanismes spécifiques destinés à développer Debian. Partons de la plus instable à la plus stable.

Experimental : elle porte bien son nom. On retrouve dans les dépôts Experimental des paquets de logiciels toujours en développement (alpha, beta, RC), mais à priori fonctionnels. Évidemment, l'usage de ces paquets se fait à vos risques et périls, ils ne sont pas censés être utilisés par l'utilisateur final. Ce n'est pas une branche à proprement parler, c'est à dire qu'il n'y a pas de release Debian Experimental, contrairement à Unstable, Testing et Stable.

Unstable : une rolling release où l'on retrouve les paquets de logiciels "finis" les plus récents. Chaque nouveau logiciel passe par Unstable. Les dépôts sont mis à jour toutes les 6 heures. Il ne faut pas avoir peur du mot "unstable" outre mesure : par instable, on entend que le logiciel est nouveau et n'a pas été testé sur Debian, donc qu'il peut comporter des bugs.

Testing : une sorte de rolling release (Une "sorte", car elle a un cycle de développement d'environ 2 ans) générée automatiquement via des scripts depuis Unstable. Pour qu'un paquet Unstable soit transféré vers Testing, il faut :

• Qu'il soit âgé de 10, 5 ou 2 jours (suivant l'urgence de l'upload).
• Qu'il soit compilé et à jour sur toutes les architectures sur lesquelles il a été compilé par le passé dans Unstable.
• Qu'il comporte moins ou autant de bugs critiques que la version actuelle de Testing.
• Que toutes ses dépendances soient satisfaites par les paquets déjà présents dans Testing, ou bien qu'elles soient satisfaites par un ensemble de paquets transférés d'Unstable au même instant.
• Que l'installation des paquets dans Testing ne casse pas un seul paquet actuellement dans Testing.

En résumé, Testing, c'est Unstable avec quelques garanties de stabilité en plus. C'est également la future Stable en développement.

Stable : La branche la plus connue, très réputée pour sa stabilité. Les paquets sont issus de Testing. En fait, à un moment, la branche de testing entre en freeze pour plusieurs mois. Plus aucun paquet venant d'Unstable n'est accepté (sauf exception) , et tous les efforts sont orientés vers la résolution de bugs des paquets freezés. C'est comme cela qu'on obtient une version Stable absolument stable.

Mis à part Experimental, chaque version d'une branche se voit attribuer le nom d'un personnage du film Toy Story. Actuellement, cela nous donne :

• Unstable : Sid, le méchant qui casse tout. Unstable aura toujours ce nom. Signifie aussi Still in Development
• Testing : Wheezy
• Stable : Squeeze

Une dernière chose à savoir concerne le processus de mises à jour de sécurité. Il est différent du processus de mises à jour classique, pour des raisons évidentes : en cas de vulnérabilité importante, la mise à jour mettrait trop de temps à arriver sur Stable. C'est pour cela qu'elles sont gérées par une équipe dédiée et arrivent directement sur Stable. Mais alors, quid des autres branches ? Et bien, et c'est capital de le prendre en compte, les autres branches ne sont pas prises en charge par l'équipe sécurité officielle de Debian ! Le cas de Testing est spécial, vu qu'il s'agit de la prochaine Stable : l'équipe sécurité s'en occupe, mais ne garantit pas la correction des bugs. Soit les mises à jour passeront par Unstable, soit, si cela prend trop de temps, elles seront déployées sur des dépôts semi-officiels, soit il n'y aura aucune mise à jour et le patch sera appliqué lors du passage en Stable. Voilà pourquoi je vous déconseillerai fortement Debian Testing sur un serveur de production. Pour le poste client d'un utilisateur avancé, en revanche, Testing est parfaitement adapté.

J'ai essayé de vous résumer les grandes lignes des différentes branches de Debian. Si vous préférez les schémas, voici tous les détails ici :

APT Pinning

Maintenant que nous avons une idée plus précise de la structure des dépôts Debian, et de leur raison d'être, nous allons pouvoir revenir à notre problème initial : Puis-je avoir des logiciels récents sur Debian ?

Oui, on l'a vu avec Unstable. On pourrait très bien installer une Debian Sid, avec des paquets 100% Sid. Mais nous pouvons faire mieux.

Pourquoi ne pas utiliser la force de chacun des dépôts ? L'idée serait par exemple de disposer d'une distribution stable et sécurisée, Debian Stable, mais de pouvoir ponctuellement installer un paquet plus récent (et ses dépendances) provenant de Testing ou Unstable. C'est ce que nous permet de faire l'apt-pinning.

Nous allons donc renseigner tous les dépôts dans notre fichier sources.list.

/etc/apt/sources.list

Si nous installions un paquet maintenant, les dépôts entreraient en conflit. C'est pourquoi nous définissons des préférences dans le fichier /etc/apt/preferences. Ce que nous voulons, c'est que le dépôt Stable passe avant Testing, qui passe lui même avant Unstable, qui passe avant Experimental.

/etc/apt/preferences

Quelques explications. Prenons par exemple cet extrait :

Première ligne : le ou les paquets concernés par le pinning. Ici, tous.
Deuxième ligne :la définition du pin. Ici, on se base sur la release des paquets.
Dernière ligne : la priorité du pin. Plus elle est grande, plus le pin est prioritaire.

Nous voyons ainsi que sur notre configuration précédente, les priorités des paquets venant d'Experimental, Sid et Wheezy sont plus basses que Stable. Quelques détails sur les valeurs de ces priorités :

Extrait du man d'apt_preferences

Les priorités (P) indiquées dans le fichier des préférences doivent être des
entiers positifs ou négatifs. Ils sont interprétés à peu près comme suit :

P > 1000
cette priorité entraîne l'installation du paquet même s'il s'agit d'un
retour en arrière.

990 < P <=1000
la version sera installée, même si elle n'appartient pas à la distribution
par défaut ; mais elle ne sera pas installée si la version installée est
plus récente.

500 < P <=990
La version sera installée, sauf s'il existe une version appartenant à la
distribution par défaut ou si la version installée est plus récente.

100 < P <=500
la version sera installée, sauf s'il existe une version appartenant à une
autre distribution ou si la version installée est plus récente.

0 < P <=100
la version sera installée si aucune version du paquet n'est installée.

P < 0
cette priorité empêche l'installation de la version.

À présent, mettons à jour aptitude.

Il nous est maintenant possible d'aller piocher un paquet dans un autre dépôt. Il suffit simplement de préciser la release du paquet que l'on souhaite installer, avec l'option -t <release> . Exemple pour Iceweasel :

Si nous avions l'Iceweasel des dépôts Stable installé, il sera mis à jour vers la version Sid, pas besoin de supprimer le paquet au préalable.

Si vous souhaitez voir la version d'un paquet d'un dépôt :

Et voilà, nous avons pu profiter de l'apt-pinning. Pratique, n'est-ce pas ?

Je ne pouvais pas terminer cet article sans mentionner LE lien indispensable pour la configuration des dépôts Debian : le topic debian-fr.org "Sources.list au carré ou minimaliste". Vous trouverez sur ce fil les principaux scénarios de sources.list et leur fichier préférence associé, régulièrement mis à jour. Un véritable incontournable, à garder bien au chaud.