Paquet del repositori o paquet de client VPN: què arriba primer?
Un paquet d’alliberament només registra una font i una clau de signatura. Decidiu si el repositori del proveïdor val la pena i després instal·leu el client com a pas propi.
Instal·leu el paquet del proveïdor, l’ordre retorna zero i encara no hi ha cap aplicació VPN per engegar. Això passa quan el paquet que heu instal·lat ha configurat un repositori en lloc d’incloure el client, i la diferència es veu en el que ha deixat al disc. Si us calen tots dos i en quin ordre depèn de tres condicions, no del nom que els doni el proveïdor. La decisió de sota manté la configuració de la font, l’actualització de les metadades i la instal·lació de l’aplicació com a actes separats amb proves separades.
Què canvia realment cada paquet
Un paquet de configuració de repositori escriu una entrada de font d’APT, importa la clau de signatura en què confia aquesta entrada i acaba. /etc/apt La seva càrrega és un parell de fitxers i un anell de claus, i res que pugueu executar. Un paquet de client inclou el dimoni o l’aplicació d’escriptori, les seves biblioteques i les seves dependències, i és l’objecte que acaba en un menú o en una unitat de systemd.
Els noms de fitxer que acaben en -release suggereixen el primer tipus, però el sufix és una convenció, no una garantia. L’afirmació fiable sobre el paper d’un paquet és la seva llista de fitxers i les seves dependències, totes dues llegibles abans d’instal·lar res. Un proveïdor que reorganitza el seu empaquetatge manté el mateix nom de fitxer i canvia el contingut, així que una resposta copiada d’un fil de fa dos anys pot descriure un paquet que ja no existeix. Llegiu les instruccions actuals del proveïdor per a l’alliberament que feu servir i després comproveu què declara el paquet.
D’aquesta divisió se’n deriven tres etapes: registreu la font, actualitzeu les metadades que alimenta i instal·leu després l’aplicació pel nom. La guia d’instal·lació a Debian i Ubuntu les manté separades, i per això el client es demana en un pas posterior i no pel paquet que va configurar la font.
Tres condicions que decideixen l’ordre
La primera condició és si el proveïdor publica un repositori per a la vostra versió exacta de distribució. Una línia de font feta per a un alliberament pot resoldre’s contra les dependències d’un altre alliberament i instal·lar una barreja que ningú no ha provat.
La segona és si la vostra distribució ja porta el client. Quan el porta, el paquet de la distribució segueix les transicions de biblioteques i les actualitzacions de seguretat del vostre alliberament, mentre que el paquet del proveïdor pot moure’s més de pressa i portar les seves pròpies còpies de biblioteques compartides.
La tercera és quines funcions necessiteu de debò. Una compilació del proveïdor pot incloure una implementació més nova d’un protocol o una integració d’escriptori que la vostra distribució no ha empaquetat, i això és un motiu real per acceptar una segona font. Si la compilació de la distribució cobreix el vostre ús, afegir un repositori de tercers compra feina d’actualització i una altra relació de confiança per molt poc.
Resoleu aquestes tres respostes abans que existeixi la línia de font, perquè treure-la després vol dir purgar el paquet i la seva clau. Un cop resoltes, la seqüència dins del camí del proveïdor no és una tria: font primer, metadades segon, aplicació tercer, mai al revés.
Comproveu què ha deixat el paquet d’alliberament
Abans d’instal·lar res més, llegiu la llista de fitxers en lloc de la descripció. En sistemes de la família Debian el manifest del paquet respon què ha configurat i on ha anat a parar la clau.
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 primera línia mostra el fitxer de font i el camí de l’anell de claus, mentre que la segona informa de quina versió poden oferir les fonts configurades. Si apt-cache policy no imprimeix res per al nom del client, l’actualització de metadades no s’ha fet o la font apunta a un altre alliberament. La tercera confirma que l’entrada és on APT realment llegeix.
Feu coincidir el camí de l’anell de claus amb el camp signed-by= de la línia de font. Una clau al directori equivocat produeix un error de font no autenticada, que és una fallada diferent d’un paquet no disponible.
Tracteu una fallada de dependències com una etapa a part
Instal·lar un .deb amb dpkg -i no resol res: comprova les dependències, informa del que falta i deixa el paquet mig configurat. És un comportament esperat, no una baixada corrupta.
apt --fix-broken install després demana a APT un estat coherent a partir de les fonts que teniu. APT no sap quin VPN volíeu i el seu pla pot treure paquets per satisfer la restricció que ha trobat. Llegiu la transacció proposada abans de respondre que sí i atureu-vos si les eliminacions toquen res que necessiteu. Repetir la reparació sense llegir el pla és com una petita llacuna de dependències es converteix en un escriptori que ja no arrenca.
Guardeu el primer missatge amb sentit del gestor de paquets i classifiqueu-lo abans d’actuar. Un repositori sense signatura, un paquet que les fonts configurades no porten, un conflicte de versions i un client que arrenca i després mor són quatre fallades separades.
Verifiqueu l’aplicació, no el repositori
Confirmeu que el client ha arribat a l’estat instal·lat i després confirmeu que el programa arrenca. dpkg-query -W -f='${Status} ${Version}' proton-vpn-gnome-desktop ha d’informar de install ok installed amb una versió, i una fallada d’engegada després d’això és un problema d’aplicació, no d’empaquetatge.
Registreu el propietari del repositori i el paquet de l’aplicació com a objectes separats, perquè una eliminació posterior tregui el correcte i deixi l’altre intacte. Quan el proveïdor canvia la seva guia, l’entrada de font és el que rellegiu; el nom del client és el que reinstal·leu.