Administrer les paquets avec Pacman

Pacman est le gestionnaire de paquets d'Arch Linux et de ses dérivées (Manjaro, EndeavourOS). Cette page vous donne les commandes réellement utiles au quotidien : installer, rechercher, mettre à jour, supprimer, nettoyer le cache, configurer les dépôts et remettre d'aplomb un système bloqué. Elle insiste surtout sur la règle qui fait la différence entre une machine Arch stable et une machine cassée : une mise à jour partielle n'est pas supportée. Elle s'adresse à un administrateur qui connaît déjà apt ou dnf et qui doit opérer une machine Arch.

Ce que vous allez apprendre

• Installer, rechercher et inspecter un paquet avec les commandes de base de Pacman.
• Mettre à jour le système entier avec pacman -Syu, et comprendre pourquoi c'est la seule opération de mise à jour supportée.
• Vérifier les mises à jour en attente sans toucher aux bases de données.
• Supprimer un paquet, ses dépendances devenues inutiles et les orphelins, sans casser la base locale.
• Configurer /etc/pacman.conf : dépôts officiels, dépôt personnalisé, signatures GPG.
• Diagnostiquer un conflit de fichiers, une base verrouillée ou une erreur de signature.

Les commandes de cette page ont été vérifiées sur Arch Linux avec Pacman 7.1.0 (libalpm 16.0.1).

Prérequis

Pacman n'a rien à installer : il est présent d'origine sur toute machine Arch. Ce qu'il vous faut, c'est une machine jetable pour tester sans risque, car plusieurs manipulations décrites ici (mise à jour partielle, écrasement de fichiers) laissent des traces durables sur un système de production.

• Une machine Arch Linux (ou une dérivée) et un compte avec les droits sudo.
• Quelques bases de ligne de commande Linux.
• La comparaison avec les autres familles est traitée dans le panorama des gestionnaires de paquets.

La règle qui prime sur tout : pas de mise à jour partielle

Arch Linux est une distribution en flux continu (rolling release) : il n'y a pas de version figée, les paquets des dépôts sont reconstruits en permanence les uns contre les autres. Un paquet publié aujourd'hui est lié aux bibliothèques partagées telles qu'elles existent aujourd'hui dans les dépôts, pas telles qu'elles existent sur votre disque. C'est pour cette raison que les mises à jour partielles ne sont pas supportées par le projet Arch.

Concrètement, une mise à jour partielle survient dès que vous rafraîchissez les bases de données (-y) sans mettre à jour l'intégralité du système (-u). Les deux formes classiques sont sudo pacman -Sy nom_du_paquet et sudo pacman -Sy suivi d'une simple installation. Pacman installe alors la dernière version du paquet demandé et de ses dépendances, tout en laissant le reste du système sur d'anciennes versions. Résultat : des binaires qui réclament une bibliothèque absente (error while loading shared libraries), et parfois un système qui ne redémarre plus.

L'effet se mesure très simplement. Sur une machine dont les bases sont fraîches mais le système en retard, un pacman -S gcc seul veut installer gcc en version 16.1.1...-3 et ses bibliothèques associées, alors que le paquet gcc-libs déjà installé reste en 16.1.1...-1 : le système se retrouve avec deux générations de bibliothèques censées travailler ensemble.

La seule opération de mise à jour supportée est donc la mise à jour complète :

sudo pacman -Syu

Ne mettez jamais à jour un seul paquet

Sur Arch, il n'existe pas de « mettre à jour ce paquet uniquement ». sudo pacman -S nom_du_paquet sur un paquet déjà installé le fait passer à la version du dépôt, donc produit une mise à jour partielle si le reste du système est en retard. Si vous avez besoin de la dernière version d'un logiciel, mettez à jour tout le système avec sudo pacman -Syu. C'est le prix d'entrée du flux continu, et il n'est pas négociable.

Vous voulez savoir ce qui vous attend avant de lancer la mise à jour ? N'utilisez pas pacman -Sy pour cela : cette commande met les bases dans un état désynchronisé du système, ce qui est précisément la situation à éviter. La commande sûre est checkupdates, fournie par le paquet pacman-contrib : elle travaille sur une copie temporaire de la base et ne modifie rien.

sudo pacman -S --needed pacman-contrib
checkupdates

La sortie liste les paquets concernés, ancienne version puis nouvelle :

archlinux-keyring 20260612-1 -> 20260707.1-1
libffi 3.6.0-1 -> 3.7.1-1

