Risoluzione dei problemi di APT in Ubuntu: correzione di pacchetti rotti, Holds ed errori GPG

I guasti di APT sono comuni nelle macchine Ubuntu di lunga durata e di solito si manifestano dopo un aggiornamento di rilascio, una modifica di un repository di terze parti, la rimozione di un PPA, un’installazione manuale di un pacchetto .deb o un’installazione di pacchetti interrotta.

Il messaggio di errore può sembrare drammatico, ma la maggior parte dei problemi di APT non è misteriosa: si tratta di problemi di stato in cui la visione di APT riguardo a repository, versioni e pacchetti installati non è più coerente.

APT cerca di rispondere a quattro domande:

1. Quali repository sono abilitati?
2. Quali versioni dei pacchetti sono disponibili?
3. Quali pacchetti sono già installati?
4. Quali modifiche ai pacchetti sono consentite?

Quando queste risposte sono in conflitto, si ottengono pacchetti trattenuti, dipendenze rotte, chiavi pubbliche mancanti, errori di PPA invalidi o pacchetti trattenuti durante l’aggiornamento. Questa guida offre una sequenza pratica di risoluzione dei problemi per APT su Ubuntu, scritta per sviluppatori, ingegneri DevOps e utenti Linux che desiderano risolvere il sistema senza incollare ciecamente comandi casuali presi da thread dei forum. Abbinatela al nostro riassunto dei comandi rapidi per Ubuntu APT e dpkg per i comandi quotidiani di installazione e aggiornamento, e sfoglia la raccolta più ampia di Strumenti per Sviluppatori per flussi di lavoro Linux correlati.

La versione breve

Se il tuo sistema è solo leggermente danneggiato, inizia da qui:

sudo apt update
sudo dpkg --configure -a
sudo apt --fix-broken install
sudo apt update
sudo apt upgrade

Se i pacchetti sono trattenuti:

apt list --upgradable
apt-mark showhold
sudo apt full-upgrade

Se un PPA o un repository di terze parti non funziona:

ls /etc/apt/sources.list.d/
sudo apt update

Leggi la riga del repository che fallisce, quindi disabilita o correggi quel repository. Se vedi NO_PUBKEY, non importare ciecamente chiavi casuali da un keyserver: trova le istruzioni ufficiali del repository, installa la chiave del repository in /etc/apt/keyrings e associala a quel repository con signed-by.

Prima di riparare qualsiasi cosa: leggi l’errore di APT

Esegui prima questo:

sudo apt update

Non saltarlo. apt update aggiorna i metadati dei pacchetti. Non aggiorna i pacchetti stessi. Ti dice se Ubuntu può leggere tutti i repository configurati e verificare i loro metadati.

Quindi controlla la tua versione di Ubuntu e il suo nome in codice: un nome di rilascio obsoleto in /etc/apt/sources.list.d/ è una causa frequente di errori 404 e del file Release. Se non sei sicuro quale rilascio stai utilizzando, consulta come verificare la versione di Ubuntu:

lsb_release -a

Oppure:

cat /etc/os-release

Controlla anche cosa è aggiornabile:

apt list --upgradable

E controlla se qualche pacchetto è trattenuto:

apt-mark showhold

Questo ti dà la prima suddivisione nell’albero delle decisioni: identificare prima la classe del guasto rende più facile la risoluzione dei problemi perché ciascuna classe ha una riparazione iniziale diversa:

• Problema di repository: apt update fallisce.
• Problema di dipendenze: apt update funziona, ma l’installazione o l’aggiornamento fallisce.
• Problema di pacchetto trattenuto: APT si rifiuta di modificare pacchetti specifici.
• Problema di sorgente mista: un PPA, un .deb manuale o un vecchio repository fornisce versioni incompatibili.
• Problema di installazione interrotta: dpkg ha estratto pacchetti che non sono mai stati configurati.

Tipi comuni di guasti di APT su Ubuntu

Pacchetti trattenuti

