L'évolution des gestionnaires de paquets

Chaque appareil informatisé utilise une forme de logiciel pour effectuer les tâches prévues. Au début des logiciels, les produits étaient rigoureusement testés pour détecter les bogues et autres défauts. Au cours de la dernière décennie environ, des logiciels ont été publiés via Internet dans le but de corriger tout bogue en appliquant de nouvelles versions du logiciel. Dans certains cas, chaque application individuelle a son propre programme de mise à jour. Dans d'autres, c'est à l'utilisateur de déterminer comment obtenir et mettre à jour le logiciel.

Linux a adopté très tôt la pratique consistant à maintenir un emplacement centralisé où les utilisateurs pouvaient trouver et installer des logiciels. Dans cet article, je vais discuter de l'historique de l'installation de logiciels sur Linux et de la façon dont les systèmes d'exploitation modernes sont tenus à jour contre le torrent incessant de CVE.

Comment les logiciels sous Linux étaient-ils installés avant les gestionnaires de packages ?

Historiquement, les logiciels étaient fournis via FTP ou des listes de diffusion (éventuellement, cette distribution se développerait pour inclure des sites Web de base). Seuls quelques petits fichiers contenaient les instructions pour créer un binaire (normalement dans un fichier tar). Vous décompressez les fichiers, lisez le fichier readme, et tant que vous avez GCC ou une autre forme de compilateur C, vous exécutez alors généralement un ./configure script avec une liste d'attributs, tels que le chemin d'accès aux fichiers de bibliothèque, l'emplacement pour créer de nouveaux fichiers binaires, etc. De plus, le configure processus vérifierait votre système pour les dépendances d'application. Si des exigences majeures manquaient, le script de configuration se fermait et vous ne pouviez pas poursuivre l'installation tant que toutes les dépendances n'étaient pas satisfaites. Si le script de configuration s'est terminé avec succès, un Makefile serait créé.

Une fois un Makefile existait, vous procéderiez alors à l'exécution du make commande (cette commande est fournie par le compilateur que vous utilisiez). Le make La commande a un certain nombre d'options appelées make flags , qui aident à optimiser les fichiers binaires résultants pour votre système. Au début de l'informatique, c'était très important car le matériel avait du mal à suivre les exigences des logiciels modernes. Aujourd'hui, les options de compilation peuvent être beaucoup plus génériques car la plupart du matériel est plus que suffisant pour les logiciels modernes.

Enfin, après le make le processus était terminé, vous auriez besoin d'exécuter make install (ou sudo make install ) afin d'installer réellement le logiciel. Comme vous pouvez l'imaginer, faire cela pour chaque logiciel était long et fastidieux, sans parler du fait que la mise à jour du logiciel était un processus compliqué et potentiellement très complexe.

Qu'est-ce qu'un forfait ?

Les packages ont été inventés pour lutter contre cette complexité. Les packages rassemblent plusieurs fichiers de données dans un seul fichier d'archive pour une portabilité et un stockage plus faciles, ou compressent simplement les fichiers pour réduire l'espace de stockage. Les binaires inclus dans un package sont précompilés selon les valeurs par défaut du développeur choisi. Les packages contiennent également des métadonnées, telles que le nom du logiciel, une description de son objectif, un numéro de version et une liste des dépendances nécessaires au bon fonctionnement du logiciel.

Plusieurs versions de Linux ont créé leurs propres formats de packages. Certains des formats de package les plus couramment utilisés incluent :

.deb :ce format de package est utilisé par Debian, Ubuntu, Linux Mint et plusieurs autres dérivés. C'était le premier type de package à être créé.
.rpm :ce format de package s'appelait à l'origine Red Hat Package Manager. Il est utilisé par Red Hat, Fedora, SUSE et plusieurs autres petites distributions.
.tar.xz :bien qu'il ne s'agisse que d'une archive compressée, c'est le format utilisé par Arch Linux.

Bien que les packages eux-mêmes ne gèrent pas directement les dépendances, ils ont représenté un énorme pas en avant dans la gestion des logiciels Linux.

Qu'est-ce qu'un référentiel de logiciels ?