Si aucune mise à jour n'est disponible, checkupdates n'affiche rien et rend un code de retour non nul : c'est un comportement normal, pratique dans un script de supervision.

Installer, rechercher et inspecter un paquet

Les commandes de lecture (-Ss, -Si, -Q) ne demandent aucun privilège : lancez-les avec votre compte normal. Seules les commandes qui modifient le système (-S, -R, -U) exigent sudo, puisqu'elles écrivent dans la base locale et dans les répertoires système.

Commencez par chercher le nom exact du paquet, puis regardez ce qu'il embarque avant de l'installer. L'opération -S signifie sync : elle synchronise votre machine avec l'état des dépôts.

pacman -Ss '^htop$'
pacman -Si htop

La recherche -Ss interroge les bases des dépôts et accepte une expression régulière, d'où les ancres ^ et $ pour éliminer le bruit. La sortie indique le dépôt d'origine :

extra/htop 3.5.1-1
    Interactive process viewer

L'installation suit, avec l'option --needed qui évite de réinstaller inutilement un paquet déjà à jour :

sudo pacman -S --needed htop

Vérification : le paquet est bien inscrit dans la base locale et son binaire lui appartient.

pacman -Qi htop | head -3
pacman -Qo /usr/bin/htop

La seconde commande doit répondre /usr/bin/htop is owned by htop 3.5.1-1. La lettre -Q (query) interroge toujours ce qui est installé sur la machine, là où -S interroge les dépôts distants : c'est la distinction la plus utile à mémoriser dans toute la syntaxe de Pacman.

Pour installer un paquet déjà téléchargé sous forme de fichier (une archive .pkg.tar.zst construite localement ou récupérée du cache), utilisez l'opération -U (upgrade) :

sudo pacman -U /var/cache/pacman/pkg/htop-3.5.1-1-x86_64.pkg.tar.zst

C'est aussi la commande qui permet de revenir à une version antérieure d'un paquet quand le cache la contient encore, en cas de régression après une mise à jour.

Mettre à jour le système

sudo pacman -Syu est la commande centrale de la maintenance d'Arch. Elle enchaîne trois choses : -y télécharge des bases de données fraîches depuis les miroirs, -u compare l'état des dépôts à l'état de la machine, -S applique la synchronisation. C'est l'équivalent fonctionnel d'apt update && apt full-upgrade sur Debian, en une seule invocation.

sudo pacman -Syu

Vérification : relancez la commande. La deuxième exécution doit répondre there is nothing to do, ce qui confirme que la machine est alignée sur les dépôts.

Avant une mise à jour sur une machine importante, prenez trente secondes pour lire les annonces du projet Arch. C'est le canal où sont publiées les interventions manuelles requises : remplacement d'un paquet, changement de format de configuration, dépôt renommé. Une mise à jour qui casse sans prévenir a presque toujours une annonce correspondante que personne n'a lue.

Deux options complètent utilement la commande. -w (downloadonly) télécharge les paquets sans les installer, ce qui permet de préparer une mise à jour longue pendant que la machine est encore disponible, puis de l'appliquer dans une fenêtre courte :

sudo pacman -Syuw
sudo pacman -Su

Quand -Syy est légitime, et quand il ne l'est pas

Le double -yy force le retéléchargement complet des bases de données, même si Pacman les considère à jour. C'est utile dans un seul cas : vous venez de changer de miroir ou de réécrire /etc/pacman.d/mirrorlist, et vous voulez repartir des métadonnées du nouveau serveur.

sudo pacman -Syyu

Notez que le -u reste présent : on force le rafraîchissement et on met à jour tout le système. En revanche, sudo pacman -Syy seul ne répare rien : il consomme de la bande passante, sollicite les miroirs sans raison, et surtout il laisse la machine avec des bases plus récentes que le système, ce qui est exactement la porte d'entrée de la mise à jour partielle. Ce n'est ni un remède contre une base corrompue ni un réflexe de dépannage.

Choisir des miroirs rapides

La vitesse de Pacman dépend d'abord de la qualité des miroirs listés dans /etc/pacman.d/mirrorlist. L'outil reflector interroge l'état des miroirs officiels, filtre ceux qui sont à jour et les trie par débit mesuré :

sudo pacman -S --needed reflector
sudo reflector --country France --age 12 --protocol https --sort rate --number 10 --save /etc/pacman.d/mirrorlist

