Product SiteDocumentation Site

6.7. Aggiornare da una distribuzione stabile alla successiva

Una delle caratteristiche più note di Debian è la sua capacità di aggiornare il sistema installato da un rilascio stabile a quello successivo: dist-upgrade, un termine ben noto, ha in gran parte contribuito alla reputazione del progetto. Con alcune precauzioni, l'aggiornamento di un computer può richiedere da un minimo di pochi, fino a qualche decina, di minuti a seconda della velocità di scaricamento dai repository dei pacchetti.

6.7.1. Procedura raccomandata

Dal momento che Debian ha un tempo abbastanza lungo per evolvere fra i rilasci stabili, si consiglia di leggere le note di rilascio prima di fare l'aggiornamento.
In this section, we will focus on upgrading a Bullseye system to Bookworm. This is a major operation on a system; as such, it is never 100% risk-free, and should not be attempted before all important data has been backed up.
Un'altra buona abitudine che permette un aggiornamento più facile (e veloce) è di riordinare i pacchetti installati e mantenere solo quelli che sono realmente necessari. Strumenti utili per fare questo sono aptitude, deborphan, debfoster e apt-show-versions (vedere Sezione 6.2.7, «Tenere traccia dei pacchetti installati automaticamente»). Per esempio, è possibile avvalersi del seguente comando e poi usare la modalità interattiva di aptitude per ricontrollare ed ottimizzare le rimozioni pianificate:
# deborphan | xargs aptitude --schedule-only remove
Now for the upgrading itself. First, you need to change the /etc/apt/sources.list file to tell APT to get its packages from Bookworm instead of Bullseye. If the file only contains references to Stable rather than explicit codenames, the change isn't even required, since Stable always refers to the latest released version of Debian. In both cases, the database of available packages must be refreshed with the apt update command or the refresh button in synaptic (Sezione 6.2.1, «Inizializzazione»).
Una volta che queste nuove fonti di pacchetti sono registrate, si dovrebbe prima fare un aggiornamento minimale con apt upgrade come descritto in Sezione 6.2.3, «Aggiornamento del sistema». Facendo l'aggiornamento in due fasi, si facilita il compito degli strumenti di gestione dei pacchetti e spesso si garantisce la presenza delle loro più recenti versioni che possono aver beneficiato di risoluzioni di bug e miglioramenti necessari per portare a termine l'aggiornamento completo del sistema.
Once this first upgrade is done, it is time to handle the upgrade itself, either with apt full-upgrade, aptitude, or synaptic (Sezione 6.7, «Aggiornare da una distribuzione stabile alla successiva»). You should carefully check the suggested actions before applying them: you might want to add suggested packages or deselect packages which are only recommended and known not to be useful. In any case, the frontend should come up with a scenario ending in a coherent and up-to-date Bookworm system. Then, all you need is to do is wait while the required packages are downloaded, answer the debconf questions and possibly those about locally modified configuration files, and sit back while APT does its magic.

6.7.2. Gestire i problemi dopo un aggiornamento

Nonostante i migliori sforzi dei manutentori Debian, un importante aggiornamento di sistema non va sempre liscio come si spera. Le nuove versioni del software possono essere incompatibili con quelle precedenti (per esempio, il loro comportamento predefinito o il loro formato dei dati potrebbe essere cambiato). Inoltre, alcuni bug possono sfuggire, nonostante la fase di sperimentazione, che precede sempre un rilascio di Debian.
Per anticipare alcuni di questi problemi, è possibile installare il pacchetto apt-listchanges, che visualizza le informazioni sui possibili problemi all'inizio dell'aggiornamento di un pacchetto. Queste informazioni sono compilate dai manutentori dei pacchetti e inserite nel file /usr/share/doc/pacchetto/NEWS.Debian a beneficio degli utenti. Leggere questi file (possibilmente attraverso apt-listchanges) dovrebbe aiutare ad evitare brutte sorprese.
A volte è possibile che la nuova versione di un software non funzioni affatto. Questo in genere accade se l'applicazione non è particolarmente popolare e non è stata testata a sufficienza; un aggiornamento dell'ultimo minuto può anche introdurre regressioni che vengono scoperte solo dopo il rilascio stabile. In entrambi i casi, la prima cosa da fare è dare uno sguardo al sistema di tracciamento dei bug su https://bugs.debian.org/pacchetto e verificare se il problema è già stato segnalato. In tal caso, verrà elencato anche prima dell'inizio dell'aggiornamento se apt-listbugs è installato. Se non lo è, dovresti essere tu a segnalarlo con reportbug. Se è già noto, la segnalazione di bug ed i messaggi ad esso associati sono in genere un'eccellente fonte di informazioni:
  • a volte una soluzione esiste già, ed è disponibile nella segnalazione di bug; si può allora ricompilare localmente una versione corretta del pacchetto non funzionante (vedere la Sezione 15.1, «Rigenerare un pacchetto dai suoi sorgenti»);
  • in altri casi, gli utenti potrebbero aver trovato un modo di superare il problema e condiviso le loro conoscenze al riguardo nelle loro risposte alla segnalazione;
  • in altri casi ancora, un pacchetto corretto potrebbe essere già stato preparato e reso pubblico da parte del manutentore.
