Paquet de dépôt ou paquet client VPN : lequel d’abord ?

Vous installez le paquet du fournisseur, la commande renvoie zéro, et aucune application VPN ne se lance pour autant. C’est ce qui arrive lorsque le paquet installé a configuré un dépôt au lieu de fournir le client, et la différence se voit dans ce qu’il a déposé sur le disque. Le besoin des deux, et leur ordre, dépend de trois conditions et non du nom donné par le fournisseur. La décision ci-dessous garde la mise en place de la source, l’actualisation des métadonnées et l’installation de l’application comme des actes distincts, avec des preuves distinctes.

Ce que chaque paquet change réellement

Un paquet de configuration de dépôt écrit une entrée de source APT, importe la clé de signature à laquelle cette entrée fait confiance, puis se termine. Sa charge utile se limite à quelques fichiers sous /etc/apt et à un trousseau de clés, sans rien d’exécutable. Un paquet client fournit le démon ou l’application de bureau, ses bibliothèques et ses dépendances, et c’est l’objet qui finit dans un menu ou dans une unité systemd.

Les noms de fichiers se terminant par -release suggèrent le premier type, mais le suffixe est une convention, pas une garantie. L’affirmation fiable sur le rôle d’un paquet est sa liste de fichiers et ses dépendances, toutes deux lisibles avant toute installation. Un fournisseur qui remodèle son empaquetage garde le même nom de fichier et change le contenu, si bien qu’une réponse copiée d’un fil vieux de deux ans peut décrire un paquet qui n’existe plus. Lisez les instructions actuelles du fournisseur pour la version que vous exécutez, puis vérifiez ce que le paquet déclare.

Trois étapes découlent de cette séparation : enregistrer la source, actualiser les métadonnées qu’elle alimente, puis installer l’application par son nom. Le guide d’installation pour Debian et Ubuntu les garde séparées, ce qui explique pourquoi le client est demandé à une étape ultérieure plutôt que par le paquet qui a mis en place la source.

Trois conditions qui décident de l’ordre

La première condition est de savoir si le fournisseur publie un dépôt pour la version exacte de votre distribution. Une ligne de source construite pour une suite peut se résoudre contre les dépendances d’une autre suite et installer un mélange que personne n’a testé.

La deuxième est de savoir si votre distribution fournit déjà le client. Quand c’est le cas, le paquet de la distribution suit les transitions de bibliothèques et les mises à jour de sécurité de votre version, tandis que le paquet du fournisseur peut avancer plus vite et apporter ses propres copies de bibliothèques partagées.

La troisième est de savoir de quelles fonctionnalités vous avez réellement besoin. Une version du fournisseur peut fournir une implémentation de protocole plus récente ou une intégration de bureau que votre distribution n’a pas empaquetée, et c’est une vraie raison d’accepter une seconde source. Si la version de la distribution couvre votre usage, ajouter un dépôt tiers coûte du travail de mise à jour et une relation de confiance supplémentaire pour bien peu.

Tranchez ces trois réponses avant que la ligne de source existe, car la retirer plus tard impose de purger le paquet et sa clé. Une fois les réponses fixées, la séquence dans la voie du fournisseur n’est pas un choix : la source d’abord, les métadonnées ensuite, l’application en troisième, jamais l’inverse.

Vérifiez ce que le paquet de publication a laissé

Avant d’installer quoi que ce soit d’autre, lisez la liste des fichiers plutôt que la description. Sur les systèmes de la famille Debian, le manifeste du paquet répond à ce qu’il a configuré et à l’emplacement de la clé.

dpkg -L proton-vpn-release | grep -E 'apt|keyring'
apt-cache policy proton-vpn-gnome-desktop
grep -r protonvpn /etc/apt/sources.list.d/

La première ligne montre le fichier de source et le chemin du trousseau, tandis que la deuxième indique quelle version les sources configurées peuvent proposer. Si apt-cache policy n’affiche rien pour le nom du client, l’actualisation des métadonnées n’a pas eu lieu ou la source cible une autre suite. La troisième confirme que l’entrée se trouve là où APT lit réellement.

Faites correspondre le chemin du trousseau au champ signed-by= de la ligne de source. Une clé placée dans le mauvais répertoire produit une erreur de source non authentifiée, qui est une panne différente d’un paquet indisponible.

Traitez un échec de dépendance comme une étape à part

Installer un .deb téléchargé avec dpkg -i ne résout rien : il vérifie les dépendances, signale ce qui manque et laisse le paquet à moitié configuré. C’est le comportement attendu, pas un téléchargement corrompu.

apt --fix-broken install demande ensuite à APT un état cohérent à partir des sources dont vous disposez. APT ne sait pas quel VPN vous vouliez, et son plan peut supprimer des paquets pour satisfaire la contrainte qu’il a trouvée. Lisez la transaction proposée avant de répondre oui, et arrêtez-vous si les suppressions touchent quelque chose dont vous avez besoin. Répéter la réparation sans lire le plan, c’est ainsi qu’un petit manque de dépendance devient un bureau qui ne démarre plus.

Conservez le premier message significatif du gestionnaire de paquets et classez-le avant d’agir. Un dépôt non signé, un paquet absent des sources configurées, un conflit de version et un client qui démarre puis meurt sont quatre pannes distinctes.

Vérifiez l’application, pas le dépôt

Confirmez que le client a atteint l’état installé, puis confirmez que le programme démarre. dpkg-query -W -f='${Status} ${Version}' proton-vpn-gnome-desktop doit signaler install ok installed avec une version, et un échec de lancement ensuite est un problème d’application, non d’empaquetage.

Consignez le propriétaire du dépôt et le paquet d’application comme deux objets distincts, afin qu’une suppression ultérieure retire le bon et laisse l’autre intact. Quand le fournisseur change son guide, l’entrée de source est ce que vous relisez ; le nom du client est ce que vous réinstallez.