L'option --age 12 écarte les miroirs synchronisés il y a plus de douze heures, --protocol https impose le transport chiffré. Après avoir réécrit la liste, enchaînez avec sudo pacman -Syyu : c'est le cas d'usage légitime du double -y.

Supprimer des paquets et nettoyer le système

La suppression suit la même logique de lettres empilées : -R retire le paquet demandé, -s y ajoute ses dépendances devenues inutiles, -n supprime aussi les fichiers de configuration que Pacman aurait sinon sauvegardés en .pacsave.

sudo pacman -R htop
sudo pacman -Rs htop
sudo pacman -Rns htop

Le choix entre les trois n'est pas cosmétique. -R seul laisse derrière lui des dépendances orphelines qui s'accumulent. -Rns est la forme la plus propre pour un logiciel dont vous ne voulez plus aucune trace, mais elle efface votre configuration : si vous comptez réinstaller plus tard, restez sur -Rs et gardez le .pacsave.

Vérification : pacman -Q htop doit répondre error: package 'htop' was not found.

Traquer les orphelins

Un paquet est orphelin quand il a été installé comme dépendance (-d) et que plus rien ne le requiert (-t, unrequired). Ces deux filtres se combinent sur une requête locale :

pacman -Qdt

Si la liste est vide, la commande n'affiche rien et rend un code de retour à 1 : la machine est propre. Sinon, la forme -q (quiet) ne renvoie que les noms, ce qui permet de les passer à la suppression :

sudo pacman -Rns $(pacman -Qdtq)

Le piège de la liste vide

Quand il n'y a aucun orphelin, la substitution produit une commande sans cible et Pacman s'arrête sur error: no targets specified (use -h for help). Ce n'est pas une panne : c'est le signe qu'il n'y avait rien à supprimer. Vérifiez toujours avec pacman -Qdt avant de lancer la suppression, et relancez le duo une seconde fois : retirer un orphelin peut en révéler d'autres en cascade.

Nettoyer le cache

Pacman conserve chaque paquet téléchargé dans /var/cache/pacman/pkg/ (le répertoire de cache des archives .pkg.tar.zst). C'est une assurance précieuse : c'est de là que vous ressortez une version antérieure avec pacman -U après une régression. Mais le répertoire grossit indéfiniment, jusqu'à plusieurs dizaines de gigaoctets sur une machine ancienne.

L'opération -Sc retire du cache les paquets qui ne sont plus installés, ainsi que les bases de dépôts inutilisées. Elle demande confirmation avant d'agir :

sudo pacman -Sc

Cache directory: /var/cache/pacman/pkg/
:: Do you want to remove all other packages from cache? [Y/n]

La variante -Scc vide tout, y compris les archives des paquets actuellement installés : vous perdez alors toute possibilité de retour arrière hors ligne. Réservez-la aux machines à l'espace disque critique.

L'approche plus fine passe par paccache, également fourni par pacman-contrib. Elle conserve les trois dernières versions de chaque paquet par défaut :

sudo pacman -S --needed pacman-contrib
sudo paccache -r

L'option -k fixe le nombre de versions gardées : sudo paccache -rk1 n'en conserve qu'une, sudo paccache -r -k0 vide le cache. Ajoutez -d (dryrun) pour voir ce qui serait supprimé sans rien effacer. La sortie annonce le résultat, par exemple ==> finished: 1 packages removed (disk space saved: 49.91 KiB).

Sauvegarder la liste des paquets

Avant une intervention lourde, ou simplement pour préparer une réinstallation, exportez la liste des paquets installés explicitement (par opposition à ceux tirés comme dépendances) :

pacman -Qqe > /root/paquets-installes.txt

La restauration se fait en réinjectant ce fichier sur l'entrée standard : le tiret - demande à Pacman de lire ses cibles depuis stdin, et --needed évite de réinstaller ce qui est déjà en place.

sudo pacman -S --needed - < /root/paquets-installes.txt

Cette sauvegarde est un inventaire, pas une image du système : elle ne contient ni vos configurations dans /etc ni vos données. Elle se combine avec une sauvegarde classique, pas à la place.

Configurer Pacman avec /etc/pacman.conf

Le fichier /etc/pacman.conf (la configuration globale de Pacman) contient un bloc [options] puis la liste ordonnée des dépôts. L'ordre compte : à nom de paquet identique, le premier dépôt déclaré gagne, quelle que soit la version.

sudo nano /etc/pacman.conf

