PaquetsObjectif de cet atelier pratique :

  • Installer et gérer des logiciels sur un système Linux de la famille Red Hat avec le gestionnaire de paquets DNF

Système : Rocky Linux 8

Après l’installation des composants logiciels depuis le code source et la gestion des paquets avec l’outil RPM, le moment est venu de vous présenter DNF (Dandified Yum), un gestionnaire de paquets en ligne de commande, tout comme RPM. À la différence de ce dernier, il gère automatiquement le téléchargement des paquets et la résolution des dépendances, ce qui augmente considérablement le confort d’utilisation au quotidien.

AstuceDNF est le successeur du gestionnaire de paquets Yum, lui-même une réécriture complète de Yup (Yellowdog Updater), le gestionnaire de mises à jour utilisé par Yellow Dog Linux, une distribution basée sur CentOS et Fedora et développée pour les ordinateurs équipés d’un processeur PowerPC comme les Macintosh d’Apple d’avant 2006. La distribution Yellow Dog Linux n’est plus maintenue depuis 2009.

Installer un paquet avec DNF

Pour illustrer le fonctionnement de DNF, partons d’une installation minimale de Rocky Linux dans sa configuration par défaut et utilisons-le pour installer le paquet quota :

$ sudo dnf install quota
...
Dependencies resolved.
==========================================================
 Package    Architecture  Version        Repository  Size
==========================================================
Installing:
 quota      x86_64        1:4.04-14.el8  baseos      213 k
Installing dependencies:
 quota-nls  noarch        1:4.04-14.el8  baseos       94 k

Transaction Summary
==========================================================
Install  2 Packages

Total download size: 306 k
Installed size: 1.1 M
Is this ok [y/N]: 

L’écran affiche alors pléthore d’informations. Essayons de comprendre un peu ce qui se passe.

  • Dans un premier temps, DNF se connecte au dépôt de téléchargement (baseos) pour récupérer la liste des paquets disponibles en ligne.
  • Il identifie le paquet recherché (quota) et se charge de résoudre les dépendances requises.
  • Il en trouve une (quota-nls).
  • Au bout de cette opération, DNF affiche un tableau récapitulatif qui résume ce qu’il a l’intention de faire : télécharger et installer le paquet quota comme prévu, de même que la dépendance requise quota-nls.

Il suffit de confirmer par Y (yes) et DNF s’exécute :

Is this ok [y/N]: y
Downloading Packages:
(1/2): quota-nls-4.04-14.el8.noarch.rpm  595 kB/s |  94 kB  00:00    
(2/2): quota-4.04-14.el8.x86_64.rpm      907 kB/s | 213 kB  00:00    
-----------------------------------------------------------------
Total                                    550 kB/s | 306 kB  00:00     
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                 1/1 
  Installing       : quota-nls-1:4.04-14.el8.noarch  1/2 
  Installing       : quota-1:4.04-14.el8.x86_64      2/2 
  Running scriptlet: quota-1:4.04-14.el8.x86_64      2/2 
  Verifying        : quota-1:4.04-14.el8.x86_64      1/2 
  Verifying        : quota-nls-1:4.04-14.el8.noarch  2/2 

Installed:
  quota-1:4.04-14.el8.x86_64  quota-nls-1:4.04-14.el8.noarch                  

Complete!

Lors de la première utilisation d’une archive de téléchargement, DNF vous demande s’il doit importer la clé GPG. Il s’agit d’une clé numérique qui sert à garantir d’authenticité des paquets téléchargés.

AstuceGNU Privacy Guard, de son petit nom GPG, est un clone libre de PGP (Pretty Good Privacy). Tous deux sont des systèmes de signature et chiffrement de l’information reposant sur un système de clés que l’on s’échange afin de pouvoir décrypter ou vérifier l’information. Pour en savoir plus sur GPG, je vous conseille la lecture de l’excellent ouvrage PGP & GPG – Email for the Practical Paranoid de Michael W. Lucas, dont la traduction française est disponible chez Eyrolles.