Un pacchetto trattenuto non è sempre un errore; significa che APT ha scelto di non aggiornare un pacchetto utilizzando il comando corrente. Questo accade spesso quando l’aggiornamento richiede l’installazione di nuove dipendenze, la rimozione di vecchi pacchetti o la modifica di un pacchetto in un modo che il semplice apt upgrade non eseguirà.

Controlla i dettagli:

apt list --upgradable
apt-cache policy package-name

Prova un aggiornamento completo solo dopo aver letto cosa APT vuole fare:

sudo apt full-upgrade

full-upgrade è autorizzato a installare nuovi pacchetti e rimuovere pacchetti se necessario per completare l’aggiornamento. Questo è utile, ma è anche il motivo per cui dovresti leggere le modifiche proposte prima di accettarle. Su una workstation, full-upgrade è solitamente accettabile dopo la revisione; su un server, leggi le rimozioni due volte.

Pacchetti trattenuti (hold)

Un pacchetto trattenuto (hold) è diverso da un pacchetto che è semplicemente trattenuto (kept back). Un hold è un’istruzione esplicita che impedisce ad APT di installare, aggiornare o rimuovere automaticamente quel pacchetto. Gli hold sono utili per fissare una versione di kernel, database, driver o runtime, e sono anche facili da dimenticare.

Elenco dei pacchetti trattenuti:

apt-mark showhold

Tratteni un pacchetto:

sudo apt-mark hold package-name

Rimuovi un hold:

sudo apt-mark unhold package-name

Se vedi errori di dipendenza che coinvolgono un pacchetto trattenuto, decidi se l’hold è ancora intenzionale. Non rimuovere gli hold automaticamente. Potrebbero proteggere un servizio di produzione, un driver o una toolchain sensibile alla compatibilità.

Dipendenze rotte

Le dipendenze rotte significano che APT non può trovare un set di pacchetti valido, il che di solito indica un conflitto di versione piuttosto che un download corrotto.

Le cause comuni includono:

• Un pacchetto richiede una versione non disponibile.
• Un PPA fornisce una libreria più recente di quella prevista da Ubuntu.
• Un .deb installato manualmente dipende da pacchetti di un altro rilascio.
• L’installazione di un pacchetto è stata interrotta.
• Un repository per il rilascio sbagliato di Ubuntu è abilitato.
• Il pinning dei pacchetti o gli hold impediscono la modifica della versione necessaria.

Inizia con:

sudo dpkg --configure -a
sudo apt --fix-broken install

Quindi ispeziona il pacchetto:

apt-cache policy package-name
apt-cache depends package-name
apt-cache rdepends package-name

Quindi usa questi comandi per trovare il conflitto di versione del pacchetto che sta bloccando APT, invece di eseguire ogni comando di riparazione in sequenza.

Errori di chiave GPG e NO_PUBKEY

Un errore NO_PUBKEY significa che APT ha ricevuto i metadati del repository, ma non può verificare la firma perché la chiave pubblica richiesta manca: un problema di fiducia, non solo un problema di download.

Un errore tipico sembra questo:

The following signatures could not be verified because the public key is not available: NO_PUBKEY ABCD1234EF567890

Le vecchie istruzioni usavano spesso apt-key add, ma evita questo per la configurazione di nuovi repository. I sistemi Ubuntu moderni dovrebbero utilizzare un keyring specifico per il repository e signed-by.

Un modello migliore è questo:

sudo install -d -m 0755 /etc/apt/keyrings

curl -fsSL https://example.com/repo-key.gpg \
  | sudo gpg --dearmor -o /etc/apt/keyrings/example.gpg

echo "deb [signed-by=/etc/apt/keyrings/example.gpg] https://example.com/apt stable main" \
  | sudo tee /etc/apt/sources.list.d/example.list

sudo apt update

Sostituisci l’URL e la riga del repository con le istruzioni ufficiali del fornitore.

La parte importante è questa:

signed-by=/etc/apt/keyrings/example.gpg