Sur une Arch à jour, les dépôts officiels activés par défaut sont [core] (le socle : noyau, pacman, glibc, systemd) et [extra] (tout le reste du logiciel empaqueté officiellement). Deux autres dépôts sont présents mais commentés : [multilib], à activer pour les bibliothèques 32 bits (Steam, Wine), et les dépôts *-testing, réservés aux paquets en préparation.

Le dépôt [community] n'existe plus

Beaucoup de tutoriels encore en ligne listent un dépôt [community]. Il a été fusionné dans [extra] en mai 2023 et n'existe plus. Si vous le trouvez encore dans votre /etc/pacman.conf, supprimez la section : la conserver ne fait que produire des erreurs de rafraîchissement.

Les options de confort

Sous [options], quelques réglages changent le quotidien. Ils s'ajoutent sur une ligne chacun, sans valeur pour les trois premiers :

[options]
Color
VerbosePkgLists
ParallelDownloads = 5
ILoveCandy

Color colorise la sortie, ce qui rend les conflits et les avertissements immédiatement visibles. VerbosePkgLists affiche les mises à jour sous forme de tableau avec l'ancienne et la nouvelle version : c'est ce qui vous permet de repérer d'un coup d'œil qu'une bibliothèque critique change de version majeure. ParallelDownloads fixe le nombre de téléchargements simultanés. ILoveCandy remplace la barre de progression par un clin d'œil à Pac-Man, sans effet technique.

Vérification : un simple sudo pacman -Sy doit se dérouler sans message d'erreur de syntaxe, avec la sortie désormais colorée.

Ajouter un dépôt personnalisé

Un dépôt maison (paquets internes à une entreprise, miroir d'un projet) se déclare en fin de fichier, donc après les dépôts officiels pour ne pas les supplanter :

[depot-interne]
SigLevel = Required DatabaseOptional
Server = https://packages.example.internal/arch/$arch

La ligne SigLevel est le point de sécurité. Required impose que chaque paquet soit signé par une clé que votre machine reconnaît. Vous croiserez souvent SigLevel = Optional TrustAll dans des tutoriels : cette valeur désactive de fait la vérification et fait confiance à n'importe quelle signature, y compris celle d'un attaquant capable de se placer entre votre machine et le serveur. Ne l'utilisez pas sur une machine de production.

Pour qu'un dépôt signé fonctionne, importez sa clé publique dans le trousseau de Pacman, puis signez-la localement afin de la marquer comme fiable :

sudo pacman-key --recv-keys <empreinte-de-la-cle>
sudo pacman-key --lsign-key <empreinte-de-la-cle>

Vérification : sudo pacman -Sy doit rafraîchir le nouveau dépôt sans lever d'erreur de signature, et pacman -Sl depot-interne doit lister ses paquets.

Dépanner les erreurs courantes

Les pannes de Pacman se ressemblent d'une machine à l'autre. Le tableau ci-dessous donne le point d'entrée ; les sections suivantes détaillent les deux cas où une mauvaise manipulation aggrave durablement la situation.

Symptôme	Cause probable	Action corrective
failed to init transaction (unable to lock database)	Un Pacman tourne déjà, ou un précédent a été tué	Vérifier avec ps aux | grep pacman, puis sudo rm /var/lib/pacman/db.lck si aucun processus
exists in filesystem	Un fichier présent sur le disque n'appartient à aucun paquet	Identifier avec pacman -Qo, puis --overwrite ciblé (voir plus bas)
invalid or corrupted package (PGP signature)	Trousseau de clés périmé	sudo pacman -S archlinux-keyring puis relancer sudo pacman -Syu
error while loading shared libraries après une installation	Mise à jour partielle	sudo pacman -Syu complet immédiatement
package 'nom' was not found alors qu'il est installé	Entrée manquante dans la base locale	Ne rien supprimer, voir la section sur la base locale

Glissez pour voir

Le fichier /var/log/pacman.log (le journal de toutes les transactions) reste la meilleure source quand la sortie du terminal ne suffit pas : il horodate chaque installation, mise à jour et suppression, et permet de reconstituer ce qui a précédé la panne.

sudo less /var/log/pacman.log

Le verrou db.lck

Pacman crée /var/lib/pacman/db.lck au début d'une transaction pour empêcher deux instances d'écrire en même temps. Si le processus est interrompu brutalement (coupure de courant, terminal fermé), le fichier survit et bloque toute opération suivante :

error: failed to init transaction (unable to lock database)
error: could not lock database: File exists

Avant de supprimer le verrou, assurez-vous qu'aucun Pacman ne tourne réellement (une mise à jour graphique en arrière-plan, par exemple). Supprimer le verrou d'une transaction active corrompt la base.

ps aux | grep -c '[p]acman'
sudo rm /var/lib/pacman/db.lck

Le conflit de fichiers exists in filesystem

C'est l'erreur la plus fréquente. Elle survient quand Pacman veut écrire un fichier qui existe déjà sans appartenir au paquet qu'il installe :

error: failed to commit transaction (conflicting files)
tree: /usr/bin/tree exists in filesystem

La première étape est de savoir à qui appartient ce fichier :

pacman -Qo /usr/bin/tree

Deux réponses possibles. Si un autre paquet installé le revendique, vous avez un vrai conflit entre paquets : ne forcez rien, c'est un problème de dépôt ou de paquet AUR mal construit, à résoudre en supprimant le paquet fautif. Si la réponse est error: No package owns /usr/bin/tree, le fichier a été déposé à la main ou laissé par une désinstallation incomplète : il est légitime de laisser Pacman le remplacer, en désignant explicitement le chemin concerné.

sudo pacman -S --overwrite /usr/bin/tree tree

Jamais d'écrasement avec un joker

Le glob '*' autorise Pacman à écraser n'importe quel fichier du système, y compris ceux qui appartiennent à d'autres paquets. Vous ne réglez pas le conflit : vous le rendez invisible, et la base locale décrit désormais un système qui n'existe plus sur le disque. Ciblez toujours des chemins précis (l'option est répétable : --overwrite /usr/bin/tree --overwrite '/usr/share/man/*'), et seulement après avoir vérifié avec pacman -Qo que le fichier n'appartient à personne.

