Recherche de site Web

Comment faire l’épinglage Debian

Debian, également connue sous le nom de « système d’exploitation universel », est l’une des plus anciennes distributions Linux. À tout moment, il y a toujours trois versions principales de Debian : stable, testing et unstable. La version « stable » représente la version officielle de Debian : elle est solide comme le roc, prête pour la production et contient des paquets qui ne changent pas grand-chose. La version « testing » contient des paquets qui sont en route pour être acceptés dans stable, et enfin, la version « unstable » est celle avec les versions les plus récentes du logiciel, utilisées pour le développement de la distribution.

Dans ce tutoriel, nous voyons comment installer des paquets de testing et unstable sur la version stable de Debian, en utilisant la technique de l’épinglage.

Dans ce tutoriel, vous allez apprendre :

  • Comment ajouter des dépôts testing et unstable aux sources de logiciels « stables » de Debian
  • Comment les priorités des packages sont attribuées par défaut
  • Comment configurer l’épinglage
  • Comment installer explicitement un paquet à partir de « testing » ou « unstable »

Ajout de dépôts Debian testing et unstable à la version stable

Il faut éviter de mélanger des paquets de différentes versions de Debian à moins qu’il n’y ait pas d’alternatives disponibles. Cela dit, pour installer des paquets de testing ou unstable dans la version stable de Debian, la première chose que nous devons faire est d’ajouter les dépôts respectifs aux sources des logiciels de distribution. La façon la plus simple d’accomplir cette tâche consiste à ajouter les entrées suivantes dans le fichier /etc/apt/sources.list :

deb http://deb.debian.org/debian testing main contrib
deb http://deb.debian.org/debian unstable main contrib

Les versions de Debian sont nommées d’après des personnages de Toy Story. Au moment de la rédaction, par exemple, la version stable de est nommée « bullseye », tandis que testing est nommée « bookworm » (la version instable est toujours nommée « sid »). Dans le fichier /etc/apt/sources.list, les versions peuvent être référencées soit par leur nom, soit par la classe de publication elle-même (stable/testing/unstable). Dans l’exemple ci-dessous, nous avons adopté cette dernière stratégie.

Chaque dépôt de version Debian a essentiellement trois « composants » : main, contrib et non-free. Le composant « principal » ne contient que des logiciels libres et open source ; Le composant « contrib » contient des logiciels libres et open source qui ont quelques dépendances non libres. Enfin, le composant « non-free » contient des logiciels qui ne respectent pas les directives du logiciel libre Debian. Un composant « backports » (bullseye-backports dans le cas de la version « stable » actuelle de Debian), est également disponible comme un moyen sûr de fournir des logiciels plus récents recompilés à partir de
« testing » par rapport aux librairies déjà disponibles sur « stable ». Dans l’exemple ci-dessus, comme vous pouvez le voir, nous n’avons utilisé que les deux premiers composants.

Une fois que les dépôts testing et/ou instables ont été ajoutés en tant que sources logicielles, nous devons modifier les priorités des paquets en fonction de la façon dont nous voulons que le système se comporte. Voyons comment faire.

Comment les priorités sont attribuées par défaut

Lorsque plusieurs versions d’un même paquet sont disponibles, APT utilise un système prioritaire pour choisir celle qui doit être installée. Avant d’apprendre comment les priorités des paquets peuvent être définies explicitement dans le fichier /etc/apt/preferences (ou dans des fichiers dédiés sous le répertoire /etc/apt/preferences.d), nous devons comprendre comment les priorités sont attribuées. Cela dépend de la définition ou non d’une version cible. La version cible de Debian n’est pas définie par défaut, mais peut être définie dans le fichier /etc/apt/apt.conf. Par exemple, pour définir « stable » comme version cible, nous écririons :

APT::Default-Release "stable"

Si la version cible est définie, les paquets de celle-ci ont la priorité la plus élevée :

  • La priorité 100 est attribuée aux packages déjà installés.
  • La priorité 900 est attribuée aux packages de la version cible
  • La priorité 500 est attribuée à d’autres packages

Si la version cible n’est pas définie, la priorité 100 est attribuée aux packages installés, tandis que tous les packages disponibles reçoivent une priorité de 500. La version la plus élevée disponible d’un paquet est sélectionnée comme candidate à l’installation, et les paquets ne sont jamais autorisés à être rétrogradés, à moins que leur priorité ne soit explicitement définie sur > 1000. Plus précisément, les valeurs de priorité (entiers) sont interprétées par APT de la manière suivante :

  • Priorité < 0 : empêche l’installation d’une version de paquet
  • Valeur de priorité comprise entre 1 et 99 : ne provoque l’installation d’une version que s’il n’y a pas de version installée du package.
  • Priorité entre 100 et 499 : provoque l’installation d’une version à moins qu’il n’y ait une version disponible appartenant à une autre distribution ou que la version installée soit plus récente
  • Priorité entre 500 et 989 : provoque l’installation d’une version sauf s’il existe une version disponible appartenant à la version cible ou si la version installée est plus récente
  • Priorité entre 990 et 999 : provoque l’installation d’une version même si elle ne provient pas de la version cible, sauf si la version installée est plus récente
  • Priorité > 1000 : provoque l’installation d’une version même si cela constitue une rétrogradation du paquet

Les priorités peuvent être écrasées en définissant des règles dans le fichier /etc/apt/preferences. Voyons comment.

Le fichier /etc/apt/preferences

