Debian 13 « Unable to locate package » : pièges de dépôts, d’architecture et de sources.list (et correctifs)

Vous tapez apt install, appuyez sur Entrée, et Debian répond calmement : « Unable to locate package … ». Le paquet existe. Votre collègue l’a installé la semaine dernière. Votre mémoire musculaire insiste pour dire que ça devrait marcher.

Cette erreur n’est pas un seul problème. C’est une famille de mauvaises configurations et d’hypothèses obsolètes — noms de suites, composants, architectures, miroirs, clés, pinning, et parfois juste votre optimisme. Traquons-la comme des adultes.

Plan de diagnostic rapide (faire ça en premier)

Quand la production attend et que vous n’avez pas le temps pour un débat philosophique avec APT, faites ceci dans l’ordre. L’objectif est d’identifier si le goulot d’étranglement est la métadonnée, les dépôts, l’architecture ou la politique.

1) Confirmez la vision d’APT (fraîcheur des métadonnées)

• Exécutez apt-get update et lisez les erreurs, pas seulement le code de sortie.
• Si vous voyez NO_PUBKEY, 403, 404 ou des problèmes de Release file, arrêtez-vous. Corrigez cela d’abord.

2) Demandez à APT s’il connaît le nom du paquet

• apt-cache show pkg et apt-cache policy pkg indiquent si le paquet existe dans vos dépôts configurés.
• Si APT ne le connaît pas, le problème est lié aux sources/composants/suite/arch/synchronisation du miroir.

3) Validez la suite et les composants (le piège le plus courant de Debian 13)

• Vérifiez que votre suite correspond à la réalité (par ex. trixie vs stable vs testing).
• Assurez-vous que non-free-firmware est présent si vous attendez des paquets firmware.

4) Validez l’architecture et le multiarch

• Confirmez avec dpkg --print-architecture.
• Si vous essayez d’installer :i386 sur amd64, ajoutez l’architecture et mettez à jour.

5) Vérifiez le pinning / preferences

• apt-cache policy montrera les pins et la sélection du candidat.
• Le pinning produit rarement « Unable to locate package », mais il produit souvent « no installation candidate » et est mal reporté dans les tickets.

Si vous faites ces cinq vérifications, vous aurez généralement le coupable en moins de dix minutes. Sinon, vous êtes probablement dans l’enfer de synchronisation des miroirs ou vous traitez un dépôt qui a cessé de publier pour votre suite/arch.

Ce que signifie vraiment « Unable to locate package »

APT ne vous dit pas « le paquet n’existe pas dans Debian ». Il vous dit quelque chose de plus étroit et plus ennuyeux :

• L’index local des paquets d’APT ne contient pas ce nom de paquet pour une quelconque combinaison de dépôt, suite, composant et architecture activés.
• Ou vous demandez un nom de paquet qui ne correspond à aucun paquet dans ces index (typo, paquet renommé, paquet transitoire supprimé).

C’est pourquoi le même paquet peut exister sur les serveurs Debian et être pourtant « introuvable » pour votre hôte. Votre hôte n’est au courant que de ce pour quoi il a des index. Les index proviennent des dépôts configurés. Les dépôts sont découpés par :

• Suite (par ex. trixie, stable, testing)
• Composant (par ex. main, contrib, non-free, non-free-firmware)
• Architecture (par ex. amd64, arm64, i386)

Manquez une tranche et le paquet disparaît de l’univers d’APT.

Aussi : Debian 13 pousse plus de monde vers le « nouveau format sources » et des habitudes de keyring plus strictes. C’est du bon ingénierie. C’est aussi une nouvelle réserve de façons de se tirer une balle dans le pied — proprement, de façon déterministe et à grande échelle.

Faits et contexte qui expliquent les bizarreries