A seconda della gravità del bug, una nuova versione del pacchetto può essere preparata appositamente per una nuova revisione del rilascio stabile. Quando ciò accade, il pacchetto corretto viene reso disponibile nella sezione proposed-updates dei mirror Debian (vedere Sezione 6.1.2.3, «Aggiornamenti proposti»). La voce corrispondente può quindi essere aggiunta temporaneamente al file sources.list ed i pacchetti aggiornati possono essere installati con apt o aptitude.
A volte il pacchetto corretto non è ancora disponibile in questa sezione perché è in attesa di una validazione da parte dei gestori (Stable Release Manager). In tal caso, si può verificare sulla loro pagina web. I pacchetti elencati in quella pagina non sono ancora disponibili, ma almeno sappiamo che il processo di pubblicazione è in corso.

6.7.3. Pulizia dopo un aggiornamento

APT normalmente assicura un aggiornamento pulito, scaricando dipendenze nuove ed aggiornando o rimuovendo i pacchetti in conflitto. Ma pur essendo un eccellente strumento, non può gestire tutti i compiti che utenti ed amministratori devono affrontare dopo un aggiornamento, in quanto richiedono una decisione umana.

6.7.3.1. Pacchetti rimossi dall'archivio Debian

Sometimes the Debian ftpmasters remove packages from the Debian archive, because they contain release critical bugs, were abandoned by their upstream author or their package maintainer, or simply reached their end of life. In this case, a newer Debian release does not ship the package anymore. To find all packages, which do not have a package source, use the apt-show-versions command:
$ apt-show-versions | grep "No available version"
Un risultato simile può essere ottenuto con aptitude search ~o. Se i pacchetti trovati non sono più necessari, allora dovrebbero essere eliminati dal sistema, perché questi non saranno più soggetti ad aggiornamenti di bug critici o di sicurezza.

6.7.3.2. Pacchetti fittizi e di transizione

Talvolta, diventa necessario cambiare il nome di un pacchetto. In questi casi, il vecchio pacchetto è spesso mantenuto come un pacchetto (quasi) vuoto, a seconda di quello nuovo ed installando soltanto i file necessari in /usr/share/doc/pacchetto/. Questi pacchetti sono chiamati "fittizi" o "transitori". Se il manutentore del pacchetto in carica cambia anche la sezione del pacchetto a oldlibs, allora strumenti come aptitude, deboprhan o debfoster (vedere il riquadro ALTERNATIVA deborphan e debfoster) possono individuare questi pacchetti e suggerirne la rimozione.
Sfortunatamente non c'è attualmente nessuna modalità infallibile per essere sicuri che questi pacchetti siano rimossi automaticamente o individuati dai predetti strumenti. Una modalità per verificare se il sistema abbia alcuni di questi pacchetti installati è quella di cercare tramite la descrizione dei pacchetti installati e controllare i risultati. Attenzione a non programmare la rimozione automatica dei file risultanti, perché questo metodo può fornire dei falsi positivi:
$ dpkg -l | grep ^ii | grep -i -E "(transition|dummy)"
Poiché i nuovi pacchetti sono scaricati come dipendenza di un pacchetto di transizione, esso viene marcato come automaticamente installato e può essere rimosso se si cerca di eliminare il pacchetto di transizione dal sistema. In questo caso, per rimuovere in modo selettivo il pacchetto di transizione, si può usare uno degli approcci descritti nel riquadro SUGGERIMENTO Rimozione e installazione nello stesso momento e Sezione 6.2.7, «Tenere traccia dei pacchetti installati automaticamente».

6.7.3.3. File di configurazione vecchi o non più in uso

If the upgrade was successful, there might be some configuration file cruft, either from dpkg (see Sezione 5.2.3, «Checksum, elenco dei file di configurazione, ecc.»), ucf or from removed packages. The latter can be purged by using apt autoremove --purge. The configuration files that were handled by dpkg or ucf during the upgrade process have left some counterparts with a dedicated suffix, e.g. .dpkg-dist, .dpkg-old, .ucf-old. Using the find or locate command can help to track them down. If they are no longer of any use, they can be deleted.
Be aware that a purge also removes the data created with a particular package (e.g. database files, docker volumes and containers, etc.). There should always be backups in place in case data gets removed accidentally.

6.7.3.4. File non appartenenti a nessun pacchetto

Le politiche di Debian impongono che i pacchetti non lascino file nel sistema quando vengono eliminati. Violare questo principio è un bug serio ed accade raramente. Se vi capita, segnalatelo; per i più curiosi, si può usare il pacchetto cruft o cruft-ng per controllare il sistema e trovare i file non posseduti da nessun pacchetto.