Vous avez envie de retenter l’expérience ? Cette fois-ci, utilisez l’option -y qui évite les demandes de confirmation :

$ sudo dnf install -y nmap

Supprimer des paquets avec DNF

La suppression d’un paquet se fait grâce à l’option remove. Là aussi, DNF se charge automatiquement de rétablir l’intégrité du système :

$ sudo dnf remove nmap-ncat

Rappelez-vous que RPM nous interdisait la suppression d’un paquet tant qu’un autre paquet qui en dépendait était installé. Voyons ce qu’en pense DNF :

=========================================================
 Package    Architecture  Version       Repository  Size
=========================================================
Removing:
 nmap-ncat  x86_64        2:7.70-6.el8  @appstream  480 k
Removing dependent packages:
 nmap       x86_64        2:7.70-6.el8  @appstream   23 M

Transaction Summary
=========================================================
Remove  2 Packages

Freed space: 24 M
Is this ok [y/N]:

Ici, nmap-ncat sera enlevé sans problème, mais nmap sera également supprimé dans la foulée (Removing dependent packages) pour que le système garde sa cohérence.

DNF et les dépendances orphelines

Lancez la suppression interactive du paquet quota sans confirmer l’opération de désinstallation et regardez ce qui se passe :

$ sudo dnf remove quota
...
==========================================================
 Package    Architecture  Version        Repository  Size
==========================================================
Removing:
 quota      x86_64        1:4.04-14.el8  @baseos     887 k
Removing unused dependencies:
 quota-nls  noarch        1:4.04-14.el8  @baseos     277 k

Transaction Summary
==========================================================
Remove  2 Packages
...

Ici, DNF gère automatiquement la suppression de la dépendance orpheline quota-nls.

AstuceUne dépendance orpheline est un paquet qui ne sert plus à rien à partir du moment où les paquets qui en dépendant sont supprimés.

Effectuer une mise à jour

La mise à jour des applications et même du système entier se fait avec une facilité déconcertante. L’option check-update vous affiche la liste complète de tous les paquets installés pour lesquels des mises à jour sont disponibles. Elle s’invoque sans privilèges particuliers :

$ dnf check-update
...
NetworkManager.x86_64        1:1.36.0-7.el8_6      baseos   
NetworkManager-libnm.x86_64  1:1.36.0-7.el8_6      baseos   
NetworkManager-team.x86_64   1:1.36.0-7.el8_6      baseos   
NetworkManager-tui.x86_64    1:1.36.0-7.el8_6      baseos   
bash.x86_64                  4.4.20-4.el8_6        baseos   
ca-certificates.noarch       2022.2.54-80.2.el8_6  baseos   
curl.x86_64                  7.61.1-22.el8_6.4     baseos   
dbus.x86_64                  1:1.12.8-18.el8_6.1   baseos   
dbus-common.noarch           1:1.12.8-18.el8_6.1   baseos   
dbus-daemon.x86_64           1:1.12.8-18.el8_6.1   baseos
...

À partir de là, l’option update met à jour un paquet installé :

$ sudo dnf update tzdata

Si la mise à jour d’un paquet dépend de celle de dépendances, celle-ci s’effectue automatiquement :

$ sudo dnf update openssl
...
=================================================================
 Package       Architecture  Version           Repository   Size
=================================================================
Upgrading:
 openssl       x86_64        1:1.1.1k-7.el8_6  baseos       708 k
 openssl-libs  x86_64        1:1.1.1k-7.el8_6  baseos       1.5 M

Transaction Summary
=================================================================
Upgrade  2 Packages
... 

La solution la plus simple consiste certainement à garder le système entier à jour. Invoquée sans autre argument, l’option update met à jour l’intégralité du système :

$ sudo dnf update

Ce qu’il faut savoir sur les mises à jour