• Fait 1 : Debian sépare les dépôts en suites et composants pour séparer objectifs de stabilité et contraintes de licence ; votre configuration décide ce qu’APT peut « voir ».
• Fait 2 : Debian a introduit le composant non-free-firmware (séparé de non-free) afin que le firmware puisse être activé explicitement sans tirer tout le reste.
• Fait 3 : Le multiarch dans Debian permet d’installer des paquets d’architecture étrangère (comme :i386 sur amd64), mais APT ne téléchargera pas ces index à moins d’ajouter l’architecture.
• Fait 4 : Les messages d’erreur d’APT sont précis mais pas toujours amicaux : « Unable to locate package » concerne des entrées d’index manquantes, pas la connectivité réseau ou le DNS (ceux-ci apparaissent généralement pendant apt update).
• Fait 5 : Les métadonnées des dépôts Debian sont signées ; les configurations modernes préfèrent des keyrings par dépôt avec signed-by= plutôt que de déposer des clés dans un seau de confiance global.
• Fait 6 : Les miroirs peuvent être temporairement désynchronisés ; pendant les transitions vous pouvez légitimement voir des paquets manquants sur un miroir et présents sur un autre.
• Fait 7 : Debian prend en charge à la fois sources.list et des fichiers .sources au format deb822 ; les mélanger sans précaution peut produire des doublons, des suites conflictuelles ou un comportement de pin surprenant.
• Fait 8 : Les paquets sont renommés, scindés ou retirés entre les versions ; le nom dont vous vous souvenez dans une Debian plus ancienne peut être maintenant un paquet transitoire ou avoir disparu entièrement.

Une citation qui vaut la peine d’être collée sur votre moniteur :

« L’espoir n’est pas une stratégie. » — Gene Kranz (idée paraphrasée)

Tâches pratiques : commandes, sorties, décisions (12+)

Voici les vérifications que j’exécute sur de vrais serveurs. Chaque tâche inclut : la commande, un extrait réaliste de sortie, ce que la sortie signifie, et la décision que vous prenez ensuite.

Task 1: Confirm your Debian version and codename (don’t guess)

cr0x@server:~$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
NAME="Debian GNU/Linux"
VERSION_ID="13"
VERSION="13 (trixie)"
VERSION_CODENAME=trixie
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

Signification : Vous êtes sur trixie. Si votre fichier de sources pointe vers bookworm ou stable dans un environnement avec pinning, attendez-vous à des surprises.

Décision : Alignez les sources sur trixie (ou choisissez consciemment stable/testing avec un pinning que vous pourrez expliquer à votre futur vous).

Task 2: Run update and actually read it

cr0x@server:~$ sudo apt-get update
Hit:1 http://deb.debian.org/debian trixie InRelease
Hit:2 http://security.debian.org/debian-security trixie-security InRelease
Get:3 http://deb.debian.org/debian trixie-updates InRelease [55.4 kB]
Reading package lists... Done

Signification : Les index ont été récupérés avec succès. Si vous ne trouvez toujours pas un paquet, c’est probablement suite/composant/arch/nom — pas la connectivité.

Décision : Passez aux tâches de découverte de paquets (policy/show/search) au lieu de déboguer le DNS.

Task 3: Catch signature/key problems early

cr0x@server:~$ sudo apt-get update
Get:1 https://repo.vendor.example/debian trixie InRelease [3,214 B]
Err:1 https://repo.vendor.example/debian trixie InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 0123456789ABCDEF
Reading package lists... Done
W: GPG error: https://repo.vendor.example/debian trixie InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 0123456789ABCDEF
E: The repository 'https://repo.vendor.example/debian trixie InRelease' is not signed.

Signification : APT refuse de faire confiance au dépôt ; ses paquets sont effectivement invisibles.

Décision : Installez la clé du fournisseur dans un keyring dédié et référencez-la avec signed-by= dans l’entrée de source (n’utilisez pas le vidage global de clés obsolète).

Task 4: Print configured sources (both old and new formats)