Quella riga signed-by associa la chiave a un singolo repository, il che è più pulito e sicuro rispetto a mettere ogni chiave di terze parti in un archivio di fiducia globale.

Errori di PPA o file Release non validi

I guasti del PPA spesso sembrano così:

The repository does not have a Release file.

Oppure:

404 Not Found

Cause comuni:

• Il PPA non supporta il tuo rilascio di Ubuntu.
• Hai aggiornato Ubuntu, ma il PPA punta ancora al vecchio nome in codice.
• Il PPA è stato eliminato.
• Il mantentore ha smesso di pubblicare pacchetti.
• Hai aggiunto un PPA destinato a una versione diversa di Ubuntu.

Controlla il tuo nome in codice:

. /etc/os-release
echo "$VERSION_CODENAME"

Elenco dei file di origine di terze parti:

ls /etc/apt/sources.list.d/

Ispezionali:

grep -R "^deb" /etc/apt/sources.list /etc/apt/sources.list.d/

Disabilita una sorgente sospetta rinominandola:

sudo mv /etc/apt/sources.list.d/example.list /etc/apt/sources.list.d/example.list.disabled
sudo apt update

Se APT funziona dopo aver disabilitato il file, hai trovato la sorgente problematica e puoi correggerla o rimuoverla permanentemente.

Un flusso di lavoro sicuro per la risoluzione dei problemi di APT

Passo 1: Aggiorna i metadati

sudo apt update

Se questo fallisce, correggi i repository prima di provare a riparare i pacchetti. APT non può risolvere le dipendenze correttamente se il suo indice dei pacchetti è obsoleto o incompleto.

Cerca righe contenenti:

NO_PUBKEY
Release file
404 Not Found
does not have a Release file
The repository is not signed

Questi sono problemi di repository o di fiducia, e dovrebbero essere risolti prima di tentare qualsiasi riparazione dei pacchetti.

Passo 2: Completa la configurazione dei pacchetti interrotta

Se l’installazione di un pacchetto è stata interrotta, dpkg potrebbe aver estratto i file ma non configurato il pacchetto.

Esegui:

sudo dpkg --configure -a

Se ha successo, continua con:

sudo apt --fix-broken install

Se fallisce, leggi attentamente il nome del pacchetto e l’errore. Il pacchetto indicato in fondo all’errore è spesso più importante del pacchetto che avevi originariamente provato a installare.

Passo 3: Chiedi ad APT di riparare le dipendenze

sudo apt --fix-broken install

Questo comando chiede ad APT di correggere i problemi di dipendenza installando le dipendenze mancanti o rimuovendo i pacchetti che non possono essere soddisfatti. Leggi attentamente l’azione proposta, specialmente eventuali rimozioni.

Sii cauto se APT vuole rimuovere:

• ubuntu-desktop
• ubuntu-server
• linux-generic
• pacchetti del gestore display
• pacchetti di rete
• pacchetti del database
• pacchetti del runtime dei container
• pacchetti dell’ambiente desktop

A volte rimuovere un metapacchetto è innocuo. A volte è un segnale di allarme che le tue sorgenti dei pacchetti sono mescolate male. Non accettare rimozioni ampie senza capirle.

Passo 4: Controlla i pacchetti trattenuti

apt-mark showhold

Se un pacchetto trattenuto sta bloccando l’aggiornamento, ispezionalo:

apt-cache policy package-name

Se l’hold non è più necessario:

sudo apt-mark unhold package-name
sudo apt update
sudo apt upgrade

Se l’hold è intenzionale, non contrastare APT: correggi il repository o la selezione dei pacchetti attorno all’hold invece di rimuovere la protezione.

Passo 5: Ispeziona le versioni dei pacchetti

Per un pacchetto con problemi di dipendenza:

apt-cache policy package-name

Questo mostra:

• Versione installata
• Versione candidata
• Versioni disponibili
• Quale repository fornisce ciascuna versione

apt-cache policy è uno dei comandi di debug di APT più utili perché mostra da dove proviene ciascuna versione disponibile.

Esempio:

apt-cache policy docker-ce