Dans le sillage de Red Hat Enterprise Linux, Rocky Linux publie régulièrement des versions majeures et mineures de sa distribution Linux clonée. À titre d’exemple, Rocky Linux 8.4 a été publié le 21 juin 2021. Les paquets constituant cette version ont été régulièrement mis à jour pour corriger les bogues et les failles de sécurité. Puis, le 16 novembre 2021, toutes ces mises à jour ont été incluses dans la publication de la version mineure 8.5. Au moment où j’écris ces lignes (septembre 2022), Rocky Linux 8 en est arrivé à sa sixième version mineure.

Ce qu’il faut retenir, c’est que quelqu’un qui a installé le système en juin 2021 avec un support d’installation Rocky Linux 8.4 peut effectuer une mise à jour de son système grâce à dnf update et se retrouver exactement avec le même système sur sa machine que quelqu’un qui l’installe aujourd’hui à partir d’un support de la version 8.6.

AstuceChaque nouvelle version de Rocky Linux, même mineure, prend en charge davantage de matériels, sous forme de modules ajoutés au kernel. Si le support d’installation d’une ancienne version de Rocky Linux ne reconnaît pas un certain matériel (comme la carte réseau), c’est le moment de tenter le coup avec une version plus récente.

Afficher les listes de paquets par états

L’option list combinée à d’autres arguments permet de lister les paquets par états. Par exemple, ceux qui sont installés :

$ dnf list installed

Le résultat de cette commande est un peu plus lisible qu’un simple rpm -qa, mais c’est une question de préférence personnelle. Pour afficher la liste complète des paquets disponibles :

$ dnf list available

Cette soupe alphabétique composée de quelques milliers de paquets ne vous paraît probablement pas très parlante. Nous verrons un peu plus loin les fonctions de recherche sur les paquets. Pour afficher la liste des mises à jour disponibles :

$ dnf list updates

Cette commande a le même effet que l’option check-update, au détail près que la présentation du résultat est différente. Là aussi, c’est avant tout une question de goût. Pour afficher la liste des nouveautés disponibles dans les archives :

$ dnf list recent

L’argument extras affiche la liste des paquets installés sur le système, qui ne sont présents dans aucune archive. Cette commande ne retournera rien pour l’instant :

$ dnf list extras

Et pour avoir une idée de tout (!) ce qu’il y a :

$ dnf list all

Gérer les groupes de paquets

Certaines applications requièrent l’installation de toute une série de paquets, que même l’administrateur le plus chevronné ne peut pas connaître par cœur. Dans ce cas, les groupes de paquets nous facilitent la tâche :

$ dnf group list
...
Available Environment Groups:
   Server with GUI
   Server
   Workstation
   Virtualization Host
   Custom Operating System
Installed Environment Groups:
   Minimal Install
Available Groups:
   Container Management
   .NET Core Development
   RPM Development Tools
   Development Tools
   Graphical Administration Tools
   Headless Management
   ...

Pour une raison mystérieuse, les groupes de paquets sont pour la plupart occultés dans la configuration par défaut depuis Red Hat Enterprise Linux 7.0. L’option hidden sert à les afficher :

$ dnf group list hidden
...
Available Environment Groups:
   Server with GUI
   Server
   Workstation
   Virtualization Host
   Custom Operating System
Installed Environment Groups:
   Minimal Install
   ...
Available Groups:
   Backup Client
   base-x
   Conflicts AppStream
   Container Management
   Debugging Tools
   Desktop Debugging and Performance Tools
   DNS Name Server
   ...

Les résultats de group list sont filtrables à l’aide de grep, comme ceci par exemple :

$ dnf group list hidden | grep -i file
   File and Storage Server
   Network File System Client
   Windows File Server

À partir de là, je peux installer un groupe de paquets en utilisant group install. Admettons que je veuille disposer de tous les paquets du système de base :

$ sudo dnf group install "Core"

Le groupe de paquets Base fournit un système de base étendu sous forme d’une panoplie complète d’outils courants comme l’éditeur Vim, les pages de manuel en ligne et bien d’autres choses encore. Sur un système Rocky Linux, c’est l’équivalent des boîtes à outils complètes que vous trouvez dans les magasins de bricolage. Je vous conseille donc d’installer ce groupe de paquets :