cr0x@server:~$ grep -R --no-filename -nE '^(deb|Types:)' /etc/apt/sources.list /etc/apt/sources.list.d/* 2>/dev/null
1:deb http://deb.debian.org/debian trixie main
2:deb http://deb.debian.org/debian trixie-updates main
3:deb http://security.debian.org/debian-security trixie-security main
/etc/apt/sources.list.d/vendor.sources:1:Types: deb

Signification : Vous avez des entrées classiques dans sources.list et au moins un fichier .sources deb822.

Décision : Inspectez aussi les fichiers deb822 ; beaucoup d’incidents « paquet introuvable » sont simplement une « mauvaise suite dans l’autre fichier que vous avez oublié qu’il existait ».

Task 5: Inspect a deb822 source file for suite/component mistakes

cr0x@server:~$ sed -n '1,120p' /etc/apt/sources.list.d/vendor.sources
Types: deb
URIs: https://repo.vendor.example/debian
Suites: stable
Components: main
Signed-By: /usr/share/keyrings/vendor-archive-keyring.gpg

Signification : Ce dépôt est épinglé sur stable. Sur Debian 13 cela peut être correct, ou incompatible avec des paquets fournisseurs publiés uniquement pour des codenames spécifiques.

Décision : Si la documentation du fournisseur attend trixie, changez la suite. S’ils publient uniquement pour bookworm, arrêtez-vous et reconsidérez — mélanger est un risque que vous devez justifier.

Task 6: Verify APT knows the package name

cr0x@server:~$ apt-cache show zfsutils-linux
N: Can't select versions from package 'zfsutils-linux' as it is purely virtual

Signification : Le nom existe mais est virtuel ; vous pourriez avoir besoin d’un paquet fournisseur, ou le nom a changé dans votre suite.

Décision : Utilisez apt-cache showpkg ou apt-cache policy pour identifier les fournisseurs ; n’essayez pas encore et encore apt install comme à une machine à sous.

Task 7: Check candidate versions and repo origins

cr0x@server:~$ apt-cache policy openssl
openssl:
  Installed: 3.3.1-1
  Candidate: 3.3.1-1
  Version table:
 *** 3.3.1-1 500
        500 http://deb.debian.org/debian trixie/main amd64 Packages
        100 /var/lib/dpkg/status

Signification : APT voit le paquet, voit son origine, et a un candidat. C’est ce à quoi ressemble un système « sain ».

Décision : Si votre paquet manquant n’affiche aucun Version table du tout, il n’est pas dans les index activés. Réparez les sources/composants/arch.

Task 8: Use apt-cache search to catch renamed packages

cr0x@server:~$ apt-cache search --names-only '^python3-venv$'
python3-venv - venv module for python3 (default python3 version)

Signification : Le paquet exact existe. Si l’installation échoue encore, vous avez un autre souci (peut-être pinning ou paquets retenus).

Décision : Installez-le ; si l’erreur est « no installation candidate », passez aux tâches liées au pinning/preferences.

Task 9: Confirm the system architecture (and stop installing the wrong thing)

cr0x@server:~$ dpkg --print-architecture
amd64

Signification : L’architecture native est amd64.

Décision : Si vous essayez d’installer :i386 (courant pour des outils legacy), ajoutez i386 et rafraîchissez.

Task 10: Check enabled foreign architectures (multiarch)

cr0x@server:~$ dpkg --print-foreign-architectures

Signification : Aucune architecture étrangère activée.

Décision : Si le paquet que vous voulez existe seulement en i386, activez-la.

Task 11: Enable i386 multiarch correctly

cr0x@server:~$ sudo dpkg --add-architecture i386
cr0x@server:~$ sudo apt-get update
Hit:1 http://deb.debian.org/debian trixie InRelease
Get:2 http://deb.debian.org/debian trixie/main i386 Packages [9,112 kB]
Fetched 9,112 kB in 2s (4,230 kB/s)
Reading package lists... Done

Signification : APT récupère maintenant les index i386.

Décision : Réessayez apt install pkg:i386. Si c’est toujours manquant, il n’est pas publié pour i386 dans cette suite.

Task 12: Confirm components include what you need (non-free-firmware is a frequent miss)

cr0x@server:~$ grep -n '^deb ' /etc/apt/sources.list
1:deb http://deb.debian.org/debian trixie main
2:deb http://security.debian.org/debian-security trixie-security main

Signification : Seul main est activé. Les paquets firmware situés dans non-free-firmware seront invisibles.

Décision : Ajoutez non-free-firmware (et non-free/contrib uniquement si vous avez une raison explicite).

Task 13: Update sources to include non-free-firmware

cr0x@server:~$ sudo sed -i 's/ main$/ main non-free-firmware/' /etc/apt/sources.list
cr0x@server:~$ sudo apt-get update
Hit:1 http://deb.debian.org/debian trixie InRelease
Get:2 http://deb.debian.org/debian trixie/non-free-firmware amd64 Packages [32.1 kB]
Fetched 32.1 kB in 1s (35.7 kB/s)
Reading package lists... Done

Signification : Vous indexez maintenant ce composant.

Décision : Réessayez l’installation du firmware ; si ça marche, documentez pourquoi non-free-firmware a été activé (pour que le prochain audit ne le considère pas comme accidentel).

Task 14: Detect duplicate/contradictory entries (classic + deb822 collision)

cr0x@server:~$ apt-get -o Debug::pkgAcquire::Auth=true update
Hit:1 http://deb.debian.org/debian trixie InRelease
Hit:2 http://deb.debian.org/debian stable InRelease
W: Target Packages (main/binary-amd64/Packages) is configured multiple times in /etc/apt/sources.list:1 and /etc/apt/sources.list.d/debian.sources:1
Reading package lists... Done

Signification : Vous indexez deux suites (trixie et stable) et vous dupliquez des cibles. Ce n’est pas de la « redondance ». C’est un « incident futur ».

Décision : Choisissez une approche. Préférez un seul fichier deb822 pour les dépôts officiels Debian sur les systèmes récents, ou conservez un fichier classique propre — mais n’utilisez pas les deux à moitié.

Task 15: Validate a package exists in your enabled components

cr0x@server:~$ apt-cache policy firmware-iwlwifi
firmware-iwlwifi:
  Installed: (none)
  Candidate: 20240811-1
  Version table:
     20240811-1 500
        500 http://deb.debian.org/debian trixie/non-free-firmware amd64 Packages

Signification : Le paquet firmware est présent et provient du composant attendu.

Décision : Installez-le. S’il manque, vous n’avez soit pas le composant, soit vous utilisez une suite où il porte un autre nom.

Task 16: Prove a network/proxy issue is corrupting APT’s view

cr0x@server:~$ sudo apt-get update
Ign:1 http://deb.debian.org/debian trixie InRelease
Err:1 http://deb.debian.org/debian trixie InRelease
  Could not connect to deb.debian.org:80 (199.232.138.132), connection timed out
Reading package lists... Done
W: Failed to fetch http://deb.debian.org/debian/dists/trixie/InRelease  Could not connect to deb.debian.org:80 (199.232.138.132), connection timed out
W: Some index files failed to download. They have been ignored, or old ones used instead.

Signification : Vous travaillez avec des index obsolètes. « Unable to locate package » peut simplement venir du fait que vos listes de paquets sont anciennes ou incomplètes.

Décision : Corrigez la connectivité/proxy/firewall. Tant que apt-get update n’est pas propre, considérez les résultats de disponibilité de paquets comme non fiables.

Blague 1 : APT ne « perd » pas les paquets. Il vous fait simplement douter jusqu’à ce que vous vous souveniez que vous avez changé le miroir le mois dernier.

Pièges de sources.list et deb822 dans Debian 13

Les installations Debian 13 contiennent souvent un mélange de l’ancien /etc/apt/sources.list et des nouveaux fichiers /etc/apt/sources.list.d/*.sources (deb822). Les deux fonctionnent. Le piège survient quand ils ne sont pas d’accord.

Confusion de suite : stable/testing vs codenames

Utiliser stable ou testing est pratique jusqu’à ce que ça ne le soit plus. Quand Debian bouge, ces étiquettes bougent aussi. C’est acceptable pour les postes de travail. En production, c’est comme se réveiller avec une libc différente qu’hier.

Si votre problème est « unable to locate package », la confusion de suite se manifestera ainsi :

• Vous êtes sur Debian 13 (trixie), mais vos sources pointent vers bookworm. Les paquets introduits dans trixie n’existeront pas.
• Vous êtes sur Debian 13, mais un dépôt tiers ne publie que pour bookworm, et vous l’avez configuré par erreur sur trixie. APT ne trouve pas d’index Packages pour votre suite et perd silencieusement l’accès à ces paquets.

Omission de composant : « main » n’est pas tout le système

Le « main » de Debian contient beaucoup. Il ne contient pas tout ce que les gens supposent être « juste du Linux ». Le firmware est l’exemple classique, surtout sur les portables, le Wi‑Fi et certains contrôleurs de stockage.

Sur Debian 13, si vous avez besoin de firmware et que vous n’avez pas non-free-firmware, vous verrez « unable to locate package firmware-… ». Ce n’est pas Debian cassé. C’est Debian explicite.

Erreurs Signed-by : le dépôt existe, mais vous ne lui faites pas confiance

APT moderne préfère restreindre la confiance. Bien. Mais cela signifie que vous pouvez facilement vous retrouver avec :

• Signed-By pointant vers un fichier qui n’existe pas
• un keyring installé, mais l’entrée du dépôt ne le référence pas
• une entrée de dépôt référant la mauvaise clé (courant lors des rotations de clés)

Dans tous ces cas, le dépôt peut être joignable, mais ses paquets restent effectivement indisponibles. APT avertira lors de apt update. Si vous ignorez ces avertissements, vous méritez l’erreur.

deb822 piège : un fichier peut définir plusieurs entrées

Le format deb822 est plus propre pour l’automatisation, mais il est aussi plus facile d’y cacher de la complexité. Un fichier peut contenir plusieurs stances. Les gens survolent la première et manquent la seconde qui épingle une suite différente ou désactive un composant.

Pièges d’architecture : amd64 vs i386 vs arm64

Les problèmes d’architecture sont ennuyeux, c’est pourquoi ils survivent dans les parcs d’entreprise. Vous pouvez regarder la configuration du dépôt pendant une heure et manquer le fait que vous êtes sur arm64.

Les schémas courants

• Mauvaise architecture matérielle : Vous êtes sur arm64 (instances cloud, certains portables), mais vous supposez amd64. Certains dépôts tiers ne publient pas pour arm64.
• Multiarch non activé : Vous voulez :i386, mais vous n’avez jamais ajouté i386. APT ne récupère pas les index i386. Le paquet est « manquant ».
• Le paquet n’est pas construit pour votre arch : Les dépôts officiels Debian ne construisent pas tous les paquets pour toutes les architectures (surtout les paquets marginaux). Le paquet existe, juste pas pour vous.

Comment le prouver rapidement

Regardez la sortie de apt-cache policy. Si vous voyez une ligne d’origine comme :

• ... trixie/main amd64 Packages alors vous regardez des métadonnées amd64.
• Si vous ne voyez jamais votre architecture dans les lignes du dépôt, il vous manque des métadonnées (mauvaise suite, mauvais dépôt, ou update échoué).

Composants : main, contrib, non-free, non-free-firmware

Cette section transforme « unable to locate package » du mystère en paperasserie.

Ce que chaque composant signifie opérationnellement

• main : Conforme aux Debian Free Software Guidelines. Supporté dans le sens normal de Debian. C’est là que vous voulez vivre.
• contrib : Logiciel libre qui dépend de composants non libres. C’est un panneau indiquant que vous êtes sur le point de faire un compromis.
• non-free : Logiciel non libre. Parfois nécessaire, souvent regrettable, toujours à documenter.
• non-free-firmware : Firmware non libre. Fréquemment nécessaire pour que le matériel fonctionne. Conservé séparément pour que vous puissiez l’activer sans ouvrir entièrement le robinet non-free.

Conseil pratique : n’activez non-free-firmware que si vous en avez besoin, mais ne faites pas semblant de ne pas en avoir besoin. Des interfaces réseau à moitié fonctionnelles ne vous rendent pas moralement supérieur ; elles vous rendent en retard.

Miroirs et problèmes réseau qui ressemblent à des paquets manquants

Parfois le paquet est vraiment absent — de votre miroir choisi, maintenant. Les miroirs dérivent. Les proxies mettent en cache incorrectement. Les passerelles de sécurité réécrivent le trafic. Et parfois un miroir interne sert silencieusement les index de mardi dernier parce que son job rsync est mort.

Signes d’un miroir désynchronisé

• apt-get update réussit, mais vous ne trouvez pas des paquets que des collègues trouvent.
• apt-cache policy montre des versions étonnamment anciennes de façon globale.
• Un environnement (dev) voit des paquets, un autre (prod) non, malgré une « même configuration ».

Comment le gérer

En production, ne changez pas de miroir au hasard sur un hôte. Décidez si vous utilisez :

• un miroir officiel (bien pour les portables et petites flottes), ou
• un miroir interne contrôlé (bien pour la reproductibilité), ou
• un proxy de cache (bien jusqu’à ce qu’il ne le soit plus).

Puis surveillez-le. Oui, surveillez votre chaîne d’approvisionnement de paquets comme si c’était un service. Parce que ça l’est.

Pinning et suites mixtes : l’assassin silencieux de paquets

Le pinning est puissant. C’est aussi la façon de créer un système que seule une personne peut mettre à jour, et cette personne est en vacances.

Le pinning provoque habituellement « no installation candidate » ou des échecs du résolveur de dépendances, mais il contribue à « unable to locate package » lorsqu’il empêche APT de considérer une suite où le paquet existe — ou quand vous pensez avoir activé une suite mais le pinning la neutralise effectivement.

Où le pinning se cache

• /etc/apt/preferences
• /etc/apt/preferences.d/*.pref
• l’automatisation qui dépose des fichiers là (scripts de build d’image, gestion de configuration)

Que faire

Utilisez apt-cache policy pour comprendre la sélection du candidat. Puis décidez si vous exécutez :

• un système mono-suite (recommandé pour la plupart des serveurs), ou
• un système à suites mixtes (seulement si vous pouvez expliquer l’histoire des dépendances et avez la capacité de rollback).

Trois mini-récits d’entreprise tirés du terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une équipe plateforme a déployé des images Debian 13 pour une nouvelle série de gateways de stockage. La pipeline de build « standardisait » les sources APT en utilisant stable partout. Cette étiquette fonctionnait bien en CI. Ça marchait même en staging. Tout le monde a hoché la tête et est passé à autre chose.

Deux semaines plus tard, on a eu besoin d’un paquet vendor pour l’export de télémétrie NVMe. L’ingénieur d’astreinte a tenté de l’installer. « Unable to locate package. » Ils ont supposé que le dépôt fournisseur était en panne et ont escaladé. Le support fournisseur a répondu, poliment, que le dépôt était sain et avait des paquets pour trixie.

Le twist : le dépôt fournisseur était configuré avec Suites: stable, mais le fournisseur ne publiait pas sous cette étiquette mouvante — seulement sous les codenames. APT demandait dists/stable, recevait un 404, et traitait silencieusement le dépôt comme inexistant après que des avertissements aient défilé pendant les updates.

L’incident n’était pas le paquet manquant. L’incident était le délai de déploiement et la frénésie pour reconstruire des images pendant que les équipes de stockage attendaient. La cause racine était « stable signifie Debian stable partout », une hypothèse humaine raisonnable qui s’est avérée opérationnellement fausse pour des dépôts tiers.

La correction était banale : utiliser les codenames pour les dépôts tiers, et appliquer « pas d’avertissements sur apt-get update » en CI. Cette dernière partie comptait. Les avertissements sont l’endroit où APT vous dit la vérité, à sa manière émotionnellement distante.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation voulait un provisioning plus rapide. Quelqu’un a ajouté un proxy de cache interne devant les miroirs Debian. Les temps d’installation ont chuté drastiquement. Les tickets ont diminué. La direction a souri. Puis ils ont monté à l’échelle vers d’autres régions et plus de segmentation réseau.

Trois mois plus tard, une réponse à une vulnérabilité nécessitait le déploiement d’un paquet mis à jour sur toute la flotte. La moitié des hôtes disait « Unable to locate package », l’autre moitié mettait à jour, et rien ne corrélait proprement avec la version de l’OS. L’astreinte a commencé à blâmer les miroirs Debian, parce que c’est ce que font les gens quand ils voient une disponibilité incohérente des paquets.

Le vrai problème : le proxy mettait en cache agressivement les métadonnées des dépôts et ne respectait pas correctement les changements de Release pendant une transition de miroir. Il servait des listes de paquets périmées à certains segments et des listes plus récentes à d’autres, selon le timing d’éviction du cache. APT n’était pas cassé ; on lui mentait.

Ils l’ont « réparé » en purgeant les caches pendant les upgrades, ce qui a aidé ponctuellement. Mais ça n’a pas résolu le risque systémique. Finalement la bonne solution a été de traiter le proxy comme un service de production : le mettre à jour, configurer des sémantiques de cache correctes pour les métadonnées APT, et ajouter une surveillance qui compare les timestamps des fichiers Release attendus à ceux reçus par les clients.

L’optimisation est géniale jusqu’à ce que vous optimisiez la détermination. Les factures arrivent plus tard, généralement à 2 h du matin.

Mini-récit 3 : La pratique ennuyeuse qui a sauvé la mise

Une société financière utilisait Debian dans des environnements régulés. Ils avaient une règle : chaque image de base doit fournir un unique fichier deb822 versionné pour les dépôts Debian, et le build d’image échoue si apt-get update émet des avertissements ou erreurs.

C’était impopulaire. Les développeurs voulaient ajouter des dépôts ad hoc. Certaines équipes se plaignaient que ça freinait l’expérimentation. La sécurité aimait ça. Les opérations aimaient ça en silence.

Un jour, un dépôt tiers a fait une rotation de sa clé de signature. Beaucoup d’équipes l’ont appris quand les déploiements de production ont commencé à échouer. Dans cette société, cela a été détecté pendant le build d’image parce que apt-get update a fait échouer la pipeline immédiatement. La correction a été appliquée une fois (mise à jour du keyring + référence signed-by), intégrée à l’image de base, et les déploiements ont repris avec un minimum de drame.

Ils n’ont pas évité le changement dans l’écosystème. Ils ont évité le rayon d’impact. La pratique était ennuyeuse parce qu’elle fonctionnait, et elle fonctionnait parce qu’elle était ennuyeuse.

Blague 2 : Si vous mélangez stable, testing et unstable sans pinning, félicitations — vous venez d’inventer une nouvelle distribution. Merci de ne pas ouvrir de bugs à ce sujet.

Erreurs courantes : symptôme → cause racine → réparation

1) « Unable to locate package … » après une installation fraîche

Symptôme : Même des paquets courants sont introuvables, ou des paquets firmware manquent.

Cause racine : Les sources n’incluent que main, ou les sources n’ont pas été configurées (installation minimale, image personnalisée).

Réparation : Assurez-vous que les dépôts Debian existent et incluent les composants nécessaires (main plus non-free-firmware si besoin). Exécutez apt-get update et vérifiez que les index des composants sont récupérés.

2) Le paquet existe sur un autre hôte mais pas ici

Symptôme : Même version d’OS, résultat différent.

Cause racine : Différence d’étiquettes de suite (stable vs trixie), miroir différent, ou index obsolètes dus à des avertissements lors de l’update.

Réparation : Comparez /etc/apt/sources.list* et la sortie de apt-get update. Rendre l’update sans avertissements. Utilisez une stratégie de miroir unique.

3) Les paquets du dépôt tiers « disparaissent » après changement de suite

Symptôme : Après la migration vers Debian 13, les paquets fournisseurs sont introuvables.

Cause racine : Le dépôt fournisseur ne publie pas pour trixie (ou publie uniquement sous les codenames, pas sous stable).

Réparation : Réglez Suites: sur le codename supporté par le fournisseur ; si non supporté, n’insistez pas — utilisez la bonne release ou isolez via des conteneurs.

4) « Unable to locate package pkg:i386 » sur amd64

Symptôme : APT ne trouve pas les paquets d’architecture étrangère.

Cause racine : L’architecture i386 n’est pas ajoutée ; les index i386 ne sont pas téléchargés.

Réparation : dpkg --add-architecture i386 puis apt-get update. Vérifiez que les Packages i386 sont récupérés.

5) Typo dans le nom du paquet ou nom obsolète

Symptôme : Tout le monde jure que le nom est correct. Il ne l’est pas.

Cause racine : Le paquet a été renommé/scindé/supprimé entre les suites.

Réparation : Utilisez apt-cache search --names-only et apt-cache showpkg. Mettez à jour l’automatisation avec les nouveaux noms.

6) Le dépôt est présent mais ignoré pour cause de signature

Symptôme : Les lignes du dépôt existent ; l’installation dit que le paquet est introuvable.

Cause racine : Clé GPG manquante ou incorrecte ; signed-by mal configuré ; dépôt considéré comme non fiable.

Réparation : Corrigez le keyring et le chemin Signed-By ; relancez apt-get update jusqu’à obtenir une sortie propre.

7) Entrées dupliquées / formats mixtes provoquant de la confusion

Symptôme : Avertissements sur des cibles configurées plusieurs fois ; candidats incohérents.

Cause racine : Entrées classiques et deb822 qui définissent des dépôts/suites superposés.

Réparation : Consolidez dans une seule approche de configuration. Supprimez les doublons. Relancez update et confirmez l’absence d’avertissements.

8) Miroir interne ou proxy de cache servant des métadonnées périmées

Symptôme : L’update « fonctionne » mais la disponibilité des paquets est incohérente selon le réseau.

Cause racine : Échec de synchronisation du miroir ou sémantique de cache incorrecte pour Release/Packages.

Réparation : Comparez les timestamps, bypasser le proxy pour un test, corriger les jobs de miroir, ajuster les règles de cache, surveiller la fraîcheur des métadonnées.

Listes de contrôle / plan pas à pas

Checklist A: Rendre APT à nouveau digne de confiance (hygiène de base)

1. Exécutez sudo apt-get update. S’il y a des avertissements/erreurs, arrêtez-vous et corrigez-les.
2. Recherchez les doublons et conflits dans votre config de sources :
   • grep -R sur /etc/apt/sources.list*
3. Standardisez une stratégie unique de nommage de suite :
   • Utilisez les codenames pour les environnements de production pin-stable, surtout pour les dépôts tiers.
4. Utilisez des keyrings par dépôt avec signed-by (ou Signed-By en deb822).
5. Documentez pourquoi tout composant non par défaut est activé (non-free-firmware, non-free, contrib).

Checklist B: Diagnostiquer un paquet spécifique manquant

1. Confirmez le codename de l’OS : cat /etc/os-release.
2. Mettez à jour les index proprement : sudo apt-get update.
3. Vérifiez la visibilité du paquet :
   • apt-cache policy <pkg>
   • apt-cache show <pkg>
   • apt-cache search --names-only
4. Confirmez les composants dans vos entrées Debian (main, éventuellement non-free-firmware).
5. Confirmez l’architecture :
   • dpkg --print-architecture
   • dpkg --print-foreign-architectures
6. Si c’est un dépôt tiers, validez le nom de la suite et la confiance de signature pour ce dépôt.

Checklist C: Éviter de réintroduire le problème (flotte/entreprise)

1. Porte CI : faire échouer les builds d’images si apt-get update émet des avertissements.
2. Un fichier canonical de sources, versionné (deb822 préféré pour la clarté).
3. Stratégie de miroir :
   • Soit des miroirs officiels par hôte, soit un miroir/proxy interne avec surveillance — pas « ce qui marche aujourd’hui ».
4. Traitez le multiarch comme un choix délibéré ; ne laissez pas des apps ajouter i386 silencieusement.
5. Audit périodique : dumpez les sources et pins, comparez à travers la flotte.

FAQ

1) Pourquoi apt update réussit mais apt install ne peut pas localiser le paquet ?

Parce que apt update vous dit seulement qu’il a récupéré certains index avec succès. Il se peut que la bonne suite/composant/arch manque, ou que vous utilisiez des index obsolètes après des échecs partiels.

2) Quelle est la façon la plus rapide de savoir si le paquet est dans mes dépôts configurés ?

Exécutez apt-cache policy <pkg>. Si aucune Version table n’apparaît, APT ne le voit pas dans les métadonnées activées.

3) Debian 13 est-il spécial ici, ou c’est juste APT qui reste APT ?

APT reste APT, mais les configs de l’époque Debian 13 incluent plus souvent des sources deb822, des pratiques de keyring plus strictes, et l’usage large de non-free-firmware — tout cela introduit de nouveaux modes de défaillance.

4) Dois-je utiliser stable ou le codename (trixie) dans les sources ?

Pour la production : préférez les codenames pour la déterminisme, surtout pour les dépôts tiers. Les labels conviennent aux machines développeur où le fait d’« avancer » est le but.

5) J’ai activé non-free-firmware. Dois-je aussi activer non-free ?

Non. Activez le minimum nécessaire. Le firmware suffit souvent ; non-free est plus large et implique d’autres compromis.

6) Je suis sur amd64 mais j’ai besoin d’un paquet i386. Pourquoi APT ne le trouve-t-il pas ?

Parce qu’APT ne téléchargera pas les index i386 tant que vous n’aurez pas activé le multiarch avec dpkg --add-architecture i386 et relancé apt-get update.

7) Pourquoi je vois des avertissements sur des doublons, et cela peut-il causer des paquets manquants ?

Les doublons peuvent provoquer une sélection de candidats confuse et masquer de vrais décalages de suite. Ils font aussi mal lire la situation aux humains. Nettoyez-les ; considérez « configuré plusieurs fois » comme un bug.

8) Quelle est la bonne façon de gérer les clés de signature des dépôts tiers maintenant ?

Utilisez un fichier keyring dédié et référencez-le par dépôt avec signed-by= (classique) ou Signed-By: (deb822). Évitez les seaux de confiance globaux et les modèles obsolètes de gestion des clés.

9) Un paquet peut-il manquer parce que mon miroir est désynchronisé ?

Oui. C’est moins fréquent au quotidien, plus courant pendant les transitions. Si un autre miroir le voit et que votre update est propre, suspectez la synchronisation du miroir ou un proxy de cache qui sert des métadonnées périmées.

10) Quand « Unable to locate package » est-ce réellement une faute de frappe ?

Plus souvent que quiconque ne l’admet. Vérifiez avec apt-cache search --names-only et cessez de vous fier à des noms à moitié mémorisés d’anciennes releases.

Conclusion : prochaines étapes que vous pouvez faire aujourd’hui

Résoudre « Unable to locate package » sur Debian 13 concerne rarement le paquet lui-même. Il s’agit de rendre les entrées d’APT correctes : suite, composant, architecture, signatures et métadonnées fraîches.

Faites ceci :

1. Rendez apt-get update sans avertissements. Pas « presque bien ». Propre.
2. Consolidez vos sources en un ensemble cohérent (évitez les conflits silencieux entre classique et deb822).
3. Activez explicitement les composants requis, en particulier non-free-firmware pour le firmware matériel.
4. Vérifiez l’architecture et le multiarch avant de blâmer le dépôt.
5. Si vous gérez un miroir/proxy interne, traitez-le comme une infrastructure de production : surveillez la fraîcheur, pas les impressions.

Une fois que vous pouvez expliquer pourquoi APT voit le monde tel qu’il le fait, « Unable to locate package » cesse d’être une surprise et redevient ce qu’il a toujours été : un audit de configuration avec un tempérament court.