Pacchetto repository o pacchetto client VPN: quale viene prima?

Installi il pacchetto del fornitore, il comando restituisce zero e non c’è ancora nessuna applicazione VPN da avviare. Succede quando il pacchetto installato ha configurato un repository invece di fornire il client, e la differenza si vede in ciò che ha lasciato sul disco. Se servano entrambi, e in quale ordine, dipende da tre condizioni e non dalla denominazione del fornitore. La decisione qui sotto tiene la configurazione della sorgente, l’aggiornamento dei metadati e l’installazione dell’applicazione come atti separati, con prove separate.

Cosa cambia davvero ogni pacchetto

Un pacchetto di configurazione del repository scrive una voce di sorgente APT, importa la chiave di firma di cui quella voce si fida e termina. Il suo contenuto è un paio di file sotto /etc/apt più un portachiavi, e nulla di eseguibile. Un pacchetto client fornisce il demone o l’applicazione desktop, le sue librerie e le sue dipendenze, ed è l’oggetto che finisce in un menu o in un’unità systemd.

I nomi di file che terminano con -release suggeriscono il primo tipo, ma il suffisso è una convenzione, non una garanzia. L’affermazione affidabile sul ruolo di un pacchetto è il suo elenco di file e le sue dipendenze, entrambi leggibili prima di installare qualsiasi cosa. Un fornitore che rimodella il proprio packaging mantiene lo stesso nome di file e cambia il contenuto, quindi una risposta copiata da un thread di due anni fa può descrivere un pacchetto che non esiste più. Leggi le istruzioni attuali del fornitore per la release che esegui, poi controlla cosa dichiara il pacchetto.

Da quella separazione seguono tre fasi: registra la sorgente, aggiorna i metadati che alimenta, poi installa l’applicazione per nome. La guida all’installazione per Debian e Ubuntu le tiene separate, ed è per questo che il client viene richiesto in un passaggio successivo e non dal pacchetto che ha impostato la sorgente.

Tre condizioni che decidono l’ordine

La prima condizione è se il fornitore pubblichi un repository per la tua esatta release della distribuzione. Una riga di sorgente costruita per una suite può risolversi contro le dipendenze di un’altra suite e installare un misto che nessuno ha provato.

La seconda è se la tua distribuzione porta già il client. Quando lo fa, il pacchetto della distribuzione segue le transizioni delle librerie e gli aggiornamenti di sicurezza della tua release, mentre il pacchetto del fornitore può muoversi più in fretta e portare proprie copie delle librerie condivise.

La terza è quali funzionalità ti servono davvero. Una build del fornitore può fornire un’implementazione di protocollo più recente o un’integrazione desktop che la tua distribuzione non ha pacchettizzato, ed è una ragione reale per accettare una seconda sorgente. Se la build della distribuzione copre il tuo uso, aggiungere un repository di terze parti compra lavoro di aggiornamento e un’altra relazione di fiducia per molto poco.

Risolvi queste tre risposte prima che la riga di sorgente esista, perché rimuoverla dopo significa ripulire il pacchetto e la sua chiave. Una volta risolte, la sequenza dentro il percorso del fornitore non è una scelta: sorgente prima, metadati secondi, applicazione terza, mai il contrario.

Controlla cosa ha lasciato il pacchetto di rilascio

Prima di installare altro, leggi l’elenco dei file invece della descrizione. Sui sistemi della famiglia Debian il manifesto del pacchetto risponde a cosa ha configurato e dove è finita la chiave.

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 prima riga mostra il file di sorgente e il percorso del portachiavi, mentre la seconda riporta quale versione possono offrire le sorgenti configurate. Se apt-cache policy non stampa nulla per il nome del client, l’aggiornamento dei metadati non è avvenuto o la sorgente punta a un’altra suite. La terza conferma che la voce si trova dove APT legge davvero.

Fai corrispondere il percorso del portachiavi al campo signed-by= della riga di sorgente. Una chiave nella directory sbagliata produce un errore di sorgente non autenticata, che è un guasto diverso da un pacchetto non disponibile.

Tratta un errore di dipendenza come una fase separata

Installare un .deb scaricato con dpkg -i non risolve nulla: controlla le dipendenze, segnala ciò che manca e lascia il pacchetto mezzo configurato. È il comportamento atteso, non un download corrotto.

apt --fix-broken install chiede poi ad APT uno stato coerente dalle sorgenti che hai. APT non sa quale VPN volessi, e il suo piano può rimuovere pacchetti per soddisfare il vincolo trovato. Leggi la transazione proposta prima di rispondere sì, e fermati se le rimozioni toccano qualcosa che ti serve. Ripetere la riparazione senza leggere il piano è il modo in cui un piccolo vuoto di dipendenze diventa un desktop che non si avvia più.

Conserva il primo messaggio significativo del gestore di pacchetti e classificarlo prima di agire. Un repository non firmato, un pacchetto che le sorgenti configurate non contengono, un conflitto di versioni e un client che si avvia e poi muore sono quattro guasti distinti.

Verifica l’applicazione, non il repository

Conferma che il client abbia raggiunto lo stato installato, poi conferma che il programma si avvii. dpkg-query -W -f='${Status} ${Version}' proton-vpn-gnome-desktop dovrebbe riportare install ok installed con una versione, e un fallimento di avvio dopo è un problema dell’applicazione e non del packaging.

Registra il proprietario del repository e il pacchetto dell’applicazione come oggetti separati, così una rimozione successiva toglie quello giusto e lascia l’altro intatto. Quando il fornitore cambia la sua guida, la voce di sorgente è ciò che rileggi; il nome del client è ciò che reinstalli.