Perché apt-cache mostra installato (nessuno) per il vostro pacchetto VPN

Un pacchetto VPN che riporta Installed: (none) non manca; semplicemente non è installato. La riga che decide se potete installarlo è Candidate, che APT ricava dagli indici, dal nome della suite, dall’architettura e da qualsiasi regola di fissaggio in vigore. La maggior parte delle segnalazioni di un pacchetto VPN scomparso si rivela un problema di candidato e non un problema di pacchettizzazione. Leggete entrambe le righe prima di toccare una sola voce delle sorgenti.

Controllo prima il candidato perché costa un solo comando e scarta metà delle supposizioni abituali.

Che cosa vi dice l’output di apt-cache policy

apt-cache policy legge la cache locale dei pacchetti, non la rete. Stampa la versione installata, la versione candidata e una tabella di ogni indice che offre il pacchetto con la priorità associata.

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

Il candidato è la versione che APT sceglierebbe in questo momento. madison elenca ciò che ogni sorgente offre con la sua priorità, ed è così che si individua un pacchetto che esiste in un indice ma perde la competizione di fissaggio. Il manuale di apt-cache documenta entrambi come letture della cache, quindi nessuno dei due dimostra che lo specchio sia raggiungibile in questo momento.

Se la riga del candidato è vuota o mostra (none), nulla nelle sorgenti configurate è idoneo per questo sistema così com’è configurato.

Quattro motivi per cui un candidato scompare

In pratica la causa è quasi sempre una di quattro cose, e ciascuna ha una correzione diversa.

Il nome della suite nelle vostre sorgenti deve corrispondere alla distribuzione per cui il pacchetto è stato compilato. Un sistema Debian bookworm puntato a uno specchio trixie, o una versione di Ubuntu rinominata in un file sources.list.d durante un aggiornamento, non risolve nulla per i pacchetti che esistono solo nell’altra suite. Confrontate lsb_release -cs con il campo suite di ogni voce.

APT vede solo i pacchetti compilati per le architetture che dpkg conosce. Un contenitore a 32 bit, un’immagine arm64 o un’installazione su Raspberry Pi che chiede un pacchetto distribuito solo per amd64 ottengono un candidato vuoto invece di un messaggio di errore. dpkg --print-architecture e dpkg --print-foreign-architectures vi dicono in quale insieme siete realmente.

Anche i componenti contano. Un pacchetto in contrib o non-free è invisibile quando è abilitato solo main, e l’universe di Ubuntu si comporta allo stesso modo. L’indice esiste e il pacchetto è lì; semplicemente il vostro elenco di componenti abilitati non lo include.

Il fissaggio è quello silenzioso. Un file in /etc/apt/preferences.d può limitare un pacchetto sotto la soglia di installazione, e allora un candidato perfettamente valido scompare dall’output mentre l’indice lo elenca ancora. Poiché policy stampa le priorità accanto a ogni sorgente, un pacchetto in cui ogni sorgente porta un numero di fissaggio basso è l’indizio.

Gli indici obsoleti sembrano pacchetti mancanti

La cache è un’istantanea. Se l’ultimo apt update è fallito su un indice, le query continuano a rispondere dalla copia più vecchia, e il pacchetto che vi aspettate potrebbe non essere in quella copia.

apt update stampa gli errori per indice, quindi leggeteli invece di scorrere subito all’ultima riga.

Un aggiornamento che fallisce per un errore di firma, un file release scaduto o uno specchio irraggiungibile lascia l’indice precedente al suo posto. È un progetto sensato, perché conserva una cache funzionante quando uno specchio è brevemente inattivo. L’effetto collaterale è che una ricerca può riuscire mentre il repository è offline. Significa anche che l’assenza di un pacchetto non dimostra nulla finché non sapete quando l’indice è stato scaricato l’ultima volta. Controllate le date dei file sotto /var/lib/apt/lists prima di incolpare il nome del pacchetto.

Nominate il pacchetto che vi serve davvero

OpenVPN è un demone, e i pezzi che la gente di solito vuole sono pacchetti separati.

Il motore, il plugin di NetworkManager e l’editor del desktop sono tre pacchetti con tre nomi, e il plugin ha una variante GTK il cui nome differisce tra le distribuzioni. apt-cache search --names-only openvpn confronta nomi e nomi forniti invece delle descrizioni, ed è ciò che volete quando sapete all’incirca come si chiama la cosa.

Se il nome è davvero sconosciuto, cercate una volta nelle descrizioni e poi tornate ai nomi esatti. Non aggiungete un suffisso -gui preso da un’altra distribuzione e non concludete che il pacchetto non esista più.

Modificate le sorgenti per ultime, poi verificate la transazione

Aggiungere un repository cambia chi fornisce i vostri aggiornamenti, quindi appartiene alla fine dell’indagine, non all’inizio.

Prima, confermate versione, architettura, componente e stato del fissaggio. Annotate quali dei quattro avete controllato, così la persona successiva non ripete il giro. Se tutti e quattro sono corretti e il candidato manca ancora, la conclusione onesta è che questa versione non distribuisce quel pacchetto. Le opzioni rimanenti sono un backport, un pacchetto del fornitore o un’altra versione supportata, e ciascuna è una scelta deliberata e non una congettura.

Quando il candidato compare, simulate prima di confermare: apt-get install --simulate con il nome del pacchetto mostra cosa verrebbe tirato dentro e cosa rimosso. Disponibilità del pacchetto, installazione e un tunnel funzionante restano tre fasi separate, e il tunnel ha ancora bisogno del suo profilo, delle credenziali, delle rotte e del DNS prima di trasportare traffico.