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

## stable
deb http://ftp.fr.debian.org/debian/ stable main contrib non-free
deb-src http://ftp.fr.debian.org/debian/ stable main contrib non-free

# stable security
deb http://security.debian.org/ stable/updates main contrib non-free
deb-src http://security.debian.org/ stable/updates main contrib non-free

# stable update
deb http://ftp.fr.debian.org/debian/ stable-updates main contrib non-free
deb-src http://ftp.fr.debian.org/debian/ stable-updates main contrib non-free

################################################
## testing
deb http://ftp.fr.debian.org/debian/ testing main contrib non-free
deb-src http://ftp.fr.debian.org/debian/ testing main contrib non-free

## testing multimedia
deb http://www.debian-multimedia.org testing main non-free
deb-src http://www.debian-multimedia.org/ testing main

## testing security
deb http://security.debian.org/ testing/updates main contrib non-free
deb-src http://security.debian.org/ testing/updates main contrib non-free

################################################
## sid
deb http://ftp.fr.debian.org/debian/ sid main contrib non-free
deb-src http://ftp.fr.debian.org/debian/ sid main contrib non-free

################################################
## experimental
deb http://ftp.fr.debian.org/debian/ experimental main contrib non-free
deb-src http://ftp.fr.debian.org/debian/ experimental main contrib non-free

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

Package: *
Pin: release o=apt-build
Pin-Priority: 995

Package: *
Pin: release o=Debian,a=squeeze-updates,l=Debian
Pin-Priority: 990

Package: *
Pin: release o=Debian,a=stable,l=Debian-Security
Pin-Priority: 990

Package: *
Pin: release o=Debian,a=stable,l=Debian
Pin-Priority: 990

Package: *
Pin: release o=Debian,a=testing,l=Debian-Security
Pin-Priority: 90

Package: *
Pin: release o=Debian,a=testing,l=Debian
Pin-Priority: 90

Package: *
Pin: release o=Debian,a=unstable,l=Debian
Pin-Priority: 50

Package: *
Pin: release o=Debian,a=experimental,l=Debian
Pin-Priority: 10

Quelques explications. Prenons par exemple cet extrait :

Package: *
Pin: release o=Debian,a=squeeze-updates,l=Debian
Pin-Priority: 990

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.

# aptitude update

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 :

# aptitude -t unstable install 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 :

# aptitude -t <release> show <package>

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.

7 réflexions au sujet de « Les branches Debian et l'APT Pinning »

  1. Ola

    Merci pour ce post, très instructif....

    Je suis en train de tester le "pinning" sur une Squeeze en suivant cette méthode. Cependant en tentant l'installation de chromium-browser du dépôt unstable :

    $ aptitude -t unstable install chromium-browser

    il m'est proposé de désinstaller en plus un nombre très important de paquet :

    Je ne suis pas allé au bout...

    N'est-ce pas étonnant ?

  2. Bonjour,

    Merci pour cet article clair.

    J'ai déjà entendu ce son de cloche auparavant sur l'effective possibilité de maintenir des logiciels en version plus avancée sur debian. Alors que je ne conteste pas que theoriquement, c'est tout à fait possible comme tu le présentes, dans la pratique, je doute énormément que ça se passe toujours bien. Par ex, http://debian-facile.org/forum/viewtopic.php?id=2767 où la moitié de mon système passait en testing si je mettais à jour vlc. Alors quand tu dis ""Debian ? C'est nul, les logiciels sont dépassés."
    Combien de fois ai-je entendu cela"

    C'est qu'effectivement, il est normal que tu ai entendu cela beaucoup de fois, mais ce n'est pas forcément sans raison. Debian n'étant pas prévue à la base pour faire ça. La seule chose que je vois, c'est d'avoir la chance que le paquet soit dans backport qui est supporté officiellement désormais.

    Un utilisateur de debian.

  3. Bonjour Cyberlab et François,

    Au vu de vos commentaires, je réalise que j'aurais dû prévenir que l'apt-pinning n'est pas une solution infaillible, qu'effectivement parfois, la gestion des dépendances est trop complexe. Pour ma part j'ai déjà eu des soucis de la sorte, qui s'expliquaient par des priorités mal définies. Il faut vraiment faire attention à la valeur du Pin-Priority.

    Personnellement j'ai toujours réussi à m'en sortir sans mettre à jour ou supprimer la moitié de mon système. C'est peut-être aussi parce que j'utilise l'apt-pinning sur une testing vers une unstable, l'écart de version entre les paquets est moins important que pour un stable->unstable.

    Il est clair que cette méthode est fortement déconseillée en production, et est à utiliser avec un recul certain, nous avons en les preuves avec vos exemples.

  4. A ce moment là, nous tombons d'accord :)
    J'ajoute que dans mon cas c'était un mix stable-lenny en fin de vie avec testing-squeeze

  5. Bonjour,

    Très bon guide, base que j'utilise depuis longtemps. Attention par contre, le dépôt multimédia n'est plus le bon et surtout le domaine a apparemment été squatté, il faut absolument ne plus l'utiliser.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>