Sie installieren das Anbieterpaket, der Befehl gibt null zurück, und trotzdem gibt es keine VPN-Anwendung zum Starten. Das passiert, wenn das installierte Paket ein Repository eingerichtet hat, statt den Client mitzuliefern, und der Unterschied zeigt sich darin, was es auf der Platte abgelegt hat. Ob Sie beides brauchen und in welcher Reihenfolge, hängt von drei Bedingungen ab und nicht von der Benennung des Anbieters. Die Entscheidung unten hält Quelleneinrichtung, Metadaten-Aktualisierung und Anwendungsinstallation als getrennte Schritte mit getrennten Belegen.

Was jedes Paket tatsächlich ändert

Ein Repository-Konfigurationspaket schreibt einen APT-Quelleneintrag, importiert den Signaturschlüssel, dem dieser Eintrag vertraut, und beendet sich. /etc/apt Sein Inhalt sind ein paar Dateien plus ein Schlüsselbund, und nichts, was Sie ausführen können. Ein Clientpaket liefert den Daemon oder die Desktop-Anwendung, ihre Bibliotheken und ihre Abhängigkeiten, und es ist das Objekt, das in einem Menü oder in einer systemd-Unit landet.

Dateinamen, die auf -release enden, deuten auf die erste Art hin, aber die Endung ist eine Konvention und keine Garantie. Die verlässliche Aussage über die Rolle eines Pakets sind seine Dateiliste und seine Abhängigkeiten, beides lesbar, bevor Sie etwas installieren. Ein Anbieter, der seine Paketierung umbaut, behält denselben Dateinamen und ändert den Inhalt, sodass eine aus einem zwei Jahre alten Thread kopierte Antwort ein Paket beschreiben kann, das es nicht mehr gibt. Lesen Sie die aktuellen Anweisungen des Anbieters für Ihr Release und prüfen Sie dann, was das Paket deklariert.

Aus dieser Trennung folgen drei Stufen: die Quelle registrieren, die Metadaten aktualisieren, die sie speist, dann die Anwendung namentlich installieren. Die Installationsanleitung für Debian und Ubuntu hält sie getrennt, weshalb der Client in einem späteren Schritt angefordert wird und nicht durch das Paket, das die Quelle eingerichtet hat.

Drei Bedingungen, die die Reihenfolge entscheiden

Die erste Bedingung ist, ob der Anbieter ein Repository für genau Ihr Distributions-Release veröffentlicht. Eine für ein Release gebaute Quellenzeile kann sich gegen die Abhängigkeiten eines anderen Releases auflösen und eine Mischung installieren, die niemand getestet hat.

Die zweite ist, ob Ihre Distribution den Client bereits mitbringt. Wenn ja, folgt das Distributionspaket den Bibliotheksübergängen und Sicherheitsaktualisierungen Ihres Releases, während das Anbieterpaket schneller sein kann und eigene Kopien gemeinsamer Bibliotheken mitbringt.

Die dritte ist, welche Funktionen Sie tatsächlich brauchen. Ein Anbieter-Build kann eine neuere Protokollimplementierung oder eine Desktop-Integration mitbringen, die Ihre Distribution nicht gepackt hat, und das ist ein echter Grund, eine zweite Quelle zu akzeptieren. Deckt der Distributions-Build Ihren Bedarf, kauft ein Drittanbieter-Repository Aktualisierungsarbeit und eine weitere Vertrauensbeziehung für sehr wenig.

Klären Sie diese drei Antworten, bevor die Quellenzeile existiert, denn sie später zu entfernen bedeutet, das Paket und seinen Schlüssel zu bereinigen. Sind sie geklärt, ist die Reihenfolge im Anbieterweg keine Wahl: Quelle zuerst, Metadaten zweitens, Anwendung drittens, nie umgekehrt.

Prüfen Sie, was das Release-Paket hinterlassen hat

Lesen Sie, bevor Sie etwas anderes installieren, die Dateiliste statt der Beschreibung. Auf Systemen der Debian-Familie beantwortet das Paketmanifest, was es konfiguriert hat und wo der Schlüssel gelandet ist.

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

Die erste Zeile zeigt die Quelldatei und den Pfad des Schlüsselbunds, während die zweite meldet, welche Version die konfigurierten Quellen anbieten können. Wenn apt-cache policy nichts für den Clientnamen ausgibt, hat die Metadaten-Aktualisierung nicht stattgefunden oder die Quelle zielt auf ein anderes Release. Die dritte bestätigt, dass der Eintrag dort steht, wo APT tatsächlich liest.

Vergleichen Sie den Pfad des Schlüsselbunds mit dem Feld signed-by= in der Quellenzeile. Ein Schlüssel im falschen Verzeichnis erzeugt einen Fehler über eine nicht authentifizierte Quelle, und das ist ein anderer Fehler als ein nicht verfügbares Paket.

Behandeln Sie einen Abhängigkeitsfehler als eigene Stufe

Die Installation einer heruntergeladenen .deb mit dpkg -i löst nichts: Sie prüft Abhängigkeiten, meldet, was fehlt, und lässt das Paket halbkonfiguriert zurück. Das ist erwartetes Verhalten und kein beschädigter Download.

apt --fix-broken install fordert dann von APT einen konsistenten Zustand aus den Quellen, die Sie haben. APT weiß nicht, welches VPN Sie wollten, und sein Plan kann Pakete entfernen, um die gefundene Einschränkung zu erfüllen. Lesen Sie die vorgeschlagene Transaktion, bevor Sie ja antworten, und hören Sie auf, wenn die Entfernungen etwas treffen, das Sie brauchen. Die Reparatur zu wiederholen, ohne den Plan zu lesen, ist der Weg, auf dem eine kleine Abhängigkeitslücke zu einem Desktop wird, der nicht mehr startet.

Behalten Sie die erste aussagekräftige Meldung des Paketmanagers und klassifizieren Sie sie, bevor Sie handeln. Ein unsigniertes Repository, ein Paket, das die konfigurierten Quellen nicht führen, ein Versionskonflikt und ein Client, der startet und dann stirbt, sind vier getrennte Fehler.

Prüfen Sie die Anwendung, nicht das Repository

Bestätigen Sie, dass der Client den installierten Zustand erreicht hat, und bestätigen Sie dann, dass das Programm startet. dpkg-query -W -f='${Status} ${Version}' proton-vpn-gnome-desktop sollte install ok installed mit einer Version melden, und ein Startfehler danach ist ein Anwendungsproblem und kein Paketierungsproblem.

Halten Sie Repository-Eigentümer und Anwendungspaket als getrennte Objekte fest, damit eine spätere Entfernung das richtige erwischt und das andere unangetastet lässt. Wenn der Anbieter seine Anleitung ändert, ist der Quelleneintrag das, was Sie neu lesen; der Clientname ist das, was Sie neu installieren.

Ähnliche Artikel