Il y a quelques années, avant la prolifération des smartphones, l'idée d'un référentiel de logiciels était difficile à saisir pour de nombreux utilisateurs s'ils n'étaient pas impliqués dans l'écosystème Linux. À ce jour, la plupart des utilisateurs de Windows semblent toujours être câblés pour ouvrir un navigateur Web afin de rechercher et d'installer de nouveaux logiciels. Cependant, ceux qui ont des smartphones se sont habitués à l'idée d'un "magasin" de logiciels. La façon dont les utilisateurs de smartphones obtiennent des logiciels et la façon dont les gestionnaires de packages fonctionnent ne sont pas différentes. Bien qu'il y ait eu plusieurs tentatives pour créer une interface utilisateur attrayante pour les référentiels de logiciels, la grande majorité des utilisateurs de Linux utilisent toujours la ligne de commande pour installer des packages. Les référentiels de logiciels sont une liste centralisée de tous les logiciels disponibles pour tout référentiel que le système a été configuré pour utiliser. Vous trouverez ci-dessous quelques exemples de recherche dans un référentiel pour un package spécifique (notez qu'ils ont été tronqués par souci de brièveté) :

Arch Linux avec aurman

user@arch ~ $  aurman -Ss kate

extra/kate 18.04.2-2 (kde-applications kdebase)
   Éditeur de texte avancé
aur/kate-root 18.04.0-1 (11, 1.139399)
   Éditeur de texte avancé, corrigé pour pouvoir s'exécuter en tant que root
aur/kate-git r15288.15d26a7-1 (1, 1e-06)
    Un composant d'édition avancé qui est utilisé dans de nombreuses applications KDE nécessitant un composant d'édition de texte

CentOS 7 utilisant YUM

[user@centos ~]$ yum search kate

kate-devel.x86_64 :Fichiers de développement pour kate
kate-libs.x86_64 :Fichiers d'exécution pour kate
kate -part.x86_64 :Plug-in Kate kpart

Ubuntu utilisant APT

user@ubuntu ~ $ apt search kate
Tri... Terminé
Recherche plein texte... Terminé

kate/xenial 4:15.12.3-0ubuntu2 amd64 
 éditeur de texte puissant

kate-data/xenial,xenial 4:4.14.3-0ubuntu4 all
 fichiers de données partagés pour l'éditeur de texte Kate

kate -dbg/xenial 4:15.12.3-0ubuntu2 amd64
  symboles de débogage pour Kate

kate5-data/xenial,xenial 4:15.12.3-0ubuntu2 all
  fichiers de données partagés pour l'éditeur de texte Kate

Quels sont les gestionnaires de packages les plus connus ?

Comme suggéré dans la sortie ci-dessus, les gestionnaires de packages sont utilisés pour interagir avec les référentiels de logiciels. Voici un bref aperçu de certains des gestionnaires de packages les plus importants.

Gestionnaires de packages basés sur RPM