$ sudo dnf group install "Base"

Dorénavant, le résultat de la commande dnf group list arbore deux sections distinctes :

  • les groupes de paquets déjà présents sur votre système (Installed Groups)
  • ceux susceptibles d’être installés (Available Groups)
$ dnf group list hidden
...
Installed Groups:
   Base
   Core
Available Groups:
   Backup Client
   base-x
   Conflicts AppStream
   Container Management
   Debugging Tools
   Desktop Debugging and Performance Tools
   DNS Name Server
   ...

Admettons que je veuille installer un serveur de messagerie sur ma machine, je pourrais le faire tout simplement comme ceci :

$ sudo dnf group install "Mail Server"

Pour supprimer tout un groupe de paquets, c’est aussi simple que l’installation :

$ sudo dnf group remove "Mail Server"

Notez que cette dernière commande supprime également les dépendances orphelines du système.

Obtenir des informations sur les paquets

L’option info affiche les informations concernant un paquet :

$ dnf info httpd
...
Name         : httpd
Version      : 2.4.37
Release      : 47.module+el8.6.0+985+b8ff6398.2
Architecture : x86_64
Size         : 1.4 M
Source       : httpd-2.4.37-47.module+el8.6.0+985+b8ff6398.2.src.rpm
Repository   : appstream
Summary      : Apache HTTP Server
URL          : https://httpd.apache.org/
License      : ASL 2.0
Description  : The Apache HTTP Server is a powerful, efficient, and extensible
             : web server.

Le résultat est similaire à celui de rpm -qi, au détail près que la présentation est différente. En revanche, les informations s’affichent même si le paquet n’est pas installé.

Rechercher un paquet

L’option search vous permet de rechercher un paquet :

$ dnf search vim
...
=================== Name & Summary Matched: vim ====================================
vim-X11.x86_64 : The VIM version of the vi editor for the X Window System - GVim
vim-common.x86_64 : The common files needed by any version of the VIM editor
vim-enhanced.x86_64 : A version of the VIM editor which includes recent enhancements
vim-filesystem.noarch : VIM filesystem layout
vim-minimal.x86_64 : A minimal version of the VIM editor

Si vous voulez effectuer une recherche sur un terme de la description du paquet, la seule restriction sera d’ordre linguistique, étant donné que les paquets sont décrits en anglais. Donc, si vous cherchez un éditeur, invoquez la commande suivante :

$ dnf search editor

DNF vous affichera la liste de tous les paquets qui contiennent le terme editor dans leur description. Autrement, si vous recherchez un client de messagerie en mode texte, par exemple, vous pouvez le faire comme ceci :

$ dnf search mail | grep text
...
mutt.x86_64 : A text mode mail user agent

L’option list sert également à effectuer des recherches sur les paquets. Je peux étendre la recherche avec un joker :

$ dnf list vim*
...
Last metadata expiration check: 0:10:15 ago on Sat 24 Sep 2022 08:39:01 AM CEST.
Installed Packages
vim-common.x86_64      2:8.0.1763-19.el8_6.4  @appstream
vim-enhanced.x86_64    2:8.0.1763-19.el8_6.4  @appstream
vim-filesystem.noarch  2:8.0.1763-19.el8_6.4  @appstream
vim-minimal.x86_64     2:8.0.1763-19.el8_6.4  @baseos   
Available Packages
vim-X11.x86_64         2:8.0.1763-19.el8_6.4  appstream

L’option provides me permet de chercher un paquet qui contient un certain fichier :

$ dnf provides /sbin/lspci
...
pciutils-3.7.0-1.el8.x86_64 : PCI bus related utilities
Repo        : @System
Matched from:
Filename    : /sbin/lspci
...

Configuration des dépôts pour DNF

Les dépôts ou archives de téléchargement sont les endroits (sites Internet ou locaux) à partir desquels DNF télécharge les logiciels et leurs mises à jour. On pourrait également utiliser le terme plus explicite de sources de téléchargement.

L’héritage de Yum transparaît dans les noms des fichiers et des répertoires de configuration. Dans les premières versions de Yum, toute la configuration s’effectuait dans un seul fichier /etc/yum.conf. Dans les versions plus récentes, la configuration des dépôts s’écrit dans des fichiers à part, qui se trouvent dans le répertoire /etc/yum.repos.d, que DNF utilise toujours :

$ ls -1 /etc/yum.repos.d/
Rocky-AppStream.repo
Rocky-BaseOS.repo
Rocky-Debuginfo.repo
Rocky-Devel.repo
Rocky-Extras.repo
Rocky-HighAvailability.repo
Rocky-Media.repo
Rocky-NFV.repo
Rocky-Plus.repo
Rocky-PowerTools.repo
Rocky-ResilientStorage.repo
Rocky-RT.repo
Rocky-Sources.repo

Dans notre installation par défaut, /etc/yum.repos.d contient pas moins de treize fichiers .repo. L’extension .repo est une convention qui indique qu’il s’agit d’un repository, c’est-à-dire d’un dépôt.

Les dépôts officiels de la distribution

Jetons un œil dans ces différents fichiers *.repo. Ils contiennent une ou plusieurs stances qui suivent toutes le même schéma :

  • Chacune des stances commence par le nom de l’archive correspondante entre crochets : [baseos], [appstream], [extras], [powertools], etc.
  • Dans la configuration par défaut, seules les archives [baseos], [appstream] et [extras] sont activées (enabled=1), les autres sont toutes désactivées (enabled=0).
  • La ligne commençant par name contient le nom de l’archive de téléchargement.
  • La directive baseurl définit l’URL de l’archive correspondante. La configuration par défaut remplace cette source de téléchargement directe par un ou plusieurs miroirs définis par la directive mirrorlist.
  • L’option gpgcheck=1 signfie à DNF de procéder à la vérification de la signature des paquets avant l’installation, et gpgkey fournit l’emplacement de la clé GPG publique correspondante.
  • Quant aux différents paramètres comme $releasever ou $basearch, il s’agit de variables qui renseignent sur la version de Rocky Linux et sur l’architecture du processeur pour lequel le système a été compilé.

Partant de là, vous pouvez très bien parcourir l’ensemble des fichiers *.repo pour en savoir plus sur les dépôts de téléchargement en vigueur. Alternativement, utilisez l’option repolist :

$ dnf repolist
repo id          repo name
appstream        Rocky Linux 8 - AppStream
baseos           Rocky Linux 8 - BaseOS
extras           Rocky Linux 8 - Extras

Pour avoir une vague idée du nombre de paquets disponibles dans la configuration actuelle, vous pouvez utiliser l’astuce suivante :

$ dnf list all | wc -l
7175

Activer le dépôt PowerTools

Le dépôt [powertools] n’est pas activé dans la configuration par défaut, mais nous pouvons remédier à cela en éditant Rocky-PowerTools.repo :

[powertools]
name=Rocky Linux $releasever - PowerTools
...
gpgcheck=1
enabled=1
countme=1
...

Vérifiez si le dépôt apparaît bien dans la liste des dépôts configurés :

$ dnf repolist
repo id          repo name
appstream        Rocky Linux 8 - AppStream
baseos           Rocky Linux 8 - BaseOS
extras           Rocky Linux 8 - Extras
powertools       Rocky Linux 8 - PowerTools

Notez que cette petite manipulation nous a permis d’augmenter sensiblement le nombre de paquets disponibles pour notre système :

$ dnf list all | wc -l
8804

Rocky Linux, le parent pauvre des distributions ?

Un choix de près de 9000 paquets, ça paraît beaucoup, mais ça ne l’est pas tant que ça, surtout si l’on regarde du côté des distributions comme OpenSUSE, Ubuntu, Debian ou Fedora, qui en proposent jusqu’à cinq ou six fois plus. Est-ce que cela signifie que Rocky Linux est un parent pauvre et que nous aurions mieux fait de porter notre choix sur une autre distribution ? Non, pas vraiment.

Rocky Linux est un Enterprise Linux et une des particularités d’une telle distribution à usage professionnel, c’est qu’elle offre un nombre restreint de paquets tout en apportant un soin particulier à la cohérence et à la stabilité de l’ensemble.

Paquets à gogo !

Pour obtenir des applications autres que celles proposées directement par les principaux dépôts officiels de Rocky Linux, la solution consiste tout simplement à configurer l’un ou plusieurs des nombreux dépôts supplémentaires.

N’oublions pas que Red Hat Enterprise Linux – la distribution en amont de Rocky Linux – provient directement de la distribution Fedora. On peut très bien considérer que cette dernière constitue une version de développement de Red Hat Enterprise Linux qui, inversement, représente une « Fedora stabilisée », mais n’en contenant qu’un nombre limité de paquets.

Certaines sources de téléchargement – notamment le dépôt EPEL – contiennent des paquets de Fedora recompilés pour Red Hat Enterprise Linux et les clones binairement compatibles comme Rocky Linux. Ce genre de dépôt présente un avantage en même temps qu’un inconvénient.

  • Il met à disposition un nombre important de paquets mais ne préserve pas l’intégrité « entreprise » de votre système. Concrètement, l’utilisation de ce genre d’archive peux facilement multiplier par deux ou par trois le nombre de paquets disponibles pour votre système.
  • En contrepartie, l’installation de certains d’entre eux peut éventuellement forcer la mise à jour de ceux du système de base. Cela ne veut pas dire que votre système plantera, mais le système de base ultra-stable Rocky Linux en tant que clone de Red Hat Enterprise Linux contiendra désormais des composants qui n’ont pas été aussi dûment testés et qui ne bénéficient pas du même suivi.

Une solution élégante à ce dilemme consiste tout simplement à définir des priorités pour DNF. Concrètement, il suffit de configurer une source de téléchargement tierce tout en indiquant au système : attention, interdiction d’installer des paquets qui risquent de remplacer des composants du système de base. Cela a l’air compliqué en théorie mais, dans la pratique, c’est relativement simple, comme vous allez le voir tout de suite.

Protéger le système de base

Il suffit de définir une variable priority=N, avec N compris entre 1 (la plus haute) et 99 (la plus basse). Concrètement, si vous avez défini une priorité de 1 pour les dépôts [baseos], [appstream], [extras] et [powertools] et une priorité de 10 (ou 30, ou 99, peu importe) pour les dépôts tiers et/ou semi-officiels que nous verrons un peu plus loin, les paquets de ces derniers ne pourront jamais remplacer les paquets de base. DNF les en empêchera tout simplement, en les excluant de la liste.

Configurer les dépôts de paquets officiels

Éditez Rocky-BaseOS.repo et définissez une priorité maximale pour ce dépôt :

[baseos]
name=Rocky Linux $releasever - BaseOS
...
gpgcheck=1
enabled=1
priority=1
countme=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rockyofficial

Procédez de même pour les dépôts [appstream], [extras] et [powertools].

Configurer le dépôt tiers EPEL

Le dépôt tiers EPEL (Extra Packages for Enterprise Linux) fournit des paquets qui ne sont pas inclus dans la distribution Rocky Linux. Il se configure très simplement à l’aide du paquet correspondant :

$ sudo dnf install -y epel-release

Le paquet epel-release a installé une série de fichiers dans le répertoire /etc/yum.repos.d ainsi que la clé GPG du projet :

$ rpm -ql epel-release | head -n 5
/etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-8
/etc/yum.repos.d/epel-modular.repo
/etc/yum.repos.d/epel-testing-modular.repo
/etc/yum.repos.d/epel-testing.repo
/etc/yum.repos.d/epel.repo

Dans la configuration par défaut, les dépôts tiers [epel] et [epel-modular] sont activés :

$ dnf repolist
repo id          repo name
appstream        Rocky Linux 8 - AppStream
baseos           Rocky Linux 8 - BaseOS
epel             Extra Packages for Enterprise Linux 8 - x86_64
epel-modular     Extra Packages for Enterprise Linux Modular 8 - x86_64
extras           Rocky Linux 8 - Extras
powertools       Rocky Linux 8 - PowerTools

Ouvrez le fichier epel.repo et définissez les priorités du dépôt :

[epel]
name=Extra Packages for Enterprise Linux 8 - $basearch
...
enabled=1
priority=10
gpgcheck=1
countme=1
...

Procédez de même pour le dépôt [epel-modular].

Nous disposons désormais d’un choix de paquets bien plus important :

$ dnf list all | wc -l
18048

Installer un paquet RPM téléchargé avec DNF

Pour terminer cet atelier pratique, je vous montre un cas de figure que l’on rencontre de temps en temps. Dans l’exemple qui suit, je cherche à configurer le dépôt tiers Icinga qui me permet d’installer le système de supervision du même nom.

$ mkdir -v RPMS
mkdir: created directory ‘RPMS’
$ cd RPMS/
$ lynx https://packages.icinga.com/epel/

Je télécharge le paquet correspondant à ma distribution et je quitte Lynx :

$ ls
icinga-rpm-release-8-latest.noarch.rpm

Je pourrais très bien l’installer en utilisant rpm -ivh ou même rpm -Uvh. Alternativement, je peux utiliser DNF avec l’option localinstall :

$ sudo dnf localinstall icinga-rpm-release-8-latest.noarch.rpm 

Cette façon de faire présente un petit avantage. Au cas où un paquet RPM téléchargé présente des dépendances locales, dnf localinstall tentera de les résoudre automatiquement.

Petit tour d’horizon sur les gestionnaires de paquets

Les outils de gestion des paquets constituent un point de distinction assez important entre les différentes distributions Linux. Le simple format des paquets permet d’organiser la majorité des distributions en grandes familles :

  • paquets au format .rpm : Rocky Linux, Red Hat Enterprise Linux, Fedora, SUSE et OpenSUSE
  • paquets au format .deb : Debian et Ubuntu
  • paquets au format .tgz et .txz : Slackware
  • etc.

Cette liste est loin d’être exhaustive, étant donné que la communauté Linux respecte la Grande Charte Anarchiste du Troupeau de Chats et développe régulièrement de nouvelles distributions avec des gestionnaires de paquets encore plus révolutionnaires et surtout incompatibles entre eux.

Chaque format de paquets dispose de son propre gestionnaire à la base, ce qui signifie que vous pourrez utiliser RPM pour gérer les paquets de n’importe laquelle des distributions basée sur ce format, du moins manuellement. Les différences se situeront au niveau des frontaux plus confortables :

  • Fedora, Red Hat Enterprise Linux et Rocky Linux gèrent les dépendances avec DNF.
  • SUSE et OpenSUSE utilisent Zypper en plus de RPM.
  • Les distributions de la famille Debian et dérivées gèrent leurs paquets au format .deb avec l’utilitaire dpkg et des frontaux en ligne de commande puissants et flexibles comme APT et Aptitude.

AstuceCe foisonnement d’outils a de quoi décourager les utilisateurs nouveaux venus. Mon conseil : n’essayez pas d’apprendre trop de choses à la fois. Explorez DNF et RPM et les possibilités qu’ils offrent. Une fois que vous aurez saisi leurs principes de fonctionnement et que vous les manierez avec le sourire, l’apprentissage d’un autre gestionnaire de paquets comme APT ne vous fera plus peur. Le fonctionnement de base est exactement le même. Ce n’est que la syntaxe des commandes qui change.

 

Lire la suite : En cours de rédaction


La rédaction de cette documentation demande du temps et des quantités significatives de café espresso. Vous appréciez ce blog ? Offrez un café au rédacteur en cliquant sur la tasse.

 

Catégories : Formation

0 commentaire

Laisser un commentaire

Avatar placeholder

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