La base locale de Pacman ne se répare pas au rm

/var/lib/pacman/local/ contient un répertoire par paquet installé : c'est l'inventaire de la machine, la liste des fichiers posés par chaque paquet et leurs empreintes. Beaucoup de tutoriels proposent de supprimer une entrée « corrompue » avec un rm. C'est une très mauvaise idée, et la démonstration est immédiate.

Après suppression du répertoire de tree dans la base locale, Pacman oublie purement et simplement que le paquet existe, alors que ses fichiers sont toujours sur le disque :

$ pacman -Q tree
error: package 'tree' was not found

La réinstallation se heurte alors aux fichiers orphelins qu'il ne reconnaît plus, et le système entre dans le cercle du conflit de fichiers décrit plus haut :

error: failed to commit transaction (conflicting files)
tree: /usr/bin/tree exists in filesystem

Vous voilà contraint de forcer l'écrasement pour réparer un dégât que vous avez vous-même créé. La bonne démarche, quand vous soupçonnez la base ou les fichiers d'un paquet, est de vérifier avant d'agir. L'opération -Qkk compare les fichiers installés à ce que la base attend (taille, permissions, propriétaire) :

pacman -Qkk tree

La sortie tree: 16 total files, 0 altered files signifie que tout est conforme. Si des fichiers sont altérés, réinstallez proprement le paquet avec sudo pacman -S tree. Et si une entrée de la base est réellement illisible, restaurez /var/lib/pacman/local/ depuis une sauvegarde ou un instantané du système, en vous appuyant sur /var/log/pacman.log pour savoir quels paquets étaient en place. On ne reconstruit pas un inventaire à coups de rm.

Utiliser l'AUR sans se mettre en danger

L'AUR (Arch User Repository) est le dépôt communautaire d'Arch. Il ne contient pas de paquets binaires mais des PKGBUILD : des scripts qui décrivent comment télécharger les sources et construire le paquet sur votre machine. C'est ce qui donne accès à des logiciels absents des dépôts officiels, mais c'est aussi ce qui change la nature du risque : vous exécutez du code écrit par un inconnu, avec vos droits.

Deux réflexes rendent l'AUR utilisable sereinement. D'abord, lire le PKGBUILD avant chaque construction, en particulier les URL de source et le contenu des fonctions prepare() et build(). Ensuite, ne jamais lancer makepkg en root : makepkg refuse d'ailleurs de démarrer sous l'identité root, précisément parce qu'un script malveillant y aurait tous les droits.

Les paquets AUR n'étant dans aucun dépôt, ils apparaissent comme étrangers à la base de synchronisation. C'est ainsi qu'on les recense :

pacman -Qm

Construire un paquet à la main

