Pourquoi apt-cache affiche installé (aucun) pour votre paquet VPN

Un paquet VPN qui affiche Installed: (none) ne manque pas ; il n’est tout simplement pas installé. La ligne qui décide si vous pouvez l’installer est Candidate, qu’APT déduit des index, du nom de la suite, de l’architecture et de toutes les règles d’épinglage en vigueur. La plupart des signalements d’un paquet VPN disparu se révèlent être un problème de candidat plutôt qu’un problème d’empaquetage. Lisez les deux lignes avant de toucher à une seule entrée de sources.

Je vérifie d’abord le candidat, car cela coûte une seule commande et écarte la moitié des suppositions habituelles.

Ce que vous dit la sortie d’apt-cache policy

apt-cache policy lit le cache local des paquets, pas le réseau. Il imprime la version installée, la version candidate et un tableau de chaque index qui propose le paquet avec la priorité qui lui est attachée.

apt-cache policy openvpn
apt-cache madison openvpn
apt list -a network-manager-openvpn

Le candidat est la version qu’APT choisirait à l’instant. madison liste ce que chaque source propose avec sa priorité, et c’est ainsi que vous repérez un paquet qui existe dans un index mais perd le concours d’épinglage. Le manuel d’apt-cache documente les deux comme des lectures de cache, donc aucun des deux ne prouve que le miroir est joignable en ce moment.

Si la ligne du candidat est vide ou affiche (none), rien dans les sources configurées n’est éligible pour ce système tel qu’il est configuré.

Quatre raisons pour lesquelles un candidat disparaît

En pratique, la cause est presque toujours l’une de quatre choses, et chacune a une correction différente.

Le nom de la suite dans vos sources doit correspondre à la distribution pour laquelle le paquet a été construit. Un système Debian bookworm pointé vers un miroir trixie, ou une version d’Ubuntu renommée dans un fichier sources.list.d lors d’une mise à niveau, ne résout rien pour les paquets qui n’existent que dans l’autre suite. Comparez lsb_release -cs avec le champ suite de chaque entrée.

APT ne voit que les paquets construits pour les architectures que dpkg connaît. Un conteneur 32 bits, une image arm64 ou une installation sur Raspberry Pi qui demande un paquet livré uniquement pour amd64 obtient un candidat vide au lieu d’un message d’erreur. dpkg --print-architecture et dpkg --print-foreign-architectures vous disent dans quel ensemble vous êtes réellement.

Les composants comptent aussi. Un paquet dans contrib ou non-free est invisible quand seul main est activé, et l’universe d’Ubuntu se comporte de la même façon. L’index existe et le paquet y est ; votre liste de composants activés ne l’inclut simplement pas.

L’épinglage est le silencieux. Un fichier dans /etc/apt/preferences.d peut plafonner un paquet sous le seuil d’installation, et un candidat parfaitement valable disparaît alors de la sortie tandis que l’index le liste encore. Comme policy imprime les priorités à côté de chaque source, un paquet dont chaque source porte un numéro d’épinglage bas est l’indice.

Les index périmés ressemblent à des paquets manquants

Le cache est un instantané. Si le dernier apt update a échoué sur un index, les requêtes continuent de répondre depuis la copie plus ancienne, et le paquet que vous attendez peut ne pas s’y trouver.

apt update imprime les erreurs index par index, alors lisez-les plutôt que de faire défiler directement jusqu’à la dernière ligne.

Une actualisation qui échoue sur une erreur de signature, un fichier release expiré ou un miroir injoignable laisse l’index précédent en place. C’est une conception sensée, car elle conserve un cache fonctionnel quand un miroir est brièvement indisponible. L’effet secondaire est qu’une recherche peut réussir alors que le dépôt est hors ligne. Cela signifie aussi que l’absence d’un paquet ne prouve rien tant que vous ne savez pas quand l’index a été récupéré pour la dernière fois. Vérifiez les dates des fichiers sous /var/lib/apt/lists avant d’accuser le nom du paquet.

Nommez le paquet dont vous avez réellement besoin

OpenVPN est un démon, et les pièces que les gens veulent habituellement sont des paquets distincts.

Le moteur, le greffon NetworkManager et l’éditeur de bureau sont trois paquets aux trois noms, et le greffon a une variante GTK dont le nom diffère selon les distributions. apt-cache search --names-only openvpn fait correspondre les noms et les noms fournis plutôt que les descriptions, ce que vous voulez quand vous savez à peu près comment la chose s’appelle.

Si le nom est vraiment inconnu, cherchez une fois dans les descriptions, puis revenez aux noms exacts. N’ajoutez pas un suffixe -gui emprunté à une autre distribution et ne concluez pas que le paquet n’existe plus.

Modifiez les sources en dernier, puis vérifiez la transaction

Ajouter un dépôt change qui fournit vos mises à jour, cela appartient donc à la fin de l’enquête, pas au début.

Avant cela, confirmez la version, l’architecture, le composant et l’état d’épinglage. Notez lesquels des quatre vous avez vérifiés, pour que la personne suivante ne refasse pas le tour. Si les quatre sont corrects et que le candidat manque encore, la conclusion honnête est que cette version ne fournit pas ce paquet. Les options restantes sont un backport, un paquet de fournisseur ou une autre version prise en charge, et chacune est un choix délibéré plutôt qu’une supposition.

Quand le candidat apparaît enfin, simulez avant de valider : apt-get install --simulate avec le nom du paquet montre ce qui serait tiré et ce qui serait supprimé. La disponibilité du paquet, l’installation et un tunnel fonctionnel restent trois étapes distinctes, et le tunnel a encore besoin de son profil, de ses identifiants, de ses routes et du DNS avant de transporter du trafic.