Se la versione candidata proviene da un PPA inaspettato o da un repository vecchio, hai trovato la causa probabile del conflitto di dipendenza.

Passo 6: Cerca repository misti

Elenco delle sorgenti abilitate:

grep -R "^deb" /etc/apt/sources.list /etc/apt/sources.list.d/

Cerca:

• Nomi in codice di Ubuntu vecchi
• Repository Debian su Ubuntu
• PPA per un altro rilascio di Ubuntu
• Repository dei fornitori duplicati
• Istruzioni sia Snap che APT mescolate per lo stesso strumento
• Vecchi file .list lasciati dopo la disinstallazione del software

Un anti-pattern comune è installare uno strumento da un repository del fornitore, per poi aggiungere successivamente un PPA o un .deb manuale che fornisce librerie sovrapposte. APT può gestire molte sorgenti, ma non può conciliare intenzioni conflittuali a meno che tu non allinei i repository tu stesso.

Passo 7: Prova un’installazione o un aggiornamento simulato

Prima di apportare modifiche, simula:

apt -s install package-name

Oppure:

apt -s full-upgrade

L’opzione -s simula l’operazione. È utile quando vuoi vedere cosa APT farebbe senza modificare il sistema.

Riparazione dei pacchetti trattenuti

Elenco dei pacchetti trattenuti

apt-mark showhold

Se non viene stampato nulla, nessun pacchetto è trattenuto con apt-mark, e puoi passare ai controlli delle dipendenze o dei repository.

Tratteni un pacchetto intenzionalmente

sudo apt-mark hold package-name

Buoni motivi per trattenere un pacchetto:

• Una versione del kernel è nota per funzionare con il tuo hardware.
• Un aggiornamento del database richiede pianificazione.
• Un aggiornamento del driver rompe la tua GPU.
• Una versione del runtime deve corrispondere alla produzione.
• Un pacchetto del fornitore non è compatibile con la dipendenza più recente.

Cattivi motivi per trattenere un pacchetto:

• Hai copiato un comando da una guida vecchia.
• Hai dimenticato perché era trattenuto.
• Stai evitando un errore di dipendenza senza capirlo.

Rimuovi un hold

sudo apt-mark unhold package-name

Quindi aggiorna e aggiorna:

sudo apt update
sudo apt upgrade

Se il pacchetto non si aggiorna comunque, non era solo un problema di hold. Controlla la policy:

apt-cache policy package-name

Riparazione delle dipendenze rotte

La sequenza di riparazione standard

Usa questa sequenza quando l’installazione o l’aggiornamento di un pacchetto è fallito a metà:

sudo apt update
sudo dpkg --configure -a
sudo apt --fix-broken install
sudo apt upgrade

Questo ordine è importante perché ogni passaggio prepara il terreno per il successivo: apt update aggiorna i metadati del repository, dpkg --configure -a completa la configurazione dei pacchetti estratti, apt --fix-broken install permette ad APT di conciliare le dipendenze mancanti o conflittuali, e apt upgrade riprende gli aggiornamenti normali dei pacchetti.

Rimuovi un pacchetto locale installato male

Se il problema è iniziato dopo l’installazione di un .deb scaricato, ispezionalo:

dpkg -l | grep package-name
apt-cache policy package-name

Rimuovilo:

sudo apt remove package-name

Se anche i file di configurazione stanno causando problemi:

sudo apt purge package-name

Quindi ripara:

sudo apt --fix-broken install

Reinstalla un pacchetto danneggiato

Se un pacchetto è installato ma rotto:

sudo apt install --reinstall package-name

Questo è utile quando i file mancano o sono corrotti, ma le sorgenti dei pacchetti sono altrimenti sane e vuoi aggiornare i file installati senza cambiare le versioni.

Riparazione dei problemi di PPA e repository di terze parti

Trova PPA e repository di terze parti

ls /etc/apt/sources.list.d/

Mostra le righe dei repository attivi:

grep -R "^deb" /etc/apt/sources.list /etc/apt/sources.list.d/