La mise à jour des systèmes basés sur RPM, en particulier ceux basés sur les technologies Red Hat, a un historique très intéressant et détaillé. En fait, les versions actuelles de yum (pour les distributions d'entreprise) et DNF (pour la communauté) combinent plusieurs projets open source pour fournir leurs fonctionnalités actuelles.

Initialement, Red Hat utilisait un gestionnaire de packages appelé RPM (Red Hat Package Manager), qui est toujours utilisé aujourd'hui. Cependant, son utilisation principale est d'installer des RPM, que vous avez localement, et non de rechercher des référentiels de logiciels. Le gestionnaire de paquets nommé up2date a été créé pour informer les utilisateurs des mises à jour des packages et leur permettre de rechercher des référentiels distants et d'installer facilement des dépendances. Bien qu'il remplisse son objectif, certains membres de la communauté ont estimé que up2date présentait des lacunes importantes.

L'incantation actuelle de yum provient de plusieurs efforts communautaires différents. Yellowdog Updater (YUP) a été développé en 1999-2001 par des gens de Terra Soft Solutions en tant que moteur principal pour un installateur graphique de Yellow Dog Linux. Duke University a aimé l'idée de YUP et a décidé de l'améliorer. Ils ont créé Yellowdog Updater, Modified (yum) qui a finalement été adapté pour aider à gérer les systèmes Red Hat Linux de l'université. Yum a gagné en popularité et, en 2005, on estimait qu'il était utilisé par plus de la moitié du marché Linux. Aujourd'hui, presque toutes les distributions de Linux qui utilisent des RPM utilisent yum pour la gestion des packages (à quelques exceptions notables près).

Travailler avec yum

Pour que yum puisse télécharger et installer des packages à partir d'un référentiel Internet, les fichiers doivent se trouver dans /etc/yum.repos.d/ et ils doivent avoir l'extension .repo . Voici un exemple de fichier de dépôt :

[local_base]
name=Base CentOS (local)
baseurl=http://7-repo.apps.home.local/yum-repo/7/
enabled=1 
gpgcheck=0

C'est pour l'un de mes référentiels locaux, ce qui explique pourquoi la vérification GPG est désactivée. Si cette vérification était activée, chaque paquet devrait être signé avec une clé cryptographique et une clé correspondante devrait être importée dans le système recevant les mises à jour. Étant donné que je maintiens moi-même ce référentiel, je fais confiance aux packages et ne prends pas la peine de les signer.

Une fois qu'un fichier de référentiel est en place, vous pouvez commencer à installer des packages à partir du référentiel distant. La commande la plus basique est yum update , qui mettra à jour chaque paquet actuellement installé. Cela ne fait pas exiger une étape spécifique pour rafraîchir les informations sur les référentiels ; cela se fait automatiquement. Un exemple de la commande est illustré ci-dessous :

[user@centos ~]$ sudo yum update
Plug-ins chargés : fastmirror, product-id, search-disabled-repos, subscription-manager
local_base                             | 3,6 Ko  00:00:00     
local_epel                             | 2,9 Ko  00:00:00     
local_rpm_forge                        | 1,9 Ko  00:00:00     
local_updates                          | 3,4 Ko  00:00:00     
spideroak-one-stable                   | 2,9 Ko  00:00:00     
zfs                                    | 2,9 Ko  00:00:00     
(1/6) :local_base/group_gz             | 166 Ko  00:00:00     
(2/6) :local_updates/primary_db        | 2,7 Mo  00:00:00     
(3/6) :local_base/primary_db           | 5,9 Mo  00:00:00     
(4/6) :spideroak-one-stable/primary_db | 12 Ko  00:00:00     
(5/6) :local_epel/primary_db           | 6,3 Mo  00:00:00     
(6/6) :zfs/x86_64/primary_db           | 78 Ko  00:00:00     
local_rpm_forge/primary_db             | 125 Ko  00:00:00     
Déterminer les miroirs les plus rapides
Résoudre les dépendances
--> Exécuter la vérification des transactions

Si vous êtes sûr de vouloir que yum exécute n'importe quelle commande sans s'arrêter pour la saisie, vous pouvez mettre le -y drapeau dans la commande, tel que yum update -y .

L'installation d'un nouveau package est tout aussi simple. Tout d'abord, recherchez le nom du package avec yum search :

[user@centos ~]$ yum search kate

artwiz-aleczapka-kates-fonts.noarch :police Kates dans la famille Artwiz
ghc-highlighting-kate-devel.x86_64 :Fichiers de développement de la bibliothèque Haskell Highlighting-Kate br />kate-libs.x86_64 :Fichiers d'exécution pour kate
kate-part.i686 :Plugin Kate kpart

Une fois que vous avez le nom du package, vous pouvez simplement installer le package avec sudo yum install kate-devel -y . Si vous avez installé un paquet dont vous n'avez plus besoin, vous pouvez le supprimer avec sudo yum remove kate-devel -y . Par défaut, yum supprimera le package ainsi que ses dépendances.

Il peut arriver que vous ne connaissiez pas le nom du package, mais que vous connaissiez le nom de l'utilitaire. Par exemple, supposons que vous recherchiez l'utilitaire updatedb , qui crée/met à jour la base de données utilisée par le locate commande. Tentative d'installation de updatedb renvoie les résultats suivants :

[user@centos ~]$ sudo yum install updatedb
Plug-ins chargés :le plus rapide miroir, langpacks
Chargement des vitesses de miroir à partir du fichier hôte mis en cache
Aucun paquet mis à jourb disponible.
Erreur :rien faire

Vous pouvez savoir de quel package provient l'utilitaire en exécutant :

[user@centos ~]$ yum whatprovides *updatedb
Plug-ins chargés :le plus rapide miroir, langpacks
Chargement des vitesses de miroir à partir du fichier hôte mis en cache

bacula-director-5.2.13- 23.1.el7.x86_64 : fichiers Bacula Director
Repo :local_base
Matched from :
Filename /usr/share/doc/bacula-director-5.2.13/updatedb

mlocate-0.26-8.el7.x86_64 : un utilitaire pour rechercher des fichiers par nom

La raison pour laquelle j'ai utilisé un astérisque * devant la commande est parce que yum whatprovides utilise le chemin d'accès au fichier afin de faire une correspondance. Comme je n'étais pas sûr de l'emplacement du fichier, j'ai utilisé un astérisque pour indiquer n'importe quel chemin.

Il y a, bien sûr, beaucoup plus d'options disponibles pour yum. Je vous encourage à consulter la page de manuel de yum pour des options supplémentaires.

Dandified Yum (DNF) est une version plus récente de yum. Introduit dans Fedora 18, il n'a pas encore été adopté dans les distributions d'entreprise et, en tant que tel, est principalement utilisé dans Fedora (et ses dérivés). Son utilisation est presque exactement la même que celle de yum, mais il a été conçu pour résoudre les problèmes de performances médiocres, les API non documentées, la résolution des dépendances lentes/cassées et l'utilisation occasionnelle élevée de la mémoire. DNF est conçu comme un remplacement direct pour yum, et donc je ne répéterai pas les commandes - partout où vous utiliseriez yum , remplacez simplement dnf .

Travailler avec Zypper

Zypper est un autre gestionnaire de paquets destiné à aider à gérer les RPM. Ce gestionnaire de packages est le plus souvent associé à SUSE (et openSUSE), mais a également été adopté par MeeGo, Sailfish OS et Tizen. Il a été initialement introduit en 2006 et a été réitéré depuis. Il n'y a pas grand-chose à dire si ce n'est que Zypper est utilisé comme back-end pour l'outil d'administration système YaST et certains utilisateurs le trouvent plus rapide que yum.

L'utilisation de Zypper est très similaire à celle de yum. Pour rechercher, mettre à jour, installer ou supprimer un package, utilisez simplement ce qui suit :

zypper search kate
zypper update
zypper install kate
zypper remove kate

Certaines différences majeures entrent en jeu dans la façon dont les référentiels sont ajoutés au système avec zypper . Contrairement aux gestionnaires de paquets discutés ci-dessus, zypper ajoute des référentiels à l'aide du gestionnaire de packages lui-même. Le moyen le plus courant est via une URL, mais zypper prend également en charge l'importation à partir de fichiers de dépôt.

suse :~ # zypper addrepo http://download.videolan.org/pub/vlc/SuSE/15.0 vlc
Ajout du référentiel 'vlc' [terminé]
Le référentiel 'vlc' a été ajouté avec succès

Activé     :Oui
Actualisation automatique :Non
Vérification GPG   :Oui
URI         :http://download.videolan.org/pub/vlc/SuSE/15.0
Priorité   :99

Vous supprimez des référentiels de la même manière :

suse :~ # zypper removerepo vlc
Suppression du référentiel 'vlc' ............................... ....[done]
Le référentiel 'vlc' a été supprimé.

Utiliser les zypper repos pour voir quel est l'état des référentiels sur votre système :

suse :~ # zypper repos
Les priorités du dépôt sont sans effet. Tous les référentiels activés partagent la même priorité.

#  | Alias                     | Nom                                    | Activé | Vérification GPG | Actualiser
---+---------------------------+---------------------- ----------------------------+---------+----------- +--------
 1 | dépôt-débogage                | openSUSE-Leap-15.0-Debug                | Non      | ----      | ----   
 2 | repo-debug-non-oss        | openSUSE-Leap-15.0-Debug-Non-Oss        | Non      | ----      | ----   
 3 | dépôt-débogage-mise à jour         | openSUSE-Leap-15.0-Update-Debug         | Non      | ----      | ----   
 4 | repo-debug-update-non-oss | openSUSE-Leap-15.0-Mise à jour-Debug-Non-Oss | Non      | ----      | ----   
 5 | repo-non-oss              | openSUSE-Leap-15.0-Non-Oss              | Oui     | ( p) Oui  | Oui    
 6 | repo-oss                  | openSUSE-Leap-15.0-Oss                  | Oui     | ( p) Oui  | Oui

zypper a même une capacité similaire à déterminer quel nom de package contient des fichiers ou des binaires. Contrairement à YUM, il utilise un trait d'union dans la commande (bien que cette méthode de recherche soit obsolète) :

localhost :~ # zypper what-provides kate
La commande 'what-provides' est remplacée par 'search --provides --match-exact'.
Voir 'help search' pour toutes les options disponibles .
Chargement des données du référentiel...
Lecture des packages installés...

S  | Nom | Résumé              | Saisissez       
---+------+----------------------+----------- -
i+ | Kate | Éditeur de texte avancé | application
je  | kate | Éditeur de texte avancé | forfait

Comme avec YUM et DNF, Zypper a un ensemble de fonctionnalités beaucoup plus riche que celui couvert ici. Veuillez consulter la documentation officielle pour des informations plus détaillées.

Gestionnaires de paquets basés sur Debian

L'une des plus anciennes distributions Linux actuellement maintenues, le système de Debian est très similaire aux systèmes basés sur RPM. Ils utilisent .deb packages, qui peuvent être gérés par un outil appelé dpkg . dpkg est très similaire à rpm en ce qu' il a été conçu pour gérer des packages disponibles localement. Il ne résout pas les dépendances (bien qu'il vérifie les dépendances) et n'a aucun moyen fiable d'interagir avec les référentiels distants. Afin d'améliorer l'expérience utilisateur et la facilité d'utilisation, le projet Debian a commandé un projet appelé Deity . Ce nom de code a finalement été abandonné et remplacé par Advanced Package Tool (APT).

Sorti sous forme de versions de test en 1998 (avant de faire son apparition dans Debian 2.1 en 1999), de nombreux utilisateurs considèrent APT comme l'une des caractéristiques déterminantes des systèmes basés sur Debian. Il utilise des référentiels de la même manière que les systèmes basés sur RPM, mais au lieu de .repo individuels fichiers qui yum utilise, apt a historiquement utilisé /etc/apt/sources.list pour gérer les dépôts. Plus récemment, il ingère également des fichiers de /etc/apt/sources.d/ . En suivant les exemples des gestionnaires de paquets basés sur RPM, pour accomplir la même chose sur les distributions basées sur Debian, vous avez quelques options. Vous pouvez modifier/créer les fichiers manuellement dans les emplacements susmentionnés à partir du terminal ou, dans certains cas, vous pouvez utiliser une interface utilisateur (telle que Software & Updates fourni par Ubuntu et al.). Pour fournir le même traitement à toutes les distributions, je ne couvrirai que les options de ligne de commande. Pour ajouter un référentiel sans modifier directement un fichier, vous pouvez faire quelque chose comme ceci :

user@ubuntu:~$ sudo apt-add-repository "deb http://APT.spideroak.com/ubuntu-spideroak-hardy/ release restricted"

Cela créera un spideroakone.list fichier dans /etc/apt/sources.list.d . Évidemment, ces lignes changent en fonction du référentiel ajouté. Si vous ajoutez une archive personnelle de paquets (PPA), vous pouvez le faire :

user@ubuntu:~$ sudo apt-add-repository ppa:gnome-desktop

REMARQUE : Debian ne prend pas en charge les PPA de manière native.

Une fois qu'un référentiel a été ajouté, les systèmes basés sur Debian doivent être informés qu'il existe un nouvel emplacement pour rechercher des paquets. Cela se fait via le apt-get update commande :

user@ubuntu :~$ sudo apt-get update
Obtenir :1 http://security.ubuntu.com/ubuntu xenial-security InRelease [107 ko]
Hit :2 http:/ /APT.spideroak.com/ubuntu-spideroak-hardy release InRelease
Hit :3 http://ca.archive.ubuntu.com/ubuntu xenial InRelease
Get :4 http://ca.archive .ubuntu.com/ubuntu xenial-updates InRelease [109 ko]              
Obtenez :5 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages [517 ko]
Obtenez :6 http://security.ubuntu.com/ubuntu xenial-security/main i386 Packages [455 ko]      
Obtenez :7 http://security.ubuntu.com/ubuntu xenial-security/main Translation-en [221 Ko]     
...

Récupération de 6 399 Ko en 3 secondes (2 017 Ko/s)                                           
Lecture des listes de packages... Terminé

Maintenant que le nouveau dépôt est ajouté et mis à jour, vous pouvez rechercher un paquet en utilisant apt-cache commande :

user@ubuntu :~$ apt-cache search kate
aterm-ml - Afterstep XVT - un émulateur VT102 pour le système X window
frescobaldi - Éditeur de partition Qt4 LilyPond
gitit - Moteur Wiki soutenu par un magasin de fichiers git ou darcs
jedit - Éditeur basé sur un plugin pour les programmeurs
kate - éditeur de texte puissant
kate-data - fichiers de données partagés pour l'éditeur de texte Kate
kate -dbg - symboles de débogage pour Kate
katepart - composant d'éditeur de texte intégrable

Pour installer kate , exécutez simplement la commande d'installation correspondante :

user@ubuntu:~$ sudo apt-get install kate

Pour supprimer un paquet, utilisez apt-get remove :

user@ubuntu:~$ sudo apt-get remove kate

En ce qui concerne la découverte de packages, APT ne fournit aucune fonctionnalité similaire à yum whatprovides . Il existe plusieurs façons d'obtenir ces informations si vous essayez de trouver l'origine d'un fichier spécifique sur le disque.

Utiliser dpkg

user@ubuntu :~$ dpkg -S /bin/ls
coreutils :/bin/ls

Utiliser le fichier apt

user@ubuntu :~$ sudo apt-get install apt-file -y 

user@ubuntu :~$ sudo apt-file update

user@ubuntu :~$ apt-file search kate

Le problème avec la apt-file search c'est ça, contrairement à yum whatprovides , il est trop verbeux à moins que vous ne connaissiez le chemin exact, et il ajoute automatiquement une recherche générique afin que vous obteniez des résultats pour tout ce qui contient le mot kate dedans :

kate :/usr/bin/kate
kate :/usr/lib/x86_64-linux-gnu/qt5/plugins/ktexteditor/katebacktracebrowserplugin.so
kate :/usr/lib/x86_64- linux-gnu/qt5/plugins/ktexteditor/katebuildplugin.so
kate :/usr/lib/x86_64-linux-gnu/qt5/plugins/ktexteditor/katecloseexceptplugin.so
kate :/usr/lib/ x86_64-linux-gnu/qt5/plugins/ktexteditor/katectagsplugin.so

La plupart de ces exemples ont utilisé apt-get . Notez que la plupart des tutoriels actuels pour Ubuntu ont spécifiquement utilisé simplement apt . Le seul apt La commande a été conçue pour implémenter uniquement les commandes les plus couramment utilisées dans l'arsenal APT. Puisque la fonctionnalité est divisée entre apt-get , apt-cache , et d'autres commandes, apt cherche à les unifier en une seule commande. Il ajoute également quelques subtilités telles que la colorisation, les barres de progression et d'autres bric et de broc. La plupart des commandes notées ci-dessus peuvent être remplacées par apt , mais pas toutes les distributions basées sur Debian qui reçoivent actuellement la prise en charge des correctifs de sécurité à l'aide de apt par défaut, vous devrez peut-être installer des packages supplémentaires.

Gestionnaires de packages basés sur Arch

Arch Linux utilise un gestionnaire de packages appelé pacman. Contrairement à .deb ou .rpm fichiers, pacman utilise une archive tar plus traditionnelle avec le LZMA2 compression (.tar.xz ). Cela permet aux packages Arch Linux d'être beaucoup plus petits que d'autres formes d'archives compressées (telles que gzip ). Initialement publié en 2002, pacman a été régulièrement itéré et amélioré. L'un des principaux avantages de pacman est qu'il prend en charge Arch Build System, un système permettant de créer des packages à partir de la source. Le système de construction ingère un fichier appelé PKGBUILD, qui contient des métadonnées (telles que les numéros de version, les révisions, les dépendances, etc.) ainsi qu'un script shell avec les indicateurs requis pour compiler un package conforme aux exigences d'Arch Linux. Les binaires résultants sont ensuite empaquetés dans le .tar.xz susmentionné fichier à consommer par pacman.

Ce système a conduit à la création de l'Arch User Repository (AUR), qui est un référentiel communautaire contenant des fichiers PKGBUILD et des correctifs ou des scripts de support. Cela permet à une quantité pratiquement infinie de logiciels d'être disponibles dans Arch. L'avantage évident de ce système est que si un utilisateur (ou un mainteneur) souhaite mettre un logiciel à la disposition du public, il n'a pas à passer par les canaux officiels pour le faire accepter dans les principaux référentiels. L'inconvénient est qu'il s'appuie sur une curation communautaire similaire à Docker Hub, aux packages Snap de Canonical ou à d'autres mécanismes similaires. Il existe de nombreux gestionnaires de packages spécifiques à AUR qui peuvent être utilisés pour télécharger, compiler et installer à partir des fichiers PKGBUILD dans l'AUR (nous verrons cela plus tard).

Travailler avec pacman et les dépôts officiels

Le gestionnaire de paquets principal d'Arch, pacman, utilise des drapeaux au lieu de mots de commande comme yum et apt . Par exemple, pour rechercher un package, vous utiliserez pacman -Ss . Comme avec la plupart des commandes sous Linux, vous pouvez trouver à la fois une manpage et l'aide en ligne. La plupart des commandes pour pacman utilisez la synchronisation (-S) drapeau. Par exemple :

user@arch ~ $ pacman -Ss kate

extra/kate 18.04.2-2 (kde-applications kdebase)
    Éditeur de texte avancé
extra/libkate 0.4. 1-6 [installé]
    Un codec de karaoké et de texte pour l'intégration dans ogg
extra/libtiger 0.3.4-5 [installé]
     Une bibliothèque de rendu pour les flux Kate utilisant Pango et Cairo
extra/ttf-cheapskate 2.0-12
    Collection TTFonts de dustimo.com
community/haskell-cheapskate 0.1.1-100
     Processeur de démarquage expérimental.

Arch utilise également des référentiels similaires à d'autres gestionnaires de packages. Dans la sortie ci-dessus, les résultats de la recherche sont précédés du référentiel dans lequel ils se trouvent (extra/ et community/ dans ce cas). Semblable aux systèmes basés sur Red Hat et Debian, Arch s'appuie sur l'utilisateur pour ajouter les informations du référentiel dans un fichier spécifique. L'emplacement de ces référentiels est /etc/pacman.conf . L'exemple ci-dessous est assez proche d'un système de stock. J'ai activé le [multilib] référentiel pour le support Steam :

[options]
Architecture =auto

Couleur
CheckSpace

SigLevel    =Obligatoire DatabaseFacultatif
LocalFileSigLevel =Facultatif
 
[core]
Include =/etc/pacman.d/mirrorlist

[extra]
Include =/etc/pacman.d/mirrorlist
 
[communauté]
Include =/etc/pacman.d/mirrorlist

[multilib]
Include =/etc/pacman.d/mirrorlist

Il est possible de spécifier une URL spécifique dans pacman.conf . Cette fonctionnalité peut être utilisée pour s'assurer que tous les packages proviennent d'un moment précis. Si, par exemple, un paquet a un bogue qui vous affecte gravement et qu'il a plusieurs dépendances, vous pouvez revenir à un moment précis en ajoutant une URL spécifique dans votre pacman.conf puis exécutez les commandes pour rétrograder le système :

[core]
Server=https://archive.archlinux.org/repos/2017/12/22/$repo/os/$arch

Comme les systèmes basés sur Debian, Arch ne met pas à jour les informations de son référentiel local tant que vous ne lui avez pas demandé de le faire. Vous pouvez actualiser la base de données de packages en exécutant la commande suivante :

user@arch ~ $ sudo pacman -Sy 

 :Synchronisation des bases de données de packages...
 core                                                                                                                                                                                                                                   851K/s 0 ################################################# ] 100 %
 supplément                                                                                                                                   1645.3 KiB  2.69M/s 00:01 [####################### #########################] 100 %
 communauté                                                              2,27 Mio/s 00:02 [#### ################################################# ##] 100 %
 multilib est à jour

Comme vous pouvez le voir dans le résultat ci-dessus, pacman pense que la base de données du package multilib est à jour. Vous pouvez forcer une actualisation si vous pensez que cela est incorrect en exécutant pacman -Syy . Si vous souhaitez mettre à jour l'intégralité de votre système (à l'exception des packages installés à partir de l'AUR), vous pouvez exécuter pacman -Syu :

user@arch ~ $ sudo pacman -Syu

 : Synchronisation des bases de données de packages...
 core est à jour
 extra est à jour
 community est à jour
 multilib est à jour
 : Démarrage de la mise à niveau complète du système...
résolution des dépendances...
recherche des paquets en conflit...

Paquets (45) ceph-13.2.0-2  ceph-libs-13.2.0-2  debootstrap-1.0.105-1  guile-2.2.4-1  harfbuzz-1.8.2-1  harfbuzz-icu- 1.8.2-1  haskell-aeson-1.3.1.1-20
              haskell-attoparsec-0.13.2.2-24  haskell-tagged-0.8.6-1  imagemagick-7.0.8.4-1  lib32-harfbuzz-1.8.2 -1  lib32-libgusb-0.3.0-1  lib32-systemd-239.0-1
              libgit2-1:0.27.2-1  libinput-1.11.2-1  libmagick-7.0.8.4-1  libmagick6-6.9.10.4 -1  libopenshot-0.2.0-1  libopenshot-audio-0.1.6-1  libosinfo-1.2.0-1
              libxfce4util-4.13.2-1  minetest-0.4.17.1-1  minetest-common-0.4.17.1 -1  mlt-6.10.0-1  mlt-python-bindings-6.10.0-1  ndctl-61.1-1  netctl-1.17-1
              nodejs-10.6.0 -1  

Taille totale de téléchargement :     2,66 Mio
Taille totale installée :  879,15 Mio
Taille nette de mise à niveau :     -365,27 Mio

 : Poursuivre l'installation ? [O/n]

Dans le scénario mentionné précédemment concernant la rétrogradation d'un système, vous pouvez forcer une rétrogradation en émettant pacman -Syyuu . Il est important de noter que cela ne doit pas être entrepris à la légère. Cela ne devrait pas poser de problème dans la plupart des cas; cependant, il est possible que la rétrogradation d'un package ou de plusieurs packages provoque une défaillance en cascade et laisse votre système dans un état incohérent. À UTILISER AVEC PRUDENCE !

Pour installer un package, utilisez simplement pacman -S kate :

user@arch ~ $ sudo pacman -S kate

résolution des dépendances...
recherche de packages en conflit...

Packages (7) editorconfig -core-c-0.12.2-1  kactivities-5.47.0-1  kparts-5.47.0-1  ktexteditor-5.47.0-2  syntax-highlighting-5.47.0-1  threadweaver-5.47.0-1
             kate-18.04.2-2

Taille totale de téléchargement :  10,94 Mio
Taille totale installée : 38,91 Mio

 : :Continuer l'installation ? [O/n]

Pour supprimer un paquet, vous pouvez exécuter pacman -R kate . Cela supprime uniquement le package et non ses dépendances :

user@arch ~ $ sudo pacman -S kate

vérification des dépendances...

Packages (1) kate-18.04.2-2

Taille totale supprimée : 20,30 Mio

 : Voulez-vous supprimer ces packages ? [O/n]

Si vous souhaitez supprimer les dépendances qui ne sont pas requis par d'autres packages, vous pouvez exécuter pacman -Rs:

user@arch ~ $ sudo pacman -Rs kate

vérification des dépendances...

Paquets (7) editorconfig-core-c-0.12.2-1  kactivities -5.47.0-1  kparts-5.47.0-1  ktexteditor-5.47.0-2  syntax-highlighting-5.47.0-1  threadweaver-5.47.0-1
             kate-18.04.2-2

Total Removed Size: 38.91 MiB

::Do you want to remove these packages? [Y/n]

Pacman, in my opinion, offers the most succinct way of searching for the name of a package for a given utility. As shown above, yum et apt both rely on pathing in order to find useful results. Pacman makes some intelligent guesses as to which package you are most likely looking for:

user@arch ~ $ sudo pacman -Fs updatedb
core/mlocate 0.26.git.20170220-1
    usr/bin/updatedb

user@arch ~ $ sudo pacman -Fs kate
extra/kate 18.04.2-2
    usr/bin/kate

Working with the AUR

There are several popular AUR package manager helpers. Of these, yaourt and pacaur are fairly prolific. However, both projects are listed as discontinued or problematic on the Arch Wiki. For that reason, I will discuss aurman . It works almost exactly like pacman, except it searches the AUR and includes some helpful, albeit potentially dangerous, options. Installing a package from the AUR will initiate use of the package maintainer's build scripts. You will be prompted several times for permission to continue (I have truncated the output for brevity):

aurman -S telegram-desktop-bin
~~ initializing aurman...
~~ the following packages are neither in known repos nor in the aur
...
~~ calculating solutions...

::The following 1 package(s) are getting updated:
   aur/telegram-desktop-bin  1.3.0-1  ->  1.3.9-1

?? Do you want to continue? Y/n:Y

~~ looking for new pkgbuilds and fetching them...
Cloning into 'telegram-desktop-bin'...

remote:Counting objects:301, done.
remote:Compressing objects:100% (152/152), done.
remote:Total 301 (delta 161), reused 286 (delta 147)
Receiving objects:100% (301/301), 76.17 KiB | 639.00 KiB/s, done.
Resolving deltas:100% (161/161), done.
?? Do you want to see the changes of telegram-desktop-bin? N/y:N

[sudo] password for user:

...
==> Leaving fakeroot environment.
==> Finished making:telegram-desktop-bin 1.3.9-1 (Thu 05 Jul 2018 11:22:02 AM EDT)
==> Cleaning up...
loading packages...
resolving dependencies...
looking for conflicting packages...

Packages (1) telegram-desktop-bin-1.3.9-1

Total Installed Size: 88.81 MiB
Net Upgrade Size:      5.33 MiB

::Proceed with installation? [Y/n]

Sometimes you will be prompted for more input, depending on the complexity of the package you are installing. To avoid this tedium, aurman allows you to pass both the --noconfirm and --noedit options. This is equivalent to saying "accept all of the defaults, and trust that the package maintainers scripts will not be malicious." USE THIS OPTION WITH EXTREME CAUTION! While these options are unlikely to break your system on their own, you should never blindly accept someone else's scripts.

Conclusion

This article, of course, only scratches the surface of what package managers can do. There are also many other package managers available that I could not cover in this space. Some distributions, such as Ubuntu or Elementary OS, have gone to great lengths to provide a graphical approach to package management.

If you are interested in some of the more advanced functions of package managers, please post your questions or comments below and I would be glad to write a follow-up article.

Appendix

# search for packages
yum search 
dnf search 
zypper search 
apt-cache search 
apt search 
pacman -Ss 

# install packages
yum install 
dnf install 
zypper install 
apt-get install 
apt install 
pacman -S 

# update package database, not required by yum, dnf and zypper
apt-get update
apt update
pacman -Sy

# update all system packages
yum update
dnf update
zypper update
apt-get upgrade
apt upgrade
pacman -Su

# remove an installed package
yum remove 
dnf remove 
apt-get remove 
apt remove 
pacman -R 
pacman -Rs 

# search for the package name containing specific file or folder
yum whatprovides *
dnf whatprovides *
zypper what-provides 
zypper search --provides 
apt-file search 
pacman -Fs