Un paquet logiciel est un fichier d’archive contenant un programme informatique ainsi que les métadonnées nécessaires à son déploiement. Le programme informatique peut être en code source qui doit être compilé et construit au préalable. Les métadonnées du paquet comprennent la description du paquet, la version du paquet et les dépendances (autres paquets qui doivent être installés au préalable).
Les gestionnaires de paquets sont chargés de trouver, d’installer, de maintenir ou de désinstaller les paquets logiciels sur commande de l’utilisateur. Les fonctions typiques d’un système de gestion de paquets comprennent :
- Travailler avec des archiveurs de fichiers pour extraire les archives de paquets
- Assurer l’intégrité et l’authenticité du paquet en vérifiant leurs sommes de contrôle et leurs certificats numériques, respectivement
- Rechercher, télécharger, installer ou mettre à jour des logiciels existants à partir d’un dépôt de logiciels ou d’un magasin d’applications
- Grouper les paquets par fonction pour réduire la confusion de l’utilisateur
- Gérer les dépendances pour s’assurer qu’un paquet est installé avec tous les paquets dont il a besoin, évitant ainsi « l’enfer des dépendances »
Des défis avec les bibliothèques partagéesEdit
Les systèmes informatiques qui s’appuient sur la liaison dynamique des bibliothèques, au lieu de la liaison statique des bibliothèques, partagent des bibliothèques exécutables d’instructions machine entre les paquets et les applications. Dans ces systèmes, les relations complexes entre différents paquets nécessitant différentes versions de bibliothèques aboutissent à un défi familièrement connu sous le nom de « dependency hell ». Sur les systèmes Microsoft Windows, cette situation est également appelée « enfer des DLL » lorsqu’on travaille avec des bibliothèques liées dynamiquement. Une bonne gestion des paquets est vitale sur ces systèmes. Le système Framework de OPENSTEP était une tentative de résoudre ce problème, en permettant à plusieurs versions de bibliothèques d’être installées simultanément, et aux paquets logiciels de spécifier contre quelle version ils étaient liés.
Fronts pour les paquets compilés localementEdit
Les administrateurs système peuvent installer et maintenir des logiciels en utilisant des outils autres que les logiciels de gestion de paquets. Par exemple, un administrateur local peut télécharger du code source non empaqueté, le compiler et l’installer. Cela peut entraîner une désynchronisation de l’état du système local avec l’état de la base de données du gestionnaire de paquets. L’administrateur local devra prendre des mesures supplémentaires, comme gérer manuellement certaines dépendances ou intégrer les modifications dans le gestionnaire de paquets.
Il existe des outils permettant de s’assurer que les paquets compilés localement sont intégrés dans la gestion des paquets. Pour les distributions basées sur des fichiers .deb et .rpm ainsi que pour Slackware Linux, il y a CheckInstall, et pour les systèmes basés sur des recettes comme Gentoo Linux et les systèmes hybrides comme Arch Linux, il est possible d’écrire d’abord une recette, qui s’assure ensuite que le paquet s’intègre dans la base de données des paquets locaux.
Maintenance de la configurationEdit
Les mises à jour des fichiers de configuration sont particulièrement gênantes avec les mises à jour logicielles. Puisque les gestionnaires de paquets, au moins sur les systèmes Unix, sont nés comme des extensions d’utilitaires d’archivage de fichiers, ils ne peuvent généralement que soit écraser, soit conserver les fichiers de configuration, plutôt que de leur appliquer des règles. Il existe des exceptions à cette règle qui s’appliquent généralement à la configuration du noyau (qui, si elle est cassée, rendra l’ordinateur inutilisable après un redémarrage). Des problèmes peuvent être causés si le format des fichiers de configuration change ; par exemple, si l’ancien fichier de configuration ne désactive pas explicitement les nouvelles options qui devraient être désactivées. Certains gestionnaires de paquets, comme dpkg de Debian, permettent la configuration pendant l’installation. Dans d’autres situations, il est souhaitable d’installer les paquets avec la configuration par défaut, puis d’écraser cette configuration, par exemple, dans le cas d’installations sans tête sur un grand nombre d’ordinateurs. Ce type d’installation préconfigurée est également pris en charge par dpkg.
RepositoriesEdit
Pour donner aux utilisateurs plus de contrôle sur les types de logiciels qu’ils autorisent à être installés sur leur système (et parfois pour des raisons légales ou de commodité du côté des distributeurs), les logiciels sont souvent téléchargés depuis un certain nombre de dépôts de logiciels.
Suppression de mise à niveauEdit
Lorsqu’un utilisateur interagit avec le logiciel de gestion de paquets pour provoquer une mise à niveau, il est habituel de présenter à l’utilisateur la liste des actions à exécuter (généralement la liste des paquets à mettre à niveau, et éventuellement en donnant les numéros de l’ancienne et de la nouvelle version), et de permettre à l’utilisateur soit d’accepter la mise à niveau en bloc, soit de sélectionner des paquets individuels pour les mises à niveau. De nombreux gestionnaires de paquets peuvent être configurés pour ne jamais mettre à niveau certains paquets, ou pour les mettre à niveau uniquement lorsque des vulnérabilités ou des instabilités critiques sont trouvées dans la version précédente, comme défini par l’empaqueteur du logiciel. Ce processus est parfois appelé épinglage de version.
Par exemple :
- yum le prend en charge avec la syntaxe exclude=openoffice*
- pacman avec IgnorePkg= openoffice (pour supprimer la mise à niveau d’openoffice dans les deux cas)
- dpkg et dselect le prennent partiellement en charge grâce au drapeau hold. dans les sélections de paquets
- APT étend le drapeau hold à travers le mécanisme complexe « pinning » (Les utilisateurs peuvent aussi mettre un paquet sur liste noire)
- aptitude a des drapeaux « hold » et « forbid »
- portage supporte cela à travers le paquet.fichier de configuration de masque
Suppression de paquet en cascadeEdit
Certaines des fonctionnalités de gestion de paquets les plus avancées offrent une « suppression de paquet en cascade », dans laquelle tous les paquets qui dépendent du paquet cible et tous les paquets dont seul le paquet cible dépend, sont également supprimés.
Comparaison des commandesEdit
Bien que les commandes soient spécifiques à chaque gestionnaire de paquets particulier, elles sont dans une large mesure traduisibles, car la plupart des gestionnaires de paquets offrent des fonctions similaires.
| Action | zypper | pacman | apt | dnf (yum) | portage |
|---|---|---|---|---|---|
| installer le paquet | zypper dans PKG |
pacman -.S PACKAGE |
apt install PACKAGE |
dnf install PACKAGE |
emerge PACKAGE |
| remove package | zypper rm -RU PKG |
pacman -R PACKAGE |
apt remove PACKAGE |
dnf remove --nodeps PACKAGE |
emerge -C PACKAGE ou emerge --unmerge PACKAGE |
| remove package+orphans | zypper rm -u --force-résolution PKG |
pacman -Rs PACKAGE |
apt autoremove PACKAGE |
dnf remove PACKAGE |
emerge -c PACKAGE ou emerge --depclean PACKAGE |
| mise à jour de la base de données des logiciels | zypper ref |
pacman -Sy |
apt update |
dnf check-update |
emerge --synchro |
| show updatable packages | zypper lu |
pacman -Qu |
apt list --upgradable |
dnf check-update |
emerge -avtuDN --with-bdeps=y @world ou emerge --update --pretend @world |
| delete orphans+config | zypper rm -u |
pacman -Rsn $(pacman -Qdtq) |
apt autoremove |
dnf erase PKG |
emerge --depclean |
| show orphans | zypper pa --orphaned --unneed |
pacman -Qdt |
package-cleanup --quiet --leaves --exclude-bin |
emerge -caD ou emerge --depclean --pretend |
|
| update all | zypper up |
pacman -Syu |
mise à niveau de l'ordinateur |
mise à jour du DNF |
émergence --update --deep --with-bdeps=y @world |
Le wiki Arch Linux Pacman/Rosetta offre un aperçu complet.