Sui sistemi Ubuntu più recenti, potresti vedere anche file .sources che utilizzano il formato deb822:

ls /etc/apt/sources.list.d/*.sources

Visualizzali:

cat /etc/apt/sources.list.d/*.sources

Disabilita un PPA in modo sicuro

Rinomina il file di origine:

sudo mv /etc/apt/sources.list.d/example.list /etc/apt/sources.list.d/example.list.disabled
sudo apt update

Per i file deb822:

sudo mv /etc/apt/sources.list.d/example.sources /etc/apt/sources.list.d/example.sources.disabled
sudo apt update

Rinominare il file di origine è reversibile e più sicuro rispetto all’eliminazione immediata della configurazione del repository, perché puoi rinominarlo nuovamente se hai disabilitato la sorgente sbagliata.

Rimuovi pacchetti da un PPA

Disabilitare un PPA interrompe i download futuri dei pacchetti da esso. Non downgrada automaticamente i pacchetti già installati da quel PPA.

Se il PPA ha causato conflitti di librerie, potresti dover downgradare i pacchetti alle versioni di Ubuntu.

Installa ppa-purge:

sudo apt install ppa-purge

Quindi purge il PPA:

sudo ppa-purge ppa:owner/name

Usa ppa-purge con cautela e leggi le modifiche proposte prima di accettarle, perché potrebbe rimuovere o downgradare diversi pacchetti correlati.

Dopo un aggiornamento di rilascio

Dopo l’aggiornamento di Ubuntu, i vecchi PPA sono una fonte comune di errori.

Controlla i nomi in codice vecchi:

grep -R "jammy\|noble\|oracular\|plucky" /etc/apt/sources.list /etc/apt/sources.list.d/

Adatta i nomi in codice al tuo sistema reale. Ad esempio, se sei su Ubuntu 24.04, il tuo nome in codice è noble. Se una sorgente di terze parti punta ancora a un nome in codice più vecchio, verifica se quel fornitore supporta il tuo rilascio corrente di Ubuntu. Se stai configurando una nuova macchina invece di riparare un aggiornamento, la nostra guida all’installazione di Ubuntu 24.04 spiega come aggiungere repository dei fornitori con signed-by fin dall’inizio.

Non modificare solo il nome in codice e sperare nel meglio: alcuni repository non pubblicano pacchetti per ogni versione di Ubuntu, quindi verifica prima il supporto del fornitore per il tuo rilascio.

Riparazione degli errori GPG e NO_PUBKEY

Cosa significa NO_PUBKEY

I repository APT pubblicano metadati firmati, e la tua macchina ha bisogno della chiave pubblica corrispondente per verificare quei metadati. Se la chiave manca, APT si rifiuta di fidarsi del repository, che è il comportamento desiderato: non disabilitare i controlli della firma solo per far scomparire l’errore.

Il modello moderno di keyring

Crea la directory del keyring:

sudo install -d -m 0755 /etc/apt/keyrings

Scarica e dearmor la chiave del fornitore:

curl -fsSL https://example.com/repository-key.gpg \
  | sudo gpg --dearmor -o /etc/apt/keyrings/example.gpg

Imposta i permessi di lettura:

sudo chmod 0644 /etc/apt/keyrings/example.gpg

Aggiungi il repository con signed-by:

echo "deb [signed-by=/etc/apt/keyrings/example.gpg] https://example.com/linux/ubuntu noble stable" \
  | sudo tee /etc/apt/sources.list.d/example.list

Quindi aggiorna:

sudo apt update

Sostituisci noble con il tuo nome in codice di Ubuntu se necessario:

. /etc/os-release
echo "$VERSION_CODENAME"

Perché apt-key è un’abitudine sbagliata

Le vecchie guide usano spesso:

curl -fsSL https://example.com/key.gpg | sudo apt-key add -

Evita apt-key add per le nuove configurazioni. Il vecchio stile apt-key aggiunge chiavi a un’area di fiducia ampia, il che rende più difficile ragionare su quale chiave è fidata per quale repository, mentre lo stile moderno signed-by limita la chiave a un repository specifico ed è un’igiene di base della catena di fornitura.

Trova chiavi fidate legacy

Potresti ancora avere vecchie chiavi in:

/etc/apt/trusted.gpg
/etc/apt/trusted.gpg.d/

Elenco dei file:

ls -l /etc/apt/trusted.gpg.d/

Non eliminare le chiavi a caso: prima mappa ogni chiave a un repository, poi migra un repository alla volta a /etc/apt/keyrings e signed-by.

Errori GPG comuni

Non usare keyservers casuali come prima scelta quando si correggono gli errori NO_PUBKEY.

Ordine migliore:

1. Usa la documentazione di installazione ufficiale del fornitore.
2. Scarica la chiave dall’URL HTTPS ufficiale del fornitore.
3. Memorizzala in /etc/apt/keyrings.
4. Associala con signed-by.
5. Esegui sudo apt update.

Evita queste scorciatoie:

sudo apt update --allow-unauthenticated
sudo apt install --allow-unauthenticated package-name

Potrebbero funzionare temporaneamente, ma rimuovono la verifica della firma che ti protegge da metadati del repository manipolati.

Riparazione di “Il repository non è firmato”

Questo errore di solito significa una di queste cose:

• Il repository non pubblica metadati firmati.
• L’URL del repository è sbagliato.
• Il repository non supporta più la tua versione di Ubuntu.
• Un proxy o uno specchio sta restituendo il contenuto sbagliato.
• Stai usando HTTP dove il fornitore ora si aspetta HTTPS.
• Il file di origine ha la suite o il componente sbagliato.

Trova la sorgente che fallisce:

sudo apt update

APT stamperà l’URL. Quindi cercalo:

grep -R "example.com" /etc/apt/sources.list /etc/apt/sources.list.d/

Disabilitalo temporaneamente:

sudo mv /etc/apt/sources.list.d/example.list /etc/apt/sources.list.d/example.list.disabled
sudo apt update

Se APT funziona di nuovo dopo aver disabilitato il file, reinstalla quel repository dalle istruzioni ufficiali attuali del fornitore invece di riabilitare la vecchia configurazione.

Riparazione degli avvisi di repository duplicati

APT potrebbe avvisare che un target è configurato più volte.

Elenco delle voci corrispondenti:

grep -R "repo-url-or-domain" /etc/apt/sources.list /etc/apt/sources.list.d/

I repository duplicati appaiono spesso dopo aver eseguito più volte gli script di installazione del fornitore.

Mantieni un file di origine. Disabilita gli altri:

sudo mv /etc/apt/sources.list.d/duplicate.list /etc/apt/sources.list.d/duplicate.list.disabled
sudo apt update

Gli avvisi di duplicati non sono sempre fatali, ma sono un segno di configurazione approssimativa, quindi mantieni un file di origine e disabilita i duplicati.

Riparazione di pacchetti dal rilascio sbagliato di Ubuntu

Uno dei peggiori problemi di APT è mescolare i rilasci di Ubuntu: ad esempio, una macchina su Ubuntu 24.04 non dovrebbe casualmente prelevare pacchetti da Ubuntu 22.04 o Debian testing. A volte funziona per un po’, ma alla fine il grafo delle dipendenze diventa un puzzle che APT non può risolvere in modo pulito.

Controlla il tuo rilascio:

. /etc/os-release
echo "$VERSION_CODENAME"

Cerca nelle sorgenti:

grep -R "^deb" /etc/apt/sources.list /etc/apt/sources.list.d/

Cerca nomi in codice stranieri nelle sorgenti abilitate, poi ispeziona il pacchetto interessato:

apt-cache policy package-name

Se la versione installata proveniva da un repository vecchio o straniero, disabilita quel repository e downgrada o reinstalla il pacchetto interessato dai repository di Ubuntu.

Un percorso di riparazione conservativo è:

sudo apt update
sudo apt install --reinstall package-name

Per conflitti più profondi, potresti dover rimuovere il pacchetto e reinstallarlo dalla sorgente corretta invece di forzare un aggiornamento su una versione straniera.

Pulizia della cache di APT e pacchetti inutilizzati

La pulizia della cache di APT non è una riparazione delle dipendenze di per sé, ma può aiutare dopo molti installazioni fallite liberando spazio su disco e cancellando file di pacchetti obsoleti.

Rimuovi i pacchetti che sono stati installati automaticamente e non sono più necessari:

sudo apt autoremove

Pulisci i file dei pacchetti scaricati:

sudo apt clean

Oppure rimuovi solo i file dei pacchetti obsoleti:

sudo apt autoclean

Usa autoremove con cautela su server e desktop con stack di driver installati manualmente, e leggi l’elenco delle rimozioni prima di accettare.

Ricette pratiche per la risoluzione dei problemi di APT

Ricetta: Il pacchetto è trattenuto

sudo apt update
apt list --upgradable
apt-mark showhold
sudo apt full-upgrade

Se APT propone modifiche ragionevoli dopo la simulazione, accettale. Se propone rimozioni ampie, fermati e ispeziona:

apt-cache policy package-name

Ricetta: Il pacchetto trattenuto blocca l’aggiornamento

apt-mark showhold
apt-cache policy package-name
sudo apt-mark unhold package-name
sudo apt upgrade

Rimuovi l’hold solo se l’hold non è più intenzionale, perché rimuovere un hold che protegge software di produzione può innescare un aggiornamento distruttivo.

Ricetta: Installazione interrotta

sudo dpkg --configure -a
sudo apt --fix-broken install
sudo apt upgrade

Ricetta: Errore NO_PUBKEY

1. Identifica il repository da sudo apt update.
2. Trova le istruzioni di installazione ufficiali attuali del fornitore.
3. Installa la chiave in /etc/apt/keyrings.
4. Usa signed-by nel file di origine.
5. Esegui sudo apt update.

Struttura di esempio:

sudo install -d -m 0755 /etc/apt/keyrings

curl -fsSL https://example.com/key.gpg \
  | sudo gpg --dearmor -o /etc/apt/keyrings/example.gpg

sudo chmod 0644 /etc/apt/keyrings/example.gpg

echo "deb [signed-by=/etc/apt/keyrings/example.gpg] https://example.com/ubuntu noble main" \
  | sudo tee /etc/apt/sources.list.d/example.list

sudo apt update

Ricetta: Il PPA non ha un file Release

sudo apt update
ls /etc/apt/sources.list.d/
grep -R "ppa.launchpadcontent.net\|launchpad" /etc/apt/sources.list.d/

Disabilita il PPA:

sudo mv /etc/apt/sources.list.d/example.list /etc/apt/sources.list.d/example.list.disabled
sudo apt update

Poi decidi se rimuovere, sostituire o pulire i pacchetti da quel PPA.

Ricetta: Un .deb manuale ha rotto le dipendenze

dpkg -l | grep package-name
apt-cache policy package-name
sudo apt remove package-name
sudo apt --fix-broken install

Se hai ancora bisogno del software, preferisci il repository APT attuale del fornitore rispetto a ripetute installazioni manuali di .deb, che tendono ad accumulare conflitti di dipendenza nel tempo.

Comandi essenziali per la risoluzione dei problemi di APT

Repository e metadati

sudo apt update
grep -R "^deb" /etc/apt/sources.list /etc/apt/sources.list.d/
ls /etc/apt/sources.list.d/

Stato del pacchetto

apt list --installed
apt list --upgradable
apt-mark showhold
dpkg -l | grep package-name

Policy e dipendenze del pacchetto

apt-cache policy package-name
apt-cache depends package-name
apt-cache rdepends package-name

Riparazione

sudo dpkg --configure -a
sudo apt --fix-broken install
sudo apt install --reinstall package-name
sudo apt full-upgrade

Pulizia

sudo apt autoremove
sudo apt autoclean
sudo apt clean

Simulazione

apt -s install package-name
apt -s full-upgrade

Cosa non fare

Non eliminare casualmente /var/lib/dpkg

Se vedi consigli per eliminare i file di stato di dpkg, sii scettico. Il database di dpkg è il registro dei pacchetti installati, e eliminare parti di esso può trasformare un problema di pacchetto riparabile in un progetto di recupero completo del sistema.

Non disabilitare la verifica della firma

Evita:

--allow-unauthenticated

Se un repository non può essere verificato, correggi la chiave o disabilita il repository invece di bypassare l’autenticazione.

Non mescolare rilasci di Ubuntu casualmente

Non aggiungere repository per un altro rilascio di Ubuntu a meno che tu non capisca il pinning di APT e le conseguenze per le dipendenze.

Questo si applica specialmente a:

• ambienti desktop
• driver grafici
• stack Python
• runtime dei container
• pacchetti Kubernetes
• pacchetti del database

Non trattare i PPA come innocui

I PPA sono utili, ma sono comunque repository di pacchetti che possono sostituire librerie e pacchetti di sistema: il che potrebbe essere esattamente quello che vuoi, o esattamente il motivo per cui il tuo prossimo aggiornamento si rompe. Preferisci i PPA per applicazioni specifiche, non per fondamenta di sistema ampie, a meno che tu non faccia affidamento sul mantentore e non capisca il percorso di aggiornamento.

Albero decisionale per la risoluzione dei problemi di APT

Usa questo modello mentale:

La maggior parte dei problemi di APT diventano gestibili una volta che smetti di trattarli come un unico grande errore e inizi a separare la salute del repository, lo stato del pacchetto, la risoluzione delle dipendenze e la configurazione della fiducia: l’albero decisionale sopra è un’abbreviazione per quella disciplina.

Linea di base consigliata per le macchine degli sviluppatori

Per una workstation di sviluppo Ubuntu pulita, preferisco questa linea di base:

• Mantieni i repository di Ubuntu standard.
• Usa i repository APT dei fornitori solo quando sono ufficiali e mantenuti.
• Usa /etc/apt/keyrings e signed-by per i repository di terze parti.
• Evita le vecchie istruzioni apt-key.
• Evita di mescolare PPA che sostituiscono librerie di sistema fondamentali.
• Usa container, uv, pipx, asdf, mise o strumenti nativi del linguaggio per le dipendenze degli sviluppatori in rapida evoluzione.
• Mantieni APT responsabile del sistema operativo, dei driver, dei servizi e degli strumenti CLI stabili.

Per il software desktop, preferisci Flatpak o Snap rispetto ai PPA quando un pacchetto universale sandboxed si adatta alle tue esigenze. APT è eccellente quando gestisce il sistema base, ma diventa doloroso quando è costretto a comportarsi come un gestore di dipendenze universali per sviluppatori per ecosistemi linguistici in rapida evoluzione.

Checklist finale per la risoluzione dei problemi di APT

Quando APT è rotto su Ubuntu, passa attraverso questa checklist:

[ ] Run sudo apt update and read the first real error.
[ ] Check Ubuntu codename with /etc/os-release.
[ ] Finish interrupted installs with dpkg --configure -a.
[ ] Repair dependencies with apt --fix-broken install.
[ ] Check held packages with apt-mark showhold.
[ ] Inspect package versions with apt-cache policy.
[ ] Disable broken PPAs or third-party repositories.
[ ] Replace apt-key style repositories with signed-by keyrings.
[ ] Simulate risky operations with apt -s.
[ ] Read removals before accepting full-upgrade or autoremove.

APT non è fragile, ma è rigoroso, e quella rigidità è una caratteristica: impedisce a repository non firmati, set di dipendenze impossibili e sostituzioni accidentali di pacchetti di modificare silenziosamente il tuo sistema. Il modo calmo per riparare APT è preservare quella rigidità, trovare lo stato conflittuale e riparare la cosa più piccola che è effettivamente sbagliata.