Le chemin de référence n'utilise aucun outil tiers : on clone le dépôt Git du paquet, on inspecte le PKGBUILD, puis on construit. Les outils de compilation sont regroupés dans le groupe base-devel.

sudo pacman -S --needed git base-devel
git clone https://aur.archlinux.org/yay.git
cd yay
less PKGBUILD
makepkg -si

L'option -s de makepkg installe les dépendances de construction manquantes, -i installe le paquet produit à la fin via pacman -U. Un assistant AUR comme yay ou paru automatise ensuite ce cycle, mais il ne vous dispense pas de la relecture : yay -S nom_du_paquet construit du code tiers exactement comme makepkg.

Vérification : pacman -Qm doit désormais lister yay avec sa version.

Écrire un PKGBUILD correct

Un PKGBUILD minimal déclare le nom, la version, l'architecture, les sources, et les fonctions de construction et d'empaquetage. Il déclare surtout un tableau de sommes de contrôle : sans lui, makepkg refuse de travailler.

pkgname=monoutillage
pkgver=1.0
pkgrel=1
pkgdesc="Outil interne de supervision"
arch=('any')
license=('MIT')
source=("monoutillage-$pkgver.tar.gz")
sha256sums=('e239672bbca007c25a020d5e62fd7949fcb80f307ba98eab9df692aeea3e02bd')
package() {
  cd "$srcdir/$pkgname-$pkgver"
  install -Dm755 monoutillage "$pkgdir/usr/bin/monoutillage"
}

L'empreinte ci-dessus est celle de l'archive utilisée pour l'exemple : la vôtre sera différente, et vous ne la recopiez jamais à la main. Sans cette ligne sha256sums, la construction s'arrête net, quelle que soit la qualité du reste du script :

==> ERROR: Integrity checks are missing for: source

Ce n'est pas une formalité : ces empreintes garantissent que l'archive téléchargée est bien celle que le mainteneur a testée, et non une version substituée en chemin. On ne les écrit pas à la main : la commande updpkgsums (paquet pacman-contrib) calcule les sommes des sources déclarées et les injecte dans le PKGBUILD.

updpkgsums
makepkg -si

Vérification : grep sha256sums PKGBUILD doit afficher le tableau rempli, et makepkg se terminer sur ==> Finished making: monoutillage 1.0-1.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• Les mises à jour partielles ne sont pas supportées sur Arch. La seule opération de mise à jour est sudo pacman -Syu, complète. pacman -Sy nom_du_paquet et « mettre à jour un seul paquet » cassent les bibliothèques partagées.
• Pour connaître les mises à jour en attente sans désynchroniser la machine, utilisez checkupdates (paquet pacman-contrib), jamais pacman -Sy.
• -S interroge les dépôts, -Q interroge les paquets installés, -R supprime, -U installe un fichier local. Tout le reste n'est que des lettres empilées.
• -Syy ne se justifie qu'après un changement de miroir, et toujours suivi de -u (pacman -Syyu). Ce n'est pas un outil de dépannage.
• Le dépôt [community] n'existe plus : il est fusionné dans [extra] depuis mai 2023. Les dépôts par défaut sont [core] et [extra], plus [multilib] si vous avez besoin du 32 bits.
• Sur un conflit exists in filesystem, identifiez le propriétaire avec pacman -Qo puis utilisez --overwrite sur un chemin précis. Le glob --overwrite '*' écrase des fichiers appartenant à d'autres paquets et rend la base locale mensongère.
• Ne supprimez jamais d'entrée dans /var/lib/pacman/local/ : Pacman perd la trace du paquet, ses fichiers restent sur le disque et toute réinstallation part en conflit. Vérifiez avec pacman -Qkk, restaurez depuis une sauvegarde.
• Nettoyez avec paccache -r (trois versions gardées) plutôt qu'avec -Scc, et supprimez les orphelins avec pacman -Rns $(pacman -Qdtq) après avoir vérifié que pacman -Qdt renvoie bien quelque chose.
• L'AUR construit du code tiers sur votre machine : relisez le PKGBUILD, ne lancez jamais makepkg en root, et déclarez toujours un tableau sha256sums dans vos propres paquets.

Articles qui pourraient vous intéresser

• Les gestionnaires de paquets Linux
• Maîtriser APT sur Debian et dérivés
• Maîtriser le gestionnaire de paquets DNF
• Maîtriser le gestionnaire de paquets Zypper
• Réparer des dépendances cassées
• Appliquer les mises à jour de sécurité

×

📖 Voir la documentation →