Pour définir une règle dans le fichier /etc/apt/preferences, nous devons fournir trois informations :

  1. Ces motifs qui doivent correspondre pour la règle à appliquer (il peut s’agir d’un nom de paquet, d’une expression régulière étendue POSIX, ou d’un « * » pour correspondre à tous les paquets disponibles)
  2. La version, l’origine ou la version du package
  3. La priorité du forfait

Voyons quelques exemples. Comme nous l’avons spécifié ci-dessus, lorsque la version cible n’est pas définie, la version la plus récente d’un paquet est sélectionnée comme candidate à l’installation. Nous avons ajouté les versions de test et instables comme sources logicielles, donc, puisque cette dernière contient les paquets les plus récents, les logiciels que nous essayons d’installer doivent en être extraits (si disponibles). Supposons que nous voulions installer ansible ; Pour vérifier que ce que nous venons de dire est vrai, nous pouvons utiliser la commande apt-cache policy, qui affiche la priorité de chaque source logicielle et la version du paquet qui serait sélectionnée comme candidate à l’installation, si un nom de paquet est passé en argument. Nous gérons :

apt-cache policy ansible

La commande renvoie le résultat suivant :

ansible:
  Installed: (none)
  Candidate: 7.3.0+dfsg-1
  Version table:
     7.3.0+dfsg-1 500
        500 http://deb.debian.org/debian testing/main amd64 Packages
        500 http://deb.debian.org/debian unstable/main amd64 Packages
     2.10.7+merged+base+2.10.8+dfsg-1 500
        500 http://deb.debian.org/debian bullseye/main amd64 Packages

Comme vous pouvez le voir, la version 7.3.0+dfsg-1 du paquet est disponible à la fois dans les dépôts « testing » et « unstable », tandis que le dépôt « stable » contient la version 2.10.7+merged+base+2.10.8+dfsg-1, qui est plus ancienne. Toutes les versions ont la même priorité (500), cependant, la plus récente est choisie.

Maintenant, supposons que nous voulions ajouter les dépôts testing et unstable à notre système Debian « stable », mais que nous voulions installer des paquets à partir de ceux-ci uniquement sur demande explicite. Sans définir de version cible, nous pourrions définir les règles suivantes et attribuer une priorité inférieure aux paquets de testing et unstable :

Package: *
Pin: release a=stable
Pin-Priority: 900

Package: *
Pin: release a=testing
Pin-Priority: 600

Package: *
Pin: release a=unstable
Pin-Priority: 500

Les règles ci-dessus correspondent à tous les packages, puisque nous avons utilisé un « * » (une expression glob). Les expressions régulières étendues POSIX peuvent également être utilisées. Pour correspondre à un paquet spécifique, nous aurions simplement entré son nom, à la place. Nous avons épinglé les paquets par archive de version (c’est ce que signifie le « a » dans « a=stable »), et nous avons attribué des priorités décroissantes commençant par « stable » (priorité 900), puis « testing » (priorité 600) et enfin « instable » (priorité 500). Les sorties peuvent également être sélectionnées par leur « nom », par exemple, nous pourrions écrire :

Package: *
Pin: release n=bullseye
Pin-Priority: 900

Nous enregistrons les règles et vérifions à nouveau le résultat de la commande apt-cache. Comme vous pouvez le voir, cette fois-ci, le paquet sélectionné comme candidat à l’installation est celui qui provient du dépôt stable, qui a une priorité plus élevée :

ansible:
  Installed: (none)
  Candidate: 2.10.7+merged+base+2.10.8+dfsg-1
  Version table:
     7.3.0+dfsg-1 600
        600 http://deb.debian.org/debian testing/main amd64 Packages
        500 http://deb.debian.org/debian unstable/main amd64 Packages
     2.10.7+merged+base+2.10.8+dfsg-1 900
        900 http://deb.debian.org/debian bullseye/main amd64 Packages

Dans une telle situation, comment installer explicitement un paquet à partir de testing ou unstable ? Nous pouvons définir temporairement la « version cible » à partir de la ligne de commande, en utilisant l’option -t ( --target-release) au moment de l’exécution, pour une seule commande. Cela permettra au package et à ses dépendances d’être installés à partir de la version spécifiée ou, s’ils sont déjà installés, mis à jour vers la version de la version cible si le package le nécessite. Par exemple, pour installer le paquet « ansible » en utilisant « testing » comme version cible, nous exécuterions :

sudo apt-get install -t testing ansible

Pour installer uniquement le paquet d’une version spécifique, mais essayer de satisfaire ses dépendances selon les priorités établies, nous exécuterions plutôt :

sudo apt-get install ansible/testing

Cependant, la plupart du temps, cela pourrait entraîner des erreurs telles que les suivantes :

The following packages have unmet dependencies:
 ansible-core : Depends: python3-jinja2 (>= 3.0.0~) but 2.11.3-1 is to be installed

Il va de soi qu’il faut être extrêmement prudent et inspecter les rapports de pré-installation avec une extrême attention lorsqu’on mélange des paquets de différentes versions de Debian. Vous devez toujours vérifier si une version mise à jour d’un paquet est disponible dans le dépôt « backports » avant de mélanger des logiciels de différentes versions de Debian.

Conclusions

Dans ce tutoriel, nous avons vu comment il est possible d’inclure des dépôts de logiciels de Debian testing et unstable dans la version stable, et de définir les priorités des paquets en utilisant la technique de « l’épinglage ». Nous avons appris comment les priorités sont attribuées selon qu’une version Debian cible/par défaut est définie ou non, et nous avons vu comment remplacer le comportement par défaut en spécifiant des règles de priorité. Pour plus d’exemples, veuillez jeter un coup d’œil à la page de manuel apt_preferences.

Articles connexes: