Objectif 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.
DNF 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
quotacomme prévu, de même que la dépendance requisequota-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.
GNU 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.
Une 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.
Chaque 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
namecontient le nom de l’archive de téléchargement. - La directive
baseurldé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 directivemirrorlist. - L’option
gpgcheck=1signfie à DNF de procéder à la vérification de la signature des paquets avant l’installation, etgpgkeyfournit l’emplacement de la clé GPG publique correspondante. - Quant aux différents paramètres comme
$releaseverou$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
.tgzet.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
.debavec l’utilitairedpkget des frontaux en ligne de commande puissants et flexibles comme APT et Aptitude.
Ce 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 : Premiers pas sur le réseau
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.
0 commentaire