[ precedente ] [ Contenuti ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ A ] [ successivo ]


Note di Rilascio per Debian GNU/Linux 4.0 ("etch"), Intel x86
Capitolo 4 - Aggiornamenti da precedenti rilasci


4.1 Preparazione all'aggiornamento

Suggeriamo che prima di aggiornare si leggano anche le informazioni in Problematiche di cui bisogna essere al corrente per etch, Capitolo 5. Tale capitolo copre potenziali problematiche non direttamente collegate al processo di aggiornamento, ma che potrebbe comunque essere importante conoscere prima di cominciare.


4.1.1 Backup di dati e informazioni di configurazione

Prima di aggiornare il proprio sistema, si raccomanda vivamente di effettuare un backup completo, o almeno la copia di tutti quei dati e informazioni di configurazione che non ci si può permettere di perdere. Gli strumenti ed i processi di aggiornamento sono piuttosto affidabili, ma un problema all'hardware nel corso di un aggiornamento potrebbe risultare in un sistema fortemente danneggiato.

Le principali cose di cui si vorrà mantenere una copia sono i contenuti di /etc, di /var/lib/dpkg e di /var/lib/aptitude/pkgstates e l'output di dpkg --get-selections "*" (le virgolette sono importanti).

Di per sé, il processo di aggiornamento non modifica nulla nella directory /home. È tuttavia noto che alcune applicazioni (p.e. alcune parti della suite Mozilla e gli ambienti desktop GNOME e KDE) sovrascrivono impostazioni preesistenti dell'utente con nuovi valori predefiniti quando un utente avvia per la prima volta una nuova versione dell'applicazione. Si potrebbe voler fare per precauzione un backup di file e directory nascosti (“dotfile”, cioè file i cui nomi iniziano con un punto, NdT) delle directory home degli utenti. Tale backup potrebbe aiutare a ripristinare o ricreare le vecchie impostazioni. Si potrebbe anche voler informare gli utenti di questo argomento.

Ogni installazione di pacchetti deve essere eseguita con i privilegi di superutente, dunque si effettui il login come root o si usi su o sudo per ottenere i diritti di accesso necessari.

L'aggiornamento ha alcune precondizioni: le si dovrebbe verificare prima di espletare effettivamente l'operazione.


4.1.2 Informare gli utenti in anticipo

È saggio informare in anticipo tutti gli utenti di qualunque aggiornamento si stia pianificando, sebbene gli utenti che accedono al sistema tramite una connessione ssh non dovrebbero notare granché durante l'aggiornamento, e dovrebbero poter continuare a lavorare.

Se si desidera prendere ulteriori precauzioni, si esegua un backup delle partizioni degli utenti (/home) o le si smonti prima di un aggiornamento.

Probabilmente con l'aggiornamento a etch si dovrà anche fare un aggiornamento del kernel, cosicché sarà normalmente necessario riavviare. Tipicamente, questo sarà fatto dopo la fine dell'aggiornamento.


4.1.3 Preparazione per il ripristino

A causa dei molti cambiamenti nel kernel tra sarge e etch riguardanti i driver, il rilevamento dell'hardware e l'assegnamento e l'ordinamento dei file device, c'è un reale rischio che si incontrino problemi al riavvio del sistema dopo l'aggiornamento. Molte potenziali problematiche sono documentate in questo capito delle presenti Note di Rilascio e nei successivi.

Per tale ragione è sensato assicurarsi di poter effettuare un ripristino nel caso in cui il sistema dovesse non riuscire a riavviarsi o, nel caso di sistemi controllati da remoto, non riuscire a raggiungere la rete.

Se si sta aggiornando da remoto tramite un collegamento ssh è altamente raccomandato che si prendano le necessarie precauzioni per poter accedere al server tramite un terminale seriale remoto. Vi è il rischio che, dopo l'aggiornamento del kernel e il riavvio, alcuni dispositivi siano rinominati (come descritto in Riordino della numerazione dei dispositivi, Sezione 4.6.4) e si dovrà sistemare la configurazione del sistema tramite una console locale. Inoltre, se il sistema è riavviato accidentalmente nel mezzo di un aggiornamento, vi sono possibilità che lo si debba ripristinare utilizzando una console locale.

La cosa più ovvia da fare per prima è riavviare con il vecchio kernel. Tuttavia, per varie ragioni documentate altrove nel presente documento, non è garantito che ciò funzioni.

Se ciò fallisce, si necessiterà di un modo alternativo per avviare il sistema in modo tale da poter accedere ad esso e ripararlo. Un'opzione è quella di utilizzare una speciale immagine di ripristino o un live CD con linux. Dopo l'avvio da esso, si dovrebbe poter montare il filesystem radice ed entrarvi con chroot per investigare e correggere il problema.

Un'altra opzione di cui vorremmo raccomandare l'utlizzo è quella di usare la modalità di ripristino (rescue mode) dell'Installatore Debian di etch. Il vantaggio di utilizzare l'installatore è che si può scegliere fra i suoi molti metodi di installazione quello che meglio si adatta alla situazione. Per maggiori informazioni si consultino la sezione "Recupero di un sistema danneggiato" nel capitolo 8 della Guida all'Installazione e le FAQ dell'Installatore Debian.


4.1.3.1 Shell di debug durante l'avvio con initrd

initramfs-tools include una shell di debug[6] negli initrd che genera. Se per esempio l'initrd non è in grado di montare il filesystem radice, si sarà rimandati in questa shell di debug che rende disponibili comandi di base per aiutare a rintracciare il problema e se possibile risolverlo.

Le cose di base da controllare sono: la presenza dei file device corretti in /dev; quali moduli sono caricati (cat /proc/modules); l'output di dmesg per errori nel caricamento dei driver. L'output di dmesg mostrerà anche quali file device sono stati assegnati a quali dischi; si dovrebbe verificare ciò rispetto all'output di echo $ROOT per accertarsi che il filesystem radice sia sul dispositivo atteso.

Se si riesce a risolvere il problema, digitando exit si uscirà della shell di debug e il processo di avvio riprenderà dal punto in cui il problema è incorso. Naturalmente si dovrà anche risolvere il problema a monte e rigenerare l'initrd così che il prossimo avvio non fallisca nuovamente.


4.1.4 Preparazione di un ambiente sicuro per l'aggiornamento

L'aggiornamento della distribuzione dovrebbe essere effettuato o in locale da una console virtuale in modalità testo (o da un terminale seriale direttamente connesso), o in remoto attraverso un collegamento ssh.

Al fine di ottenere un margine di sicurezza extra nell'aggiornamento da remoto, suggeriamo che si eseguano i processi di aggiornamento nella console virtuale fornita dal programma screen, che consente la riconnessione sicura ed assicura che il processo di aggiornamento non sia interrotto anche qualora il processo di connessione remota si interrompa.

Importante! Non si dovrebbe effettuare l'aggiornamento utilizzando telnet, rlogin, rsh, o da una sessione di X gestita da xdm, gdm o kdm etc. sulla macchina che si sta aggiornando. Questo perché ciascuno di tali servizi potrebbe essere terminato durante l'aggiornamento, il che può risultare in un sistema inaccessibile che si troverebbe aggiornato solo a metà.


4.1.5 Il supporto per i kernel 2.2 è stato interrotto

Nel caso in cui si utilizzi un kernel precedente al 2.4.1, è necessario aggiornare (almeno) alla serie 2.4 prima di aggiornare le glibc. Ciò dovrebbe essere fatto prima di cominciare con l'aggiornamento. Si raccomanda di aggiornare direttamente al kernel 2.6.8 disponibile in sarge, anziché aggiornare ad un kernel 2.4.


4.2 Verifica dello stato del sistema

Il processo di aggiornamento descritto nel presente capitolo è stato progettato per aggiornamenti da sistemi sarge puri senza pacchetti di terze parti. In particolare, vi sono noti problemi con pacchetti di terze parti che installano programmi in /usr/X11R6/bin/, causando problemi con gli aggiornamenti a causa della transizione di X.org (Transizione da XFree86 a X.Org, Sezione 5.3). Per la massima affidabilità del processo di aggiornamento, si potrebbe desiderare di rimuovere pacchetti di terze parti dal sistema prima di cominciare con l'aggiornamento.

La procedura assume anche che il sistema sia stato aggiornato fino all'ultimo rilascio anche minore di sarge. Se non lo si è fatto o non se ne è certi, si seguano le istruzioni in Aggiornamento del proprio sistema sarge, Sezione A.1.


4.2.1 Controllare le azioni in sospeso nel gestore dei pacchetti

In alcuni casi, l'utilizzo di apt-get per installare pacchetti in luogo di aptitude potrebbe far sì che aptitude consideri un pacchetto come "inutilizzato" e ne programmi la rimozione. In generale, ci si dovrebbe assicurare che il sistema sia completamente aggiornato e "pulito" prima di procedere con l'aggiornamento.

A causa di ciò bisognerebbe controllare se vi sono azioni in sospeso nel gestore dei pacchetti aptitude. Se di un pacchetto è programmata la rimozione o l'aggiornamento nel gestore dei pacchetti, esso potrebbe avere un impatto negativo sulla procedura di aggiornamento. Si noti che la correzione è possibile soltanto se il file sources.list punta ancora a sarge, e non a stable o a etch: si veda Controllo della lista delle fonti, Sezione A.2.

Per fare questo, si dovrebbe eseguire l'interfaccia utente di aptitude e premere 'g' ("Go"). Se questo visualizza delle azioni, si dovrebbero controllare queste ultime e correggere o implementare le azioni suggerite. Se non è suggerita alcuna azione sarà presentato un messaggio che dice "No packages are scheduled to be installed, removed, or upgraded".


4.2.2 Disattivare il pinning di APT

Se si è configurato APT per installare alcuni pacchetti da una distribuzione diversa da stable (p.e. da testing), si potrebbe dover modificare la propria configurazione dei pin APT (salvata in /etc/apt/preferences) per consentire l'aggiornamento di tali pacchetti alle versioni contenute nel nuovo rilascio stable. Maggiori informazioni sui pin APT possono essere reperite in apt_preferences(5).


4.2.3 Verifica dello stato dei pacchetti

Indipendentemente dal metodo utilizzato per l'aggiornamento, si raccomanda di controllare prima lo stato di tutti i pacchetti, e di verificare che tutti i pacchetti siano in uno stato che ne consente l'aggiornamento. Il seguente comando visualizzerà eventuali pacchetti che siano in uno stato “Half-Installed” o “Failed-Config”, e quelli che abbiano uno status problematico.

     
     
     # dpkg --get-selections | grep hold

Si può anche ispezionare lo stato di tutti i pacchetti del proprio sistema utilizzando dselect, aptitude, o comandi come

     # dpkg -l | pager

o

     # dpkg --get-selections "*" > ~/curr-pkgs.txt

È desiderabile la rimozione di qualunque blocco prima dell'aggiornamento. Se qualche pacchetto che è essenziale per l'aggiornamento è bloccato [“on hold”], l'aggiornamento non andrà a buon fine.

Si noti che aptitude utilizza un metodo differente per registrare i pacchetti tenuti bloccati rispetto ad apt-get e a dselect. Si possono identificare pacchetti tenuti bloccati per aptitude con

     # aptitude search "~ahold" | grep "^.h"

Volendo controllare quali pacchetti sono bloccati per apt-get, si dovrebbe utilizzare il comando

     # dpkg --get-selections | grep hold

Se si è modificato e ricompilato un pacchetto localmente, e non lo si è rinominato né lo si è contrassegnato nella versione, lo si dovrà bloccare per impedire che venga aggiornato.

Lo stato “bloccato” [“hold”] dei pacchetti per aptitude può essere cambiato con il comando:

     # aptitude hold nome_del_pacchetto

Si sostituisca hold con unhold per rimuovere lo stato “bloccato”.

Se c'è bisogno di sistemare qualcosa, è sempre meglio assicurarsi che il proprio sources.list faccia ancora riferimento a sarge come spiegato in Controllo della lista delle fonti, Sezione A.2.


4.2.4 Fonti non ufficiali e backport

Se si hanno pacchetti non-Debian sul proprio sistema, si dovrebbe essere al corrente del fatto che essi potrebbero essere rimossi durante l'aggiornamento a causa di dipendenze in conflitto. Se tali pacchetti fossero stati installati tramite l'aggiunta di un archivio extra di pacchetti in /etc/apt/sources.list, si dovrebbe verificare se quell'archivio offra anche pacchetti compilati per etch e modificare rispettivamente le righe delle fonti nel momento stesso in cui si modifichino le righe delle fonti per i pacchetti Debian.

Alcuni utenti potrebbero avere installate nel loro sistema versioni non ufficiali “più recenti” da backport di pacchetti che sono in Debian sarge. Tali pacchetti sono i primi candidati a causare problemi durante un aggiornamento, dal momento che essi potrebbero far risultare conflitti tra file[7]. La sezione Problematiche che potrebbero emergere durante l'aggiornamento, Sezione 4.5.8 contiene delle informazioni su come comportarsi di fronte a conflitti fra file nel caso in cui si dovessero verificare.


4.3 Smarcare manualmente i pacchetti

Per impedire ad aptitude di rimuovere alcuni pacchetti che sono stati selezionati tramite dipendenze, li si dovrà smarcare manualmente come pacchetti auto. Ciò comprende OpenOffice.org e Vim per installazioni di desktop:

     # aptitude unmarkauto openoffice.org vim

E immagini di kernel 2.6 qualora siano state installate con l'utilizzo di un metapacchetto:

     # aptitude unmarkauto $(dpkg-query -W 'kernel-image-2.6.*' | cut -f1)

Nota: Si può controllare quali pacchetti sono marcati come auto in aptitude eseguendo:

     # aptitude search 'i~M <nome pacchetto>'

4.4 Preparazione delle fonti per APT

Prima di cominciare l'aggiornamento si deve predisporre per le liste dei pacchetti il file di configurazione di apt, /etc/apt/sources.list.

apt prenderà in considerazione tutti i pacchetti che possono essere trovati tramite le righe “deb”, ed installerà il pacchetto con il numero di versione più alto, dando la priorità alle righe menzionate per prime (in questo modo, nel caso in cui siano presenti varie fonti equivalenti, si dovrebbe menzionare per primo un disco fisso locale, poi CD-ROM, infine mirror HTTP/FTP).

Si fa spesso riferimento ad un rilascio sia tramite il uso nome in codice (p.e. sarge, etch) sia tramite la denominazione del suo stadio (cioè oldstable, stable, testing, unstable). Fare riferimento ad un rilascio attraverso il suo nome in codice presenta il vantaggio che non si sarà mai sorpresi da un nuovo rilascio, e per questa ragione è il modo adottato qui. Questo naturalmente significa che si dovrà fare attenzione agli annunci di rilascio. Se si utilizza invece la denominazione dello stadio, si vedrà la grande quantità di aggiornamenti disponibili per i propri pacchetti non appena avvenga un rilascio.


4.4.1 Aggiunta di fonti Internet per APT

La configurazione predefinita è predisposta per l'installazione dai principali server Debian su Internet, ma si potrebbe desiderare di modificare /etc/apt/sources.list per utilizzare altri mirror, preferibilmente un mirror più “vicino” (dal punto di vista della rete).

Gli indirizzi dei mirror HTTP o FTP di Debian possono essere reperiti presso http://www.debian.org/distrib/ftplist (si guardi la sezione “elenco dei mirror”). I mirror HTTP sono in genere più rapidi dei mirror FTP.

Ad esempio, si supponga che il proprio mirror Debian più vicino sia http://mirrors.kernel.org/debian/. Ispezionando tale mirror con un browser web o con un client FTP, si noterà che le directory principali sono organizzate nel modo seguente:

     http://mirrors.kernel.org/debian/dists/etch/main/binary-i386/...
     http://mirrors.kernel.org/debian/dists/etch/contrib/binary-i386/...

Per utilizzare questo mirror con apt, si aggiungerà al proprio file sources.list la seguente riga:

     deb http://mirrors.kernel.org/debian etch main contrib

Si noti che “dists” è aggiunto implicitamente, e che gli argomenti che seguono il nome del rilascio sono utilizzati per espandere il percorso su multiple directory.

Dopo aver aggiunto le proprie nuove fonti, si disabilitino le righe “deb” preesistenti in sources.list ponendo davanti ad esse un simbolo 'cancelletto' (#).


4.4.2 Aggiunta di fonti da mirror locale per APT

Al posto di utilizzare mirror HTTP o FTP dei pacchetti, si potrebbe desiderare di modificare /etc/apt/sources.list per utilizzare un mirror su un disco locale (possibilmente montato su NFS) (NFS: filesystem di rete, NdT).

Ad esempio, il proprio mirror dei pacchetti potrebbe essere sotto /var/ftp/debian/, e si potrebbe avere directory principali come le seguenti:

     /var/ftp/debian/dists/etch/main/binary-i386/...
     /var/ftp/debian/dists/etch/contrib/binary-i386/...

Per utilizzare questo mirror con apt, si aggiungerà al proprio file sources.list la seguente riga:

     deb file:/var/ftp/debian etch main contrib

Si noti che “dists” è aggiunto implicitamente, e che gli argomenti che seguono il nome del rilascio sono utilizzati per espandere il percorso su multiple directory.

Dopo aver aggiunto le proprie nuove fonti, si disabilitino le righe “deb” preesistenti in sources.list ponendo davanti ad esse un simbolo 'cancelletto' (#).


4.4.3 Aggiunta di fonti su CD-ROM o DVD per APT

Se si vogliono utilizzare soltanto CD-ROM, si disabilitino, commentandole, le righe “deb” preesistenti in /etc/apt/sources.list, ponendo davanti ad esse un simbolo 'cancelletto' (#).

Ci si accerti che vi sia in /etc/fstab una riga che abilitai l'accesso al proprio drive CD-ROM su /cdrom (apt-cdrom richiede che il filesystem sia montato esattamente su /cdrom). Ad esempio, se il drive del CD-ROM è chiamato /dev/hdc, /etc/fstab dovrebbe contenere una riga come la seguente:

     /dev/hdc /cdrom auto defaults,noauto,ro 0 0

Si noti che non deve essere presente nessuno spazio tra le parole defaults,noauto,ro nel quarto campo.

Per verificare il funzionamento, si inserisca un CD e si provi ad eseguire

     # mount /cdrom   # con questo comando si monterà il CD sul mount point
     # ls -alF /cdrom # con questo comando si dovrebbe visualizzare la directory di root del CD
     # umount /cdrom  # con questo comando si smonterà il CD

Quindi, si esegua:

     # apt-cdrom add

per ciascun CD-ROM di binari di Debian che si possiede, per aggiungere i dati su ciascun CD al database di APT.


4.5 Aggiornamento dei pacchetti

Il metodo raccomandato per l'aggiornamento dai precedenti rilasci di Debian GNU/Linux prevede l'utilizzo del gestore dei pacchetti aptitude. Tale programma rende le decisioni riguardanti le installazioni dei pacchetti più sicure che l'esecuzione diretta di apt-get.

Non ci si dimentichi di montare tutte le partizioni necessarie (in particolar modo le partizioni root e /usr) in lettura-scrittura, con un comando come:

     # mount -o remount,rw /mountpoint

Si dovrebbe poi controllare bene che le voci sulle sorgenti di APT (contenute in /etc/apt/sources.list) facciano riferimento a "etch" o a "stable". Non vi dovrebbero essere voci di fonti che puntino a sarge. Nota: le righe delle fonti per un CD-ROM faranno spesso riferimento ad "unstable"; sebbene ciò possa generare confusione, non le si dovrebbe modificare.


4.5.1 Registrazione della sessione

Si raccomanda vivamente di utilizzare il programma /usr/bin/script per registrare una trascrizione della sessione di aggiornamento. In tal modo, se si verificasse un problema, si disporrà di una registrazione di quanto accaduto, e, ove necessario, si potrà fornire le informazioni esatte in un'eventuale segnalazione su un bug. Per avviare la registrazione, si digiti:

     # script -t 2>~/upgrade-etch.time -a ~/upgrade-etch.script

completo o un simile comando. Non si collochi il file della registrazione in una directory temporanea come /tmp o /var/tmp (i file in queste directory potrebbero venir cancellati durante l'aggiornamento o durante un qualunque riavvio).

Il file generato permetterà anche di rileggere informazioni scorse fuori dalla schermata. Basta passare a VT2 (con Alt-F2) e, dopo aver effettuato il log-in, utilizzare il comando less ~root/upgrade-to-etch.typescript per visionare il file.

Dopo aver completato l'aggiornamento, si può arrestare script digitando al prompt exit.

Se si è utilizzato il parametro -t per script si può utilizzare il programma scriptreplay per un replay dell'intera sessione:

     # scriptreplay ~/upgrade-etch.time ~/upgrade-etch.script

4.5.2 Aggiornamento della lista dei pacchetti

Innanzitutto dev'essere recuperata la lista dei pacchetti disponibili per il nuovo rilascio. Lo si fa eseguendo:

     # aptitude update

Eseguire questo la prima volta che le nuove fonti sono aggiornate provocherà la stampa a schermo di alcuni avvisi relativi alla disponibilità delle fonti. Tali avvisi sono innocui e non appariranno se si eseguirà nuovamente il comando.


4.5.3 Assicurarsi di avere spazio a sufficienza per l'aggiornamento

Prima di aggiornare il proprio sistema ci si deve accertare di avere sufficiente spazio libero sull'hard disk al momento di fare partire l'aggiornamento completo del sistema descritto in Aggiornamento del resto del sistema, Sezione 4.5.6. Per prima cosa, ogni pacchetto necessario per l'installazione prelevato dalla rete è immagazzinato in /var/cache/apt/archives (e nella sottodirectory partial/, durante lo scaricamento), onde ci si dovrebbe accertare di avere spazio a sufficienza sulla partizione del filesystem che contiene /var per il temporaneo scaricamento dei pacchetti che saranno installati nel sistema. Dopo lo scaricamento,altre partizioni sarà probabilmente necessario ulteriore spazio in altre partizioni del filesystem al fine di installare sia i pacchetti aggiornati (che potrebbero contenere file binari più grossi o più dati), sia nuovi pacchetti che saranno introdotti con l'aggiornamento. Se il sistema non ha spazio a sufficienza, si potrebbe finire con un aggiornamento incompleto dal quale potrebbe risultare difficile ripristinare.

Sia aptitude, sia apt mostreranno informazioni dettagliate sullo spazio su disco necessario per l'installazione. Prima di eseguire effettivamente l'aggiornamento si può vedere questa stima con:

     
     # aptitude -y -s -f --with-recommends dist-upgrade
     [ ... ]
     XXX pacchetti aggiornati, XXX installati, XXX da rimuovere e XXX non aggiornati.
     È necessario prelevare xx.xMB/yyyMB di archivi. Dopo l'estrazione, verranno occupati AAAMB.
     Saranno scaricati/installati/rimossi pacchetti.

[8]

Se non si ha abbastanza spazio per l'aggiornamento, ci si accerti di liberare dapprima dello spazio. Si può:

Si noti che per una rimozione sicura dei pacchetti è consigliabile riportare il file sources.list a sarge, come descritto in Controllo della lista delle fonti, Sezione A.2.


4.5.4 Aggiornamento minimo del sistema

A causa di alcuni necessari conflitti tra pacchetti tra sarge e etch, l'esecuzione diretta di aptitude dist-upgrade rimuoverà spesso grandi quantità di pacchetti che si vorranno mantenere. Raccomandiamo dunque un processo di aggiornamento in due parti: prima un aggiornamento minimo che risolva questi conflitti, poi un dist-upgrade completo.

Si esegua in primo luogo:

     # aptitude upgrade

Questo ha l'effetto di aggiornare i pacchetti che possono essere aggiornati senza richiedere la rimozione o l'installazione di altri pacchetti.

Si segua la procedura di aggiornamento minimo con:

     # aptitude install initrd-tools

Questo passaggio aggiornerà automaticamente libc6 e locales e farà rientrare le librerie di supporto a SELinux (libselinux1). A questo punto, alcuni servizi in esecuzione saranno riavviati, inclusi xdm, gdm e kdm. Di conseguenza saranno disconnesse le sessioni locali di X11.

I seguenti passaggi dipendono dall'insieme di pacchetti che si hanno installati. Queste note di rilascio forniscono consigli generici riguardo quale metodo utilizzare, ma se si è in dubbio si raccomanda di esaminare le rimozioni di pacchetti proposte da ciascun metodo prima di procedere.

Alcuni pacchetti comuni che ci si aspetta siano rimossi comprendono base-config, hotplug, xlibs, netkit-inetd, python2.3, xfree86-common e xserver-common. Per un elenco più completo di pacchetti resi obsoleti in etch, si veda Pacchetti obsoleti, Sezione 4.10.


4.5.4.1 Aggiornamento di un sistema desktop

Questo percorso si aggiornamento è stato verificato funzionare su sistemi con installato il task desktop di sarge. È probabilmente il metodo che darà i migliori risultati su sistemi con il task desktop installato, o con i pacchetti gnome o kde installati.

Non è probabilmente il metodo corretto da usare se on si hanno già i pacchetti libfam0c102 e xlibmesa-glu installati:

     # dpkg -l libfam0c102 | grep ^ii
     # dpkg -l xlibmesa-glu | grep ^ii

Se si ha un sistema desktop completo installato, si esegua:

     # aptitude install libfam0 xlibmesa-glu

4.5.4.2 Aggiornamento di un sistema con alcuni pacchetti di X installati

Sistemi con alcuni pacchetti di X installati, ma non il task desktop completo, richiedono un metodo differente. Tale metodo si applica in generale ai sistemi con xfree86-common installato, compresi alcuni sistemi server che hanno task per server di tasksel installati, dato che alcuni task comprendono strumenti di gestione grafici. Sarà probabilmente il metodo corretto da utilizzare su sistemi su cui è eseguito X, ma che non hanno il task desktop completo installato.

     # dpkg -l xfree86-common | grep ^ii

Si verifichi per prima cosa se si hanno i pacchetti libfam0c102 e xlibmesa-glu installati.

     # dpkg -l libfam0c102 | grep ^ii
     # dpkg -l xlibmesa-glu | grep ^ii

Se non si ha libfam0c102 installato, non si includa libfam0 nella seguente riga di comando. Se non si ha xlibmesa-glu installato, non lo si includa nella seguente riga di comando.[9]

     # aptitude install x11-common libfam0 xlibmesa-glu

Si noti che l'installazione di libfam0 installerà anche il File Alteration Monitor (fam), nonché il RPC portmapper (portmap), se non già disponibili nel sistema. Entrambi i pacchetti abiliteranno un nuovo servizio di rete nel sistema, sebbene siano entrambi configurati per essere collegati al dispositivo di rete (interno) di loopback.


4.5.4.3 Aggiornamento di un sistema senza supporto a X installato

Su un sistema senza X, non dovrebbero essere richiesti comandi aptitude install aggiuntivi, e si può passare al passaggio successivo.


4.5.5 Aggiornamento del kernel

La versione di udev in etch non supporta versioni del kernel precedenti alla 2.6.15 (fra cui i kernel 2.6.8 di sarge), e la versione di udev in sarge non funzionerà correttamente con gli ultimi kernel. Inoltre, l'installazione della versione di udev in etch forzerà la rimozione di hotplug, utilizzato dai kernel Linux 2.4.

Di conseguenza, il precedente pacchetto del kernel probabilmente non si avvierà correttamente dopo questo aggiornamento. In modo simile, vi è una finestra di tempo durante l'aggiornamento in cui udev è stato aggiornato, ma non è stato installato l'ultimo kernel. Se il sistema si dovesse riavviare a questo punto, nel mezzo dell'aggiornamento, potrebbe non essere avviabile a causa del non corretto rilevamento e caricamento dei driver. (Si veda Preparazione di un ambiente sicuro per l'aggiornamento, Sezione 4.1.4 per raccomandazioni su come premunirsi per questa eventualità se si sta aggiornando da remoto.)

A meno che il sistema abbia il task desktop installato, o altri pacchetti che causarebbero un numero inaccettabile di rimozioni di pacchetti, è dunque raccomandato che si aggiorni a questo punto il solo kernel.

Per procedere con questo aggiornamento del kernel, si esegua:

     # aptitude install linux-image-2.6-flavor

Si veda Installazione del metapacchetto del kernel, Sezione 4.6.1 per un aiuto nella determinazione del flavor del pacchetto del kernel da installare.

Nel caso dei desktop, non è purtroppo possibile assicurare che il nuovo pacchetto del kernel sia installato immediatamente dopo l'installazione del nuovo udev, per cui vi è una finestra di tempo di durata non nota in cui il sistema avrà il pieno supporto ad hotplug senza alcun kernel installato. Si veda Aggiornare il kernel e i pacchetti collegati, Sezione 4.6 per informazioni su come configurare il proprio sistema perché non dipenda da hotplug per l'avvio.


4.5.6 Aggiornamento del resto del sistema

Si è ora pronti per continuare con la parte principale dell'aggiornamento. Si esegua:

     
     # aptitude dist-upgrade

Questo comando farà eseguire l'aggiornamento completo del sistema, che comprenderà p.e. l'installazione delle ultime versioni disponibili di tutti i pacchetti, e la risoluzione di tutti i possibili cambiamenti di dipendenze fra pacchetti di rilasci differenti. Se necessario, saranno installati alcuni nuovi pacchetti (solitamente nuove versioni di librerie, o pacchetti rinominati), e sarà rimosso qualunque pacchetto obsoleto che crei conflitti.

In caso di aggiornamento da una serie di CD-ROM, verrà chiesto di inserire uno specifico CD in parecchi momenti dell'aggiornamento. Potrebbe capitare di dover inserire più volte lo stesso CD: ciò è dovuto a pacchetti intercorrelati tra loro che sono stati distribuiti tra diversi CD.

Pacchetti attualmente installati disponibili in nuove versioni alle quali non possano essere aggiornati senza cambiare lo stato di installazione di un altro pacchetto, saranno lasciati alla loro attuale versione (contrassegnati come “held back”; “bloccàti indietro”, NdT). Questo fatto può essere risolto o utilizzando aptitude per designare tali pacchetti per l'installazione, o provando con aptitude -f install pacchetto.


4.5.7 Ottenere le firme dei pacchetti

Dopo l'aggiornamento, con la nuova versione di apt si può ora aggiornare le informazioni dei pacchetti, che comprenderanno il nuovo meccanismo di verifica delle firme dei pacchetti:

     # aptitude update

L'aggiornamento avrà già recuperato ed abilitato le chiavi di firma per gli archivi di pacchetti di Debian. Se si aggiungono altre fonti (non ufficiali) di pacchetti, apt stamperà avvertimenti relativi alla sua incapacità di confermare che i pacchetti scaricati da esse siano legittimi e non siano stati alterati. Per maggiori informazioni si veda Gestione dei pacchetti, Sezione 2.1.1.

Si noterà che, dal momento in cui si utilizza la nuova versione di apt, esso scaricherà file di differenze di pacchetti (pdiff) anziché la lista completa dei pacchetti. Per maggiori informazioni su questa caratteristica si legga Aggiornamenti più lenti dei file degli indici dei pacchetti per APT, Sezione 5.1.5.


4.5.8 Problematiche che potrebbero emergere durante l'aggiornamento

Se un'operazione che utilizza aptitude, apt-get o dpkg termina con l'errore

     E: Dynamic MMap ran out of room

lo spazio predefinito della cache è insufficiente. È possibile risolvere questo problema rimuovendo o riducendo a commenti righe inutili in /etc/apt/sources.list o aumentando la grandezza della cache. Si può aumentare la grandezza della cache dando un opportuno valore alla variabile APT::Cache-Limit in /etc/apt/apt.conf. Il seguente comando la imposterà ad un valore che dovrebbe essere sufficiente per l'aggiornamento:

     # echo 'APT::Cache-Limit "12500000";' >> /etc/apt/apt.conf

Questo assume che la variabile non sia ancora stata impostata in quel file.

A volte è necessario abilitare l'opzione APT::Force-LoopBreak perché APT possa rimuovere temporaneamente un pacchetto essenziale, per via di un un circolo “è in conflitto con”/“pre-dipende da”. Di norma aptitude emetterà un avviso e cesserà l'aggiornamento. Si può evitare ciò specificando l'opzione -o APT::Force-LoopBreak=1 nella riga di comando di aptitude.

C'è la possibilità che la struttura delle dipendenze di un sistema sia talmente corrotta da richiedere un intervento manuale. Solitamente ciò significa usare aptitude o

     # dpkg --remove nome_pacchetto

per eliminare alcuni dei pacchetti problematici, o

     # aptitude -f install
     # dpkg --configure --pending

In casi estremi si dovrebbe poter forzare la reinstallazione con un comando simile a

     # dpkg --install /percorso/di/nomepacchetto.deb

Non dovrebbero esserci conflitti tra file se si aggiorna da una etch pura, ma si potrebbero avere se sono stati installati backport non ufficiali. Un conflitto tra file causerà un errore simile al seguente:

     Spacchettamento di <pacchetto-tizio> (da
     <file-del-pacchetto-tizio>) ...
     dpkg: errore nel processamento di <pacchetto-tizio>
      (--unpack):
      tentativo di sovrascrivere `<nome-di-qualche-file>',
      che è anche nel pacchetto <pacchetto-caio>
     dpkg-deb: sottoprocesso paste ucciso da un segnale (Pipe rotta)
      Sono stati incontrati errori durante il processamento di:
      <pacchetto-tizio>

Si può cercare di risolvere un conflitto tra file rimuovendo forzatamente il pacchetto menzionato nell'ultima riga del messaggio di errore:

     # dpkg -r --force-depends nome_pacchetto

Dopo aver sistemato le cose, si dovrebbe poter riprendere l'aggiornamento ripetendo i comandi aptitude descritti in precedenza.

Durante l'aggiornamento verranno poste domande riguardanti la configurazione o riconfigurazione di parecchi pacchetti. Quando venga chiesto se un qualsivoglia file nelle directory /etc/init.d e /etc/terminfo o il file /etc/manpath.config debba venir rimpiazzato con quello fornito dal manutentore del pacchetto, di solito è necessario rispondere affermativamente, per garantire la coerenza del sistema. Si può sempre ritornare alle versioni precedenti, dal momento che verranno salvate con l'estensione .dpkg-old.

Se non si è sicuri sul da farsi, ci si annoti il nome del pacchetto o del file da sistemare, e si sistemino le cose in un momento successivo. Le informazioni presentate sullo schermo durante l'aggiornamento possono essere riesaminate dopo esser state cercate nel file generato da script.


4.6 Aggiornare il kernel e i pacchetti collegati

Questa sezione spiega come aggiornare il kernel ed identifica potenziali problematiche relative a tale aggiornamento. Si può o installare uno dei pacchetti linux-image-* forniti da Debian, o compilare un kernel personalizzato dai sorgenti.

Si noti che molte informazioni in questa sezione sono basate sull'assunzione che si userà uno dei pacchetti modulari di Debian, insieme con initramfs-tools e udev. Se si sceglie di usare un kernel personalizzato che non richiede un initrd o se si utilizza un generatore di initrd differente, alcune delle informazioni potrebbero non essere attinenti.

Si noti poi che se udev non è installato sul sistema, rimane possibile utilizzare hotplug per il rilevamento dell'hardware.

Se si sta utilizzando un kernel 2.4, si dovrebbe anche leggere attentamente Aggiornamento ad un kernel 2.6, Sezione 5.2.


4.6.1 Installazione del metapacchetto del kernel

Allorché si effettua un dist-upgrade da sarge a etch, è fortemente raccomandato che si installi un nuovo metapacchetto linux-image-2.6-*. Tale pacchetto potrebbe essere installato automaticamente dal processo di dist-upgrade. Lo si può verificare eseguendo:

     # dpkg -l "linux-image*" | grep ^ii

Se non si vede alcun output, si dovrà installare un nuovo pacchetto linux-image a mano. Per vedere un elenco dei metapacchetti linux-image-2.6 disponibili, si esegua:

     # apt-cache search linux-image-2.6- | grep -v transition

Se non si è sicuri riguardo quale pacchetto selezionare, si esegua uname -r e si cerchi un pacchetto con un nome simile. Ad esempio, se si vede '2.4.27-3-686', è consigliata l'installazione di linux-image-2.6-686. (Si noti che il flavor 386 non esiste più. Se si sta attualmente utilizzando il flavor 396 del kernel, si dovrebbe installare al suo posto il flavor 486.) Si può anche utilizzare aptitude per vedere una lunga descrizione di ciascun pacchetto che aiuti a scegliere il migliore disponibile. Ad esempio:

     # apt-cache show linux-image-2.6-686

Si dovrebbe quindi utilizzare aptitude install per installarlo. Una volta che questo nuovo pacchetto è installato si dovrebbe avviare alla prossima opportunità che si presenta per beneficiare della nuova versione del kernel.

Per i più avventurosi, esiste un modo agevole per compilare il proprio kernel personalizzato su Debian GNU/Linux. Si installi lo strumento kernel-package e si legga la documentazione contenuta in /usr/share/doc/kernel-package.


4.6.2 Aggiornamento da un kernel 2.6

Se si sta attualmente facendo girare un kernel della serie 2.6 di sarge, questo aggiornamento avrà luogo automaticamente dopo un aggiornamento completo del sistema (come descritto in Aggiornamento dei pacchetti, Sezione 4.5).

Se possibile, conviene aggiornare il pacchetto del kernel separatamente dal dist-upgrade per ridurre le possibilità di ritrovarsi con un sistema temporaneamente non avviabile. Si veda Aggiornamento del kernel, Sezione 4.5.5 per una descrizione di tale processo. Si noti che ciò dovrebbe essere fatto soltanto dopo il processo di aggiornamento minimo descritto in Aggiornamento minimo del sistema, Sezione 4.5.4.

Si può anche comprendere questo passaggio se si sta usando il proprio kernel personalizzato e si vuole utilizzare il kernel disponibile in etch. Se la versione del proprio kernel non è supportata da udev, si raccomanda l'aggiornamento completo dopo quello minimo. Se la versione è supportata da udev si può attendere in sicurezza finché non sia stato aggiornato l'intero sistema.


4.6.3 Aggiornamento da un kernel 2.4

Se si ha un kernel 2.4 installato, e il sistema si affida a hotplug per il rilevamento del suo hardware, si dovrebbe preliminarmente aggiornare ad un kernel della serie 2.6 di sarge prima di tentare l'aggiornamento. Ci si accerti che il kernel della serie 2.6 avvii il sistema e che tutto l'hardware sia correttamente rilevato prima di effettuare l'aggiornamento. Il pacchetto hotplug è rimosso dal sistema (a favore di udev) quando si esegue un aggiornamento completo del sistema. Se non si esegue l'aggiornamento del kernel prima di questo, il sistema potrebbe di qui in avanti non avviarsi correttamente. Una volta eseguito un aggiornamento ad un kernel della serie 2.6 in sarge si può eseguire un aggiornamento del kernel come descritto in Aggiornamento da un kernel 2.6, Sezione 4.6.2.

Se il sistema non si affida a hotplug[10], si può rimandare l'aggiornamento del kernel a dopo che si sia eseguito un aggiornamento completo del sistema, come descritto in Aggiornamento del resto del sistema, Sezione 4.5.6. Una volta che il sistema è stato aggiornato si può fare quanto segue (modificando il nome del pacchetto del kernel in quello più adatto al proprio sistema sostituendo <flavor>):

     # aptitude install linux-image-2.6-<flavor>

4.6.4 Riordino della numerazione dei dispositivi

etch si caratterizza per un meccanismo di rilevamento dell'hardware più robusto di quelli dei precedenti rilasci. Questo potrebbe tuttavia causare cambiamenti nell'ordine in cui i dispositivi vengono rilevati sul sistema, interessando l'ordine in cui i nomi dei dispositivi sono assegnati. Ad esempio, se si hanno due adattatori di rete, i dispositivi cui eth0 e eth1 fanno riferimento potrebbero venire scambiati. Si noti che il nuovo meccanismo significa che se p.e. si sostituiscono gli adattatori ethernet in un sistema etch in funzione il nuovo adattatore riceverà anche un nuovo nome di interfaccia.

Per i dispositivi di rete, si può evitare questo riordino utilizzando le regole di udev, più specificamente, tramite le definizioni in /etc/udev/rules.d/z25_persistent-net.rules[11]. In alternativa è possibile utilizzare l'utility ifrename per collegare dispositivi fisici a specifici nomi all'avvio. Per maggiori informazioni si vedano ifrename(8) e iftab(5). Le due alternative (ifrename e udev) non dovrebbero essere utilizzate entrambe allo stesso tempo.

Per i dispositivi di archiviazione, si può evitare questo riordino utilizzando initramfs-tools e configurandolo perché carichi i driver dei dispositivi di archiviazione nel medesimo ordine in cui sono attualmente caricati. Per fare ciò, si identifichi l'ordine in cui i moduli di archiviazione sul proprio sistema sono caricati guardando l'output di lsmod. lsmod elenca i moduli nell'ordine inverso di quello in cui sono stati caricati, p.e. il primo modulo della lista è l'ultimo che è stato caricato.

Rimuovere e ricaricare i pacchetti dopo l'avvio iniziale avrà tuttavia effetto su tale ordine. Inoltre, il kernel potrebbe avere alcuni moduli collegati staticamente, e i loro nomi non appariranno nell'output di lsmod. Si potrebbe riuscire a ricavare i nomi di tali driver e l'ordine del loro caricamento guardando il file /var/log/kern.log, o l'output di dmesg.

Si aggiungano i nomi di tali moduli al file /etc/initramfs-tools/modules nell'ordine in cui essi dovrebbero essere caricati all'avvio. Alcuni nomi di moduli potrebbero essere cambiati da sarge a etch. Ad esempio, sym53c8xx_2 è diventato sym53c8xx.

Si dovrà quindi rigenerare la/e propria/e immagine/i initramfs eseguendo update-initramfs -u -k all.

Una volta che si siano messi in funzione un kernel etch e udev, si può riconfigurare il proprio sistema perché acceda ai dischi tramite un alias che non dipenda dall'ordine di caricamento dei driver. Tali alias risiedono nella gerarchia /dev/disk/.


4.6.5 Problemi di temporizzazione dell'avvio

Se per l'avvio del sistema è utilizzato un initrd creato con initramfs-tools, in alcuni casi la creazione dei file dei dispositivi ad opera di udev può accadere troppo tardi perché gli script di avvio possano agire su di essi.

I sintomi consueti sono che l'avvio fallirà poiché il filesystem radice non può essere montato e si sarà rinviati ad una shell di debug, ma che quando in seguito si effettuerà una verifica tutti i dispositivi necessari saranno presenti in /dev. Ciò è stato osservato in casi in cui il filesystem radice è su un disco USB o in RAID, specialmente ove sia utilizzato lilo.

Un trucco per questa problematica è quello di utilizzare il parametro di avvio rootdelay=9. Il valore per il timeout (in secondi) potrebbe necessitare un aggiustamento.


4.7 Cose da fare prima di riavviare

Quando aptitude dist-upgrade è giunto al termine, l'aggiornamento “formale” è concluso, ma vi sono alcune altre cose di cui ci si dovrebbe preoccupare prima del successivo riavvio.


4.7.1 Conversione da devfs

I kernel Debian non includono più il supporto per devfs, cosicché gli utenti di devfs dovranno convertire i loro sistemi manualmente prima di avviare un kernel di etch.

Se si vede la stringa "devfs" in /proc/mounts, si sta nel caso più probabile utilizano devfs. Tutti i file di configurazione che facciano riferimento a nomi di dispositivo nello stile di devfs dovranno essere corretti così che utilizzino nomi nello stile di udev. I file che potrebbero verosimilmente fare riferimento a nomi di dispositivo nello stile di devfs comprendono /etc/fstab, /etc/lilo.conf, /boot/grub/menu.lst e /etc/inittab.

Sono disponibili maggiori informazioni sulle potenziali problematiche nella segnalazione #341152.


4.7.2 Rieseguire lilo

Se si sta utilizzando lilo come bootloader (è il bootloader predefinito per alcune installazioni di sarge), si raccomanda vivamente di rieseguire lilo dopo l'aggiornamento:

     # /sbin/lilo

Si noti che ciò è necessario anche se non si è aggiornato il kernel del sistema, dal momento che il secondo stage di lilo cambierà a causa dell'aggiornamento del pacchetto.

Si controllino inoltre i contenuti del file /etc/kernel-img.conf e ci si accerti di avervi do_bootloader = Yes. In tal modo il bootloader sarà sempre rieseguito dopo un aggiornamento del kernel.

Se si incontrano problematiche durante l'esecuzione di lilo, si controllino i link simbolici in / a vmlinuz e a initrd e i contenuti di /etc/lilo.conf per eventuali discrepanze.

Se ci si dimentica di rieseguire lilo prima del riavvio o se il sistema è riavviato accidentalmente prima che si possa fare ciò manualmente, il sistema potrebbe non riuscire ad avviarsi. Al posto del prompt di lilo, si vedrà soltanto LI all'avvio del sistema[12]. Per informaioni su come ripristinare da questa condizione, si veda Preparazione per il ripristino, Sezione 4.1.3.


4.7.3 Aggiornamento di mdadm

mdadm necessita ora di un file di configurazione per l'assemblaggio di array MD (RAID) dal ramdisk iniziale e durante la sequenza di inizializzazione del sistema. Ci si accerti di leggere il file /usr/share/doc/mdadm/README.upgrading-2.5.3.gz e di leggere le istruzioni in esso contenute dopo l'aggiornamento del pacchetto e prima di riavviare. L'ultima versione di tale file è reperibile all'indirizzo http://svn.debian.org/wsvn/pkg-mdadm/mdadm/trunk/debian/README.upgrading-2.5.3?op=file; lo si consulti in caso di problemi.


4.8 Preparazione per il prossimo rilascio

Prima dell'aggiornamento vi sono diverse cose che si possono fare per preparare per il prossima rilascio.


4.9 Pacchetti deprecati

Con il rilascio di Lenny saranno resi deprecati un maggior numero di pacchetti per server, dunque aggiornare ora a versioni più nuove di essi salverà da problemi chi aggiornerà poi a Lenny.

Ciò include i seguenti pacchetti:


4.10 Pacchetti obsoleti

Introducendo svariate migliaia di nuovi pacchetti, etch ritira e tralascia al tempo stesso più di duemila vecchi pacchetti che erano in sarge; non fornisce più aggiornamenti per tali pacchetti obsoleti. Mentre nulla impedisce che si continui ove lo si desideri ad utilizzare un pacchetto obsoleto, il progetto Debian interromperà solitamente il supporto per la sicurezza per lo stesso un anno dopo il rilascio di etch[13], e non fornirà normalmente nel frattempo altro supporto. Si raccomanda di sostituirlo con le alternative disponibili, se ve ne sono.

Vi sono molte ragioni per cui dei pacchetti potrebbero essere stati rimossi dalla distribuzione: non sono più mantenuti a monte; non c'è più uno sviluppatore Debian interessato al mantenimento dei pacchetti; la funzionalità che forniscono è stata superata da altro software (o da una nuova versione); o non sono più considerati idonei per etch a causa di bug in essi. Nell'ultimo caso, i pacchetti potrebbero tuttavia essere presenti nella distribuzione “unstable”.

Determinare quali pacchetti sono “obsoleti” in un sistema aggiornato è semplice, visto che le interfacce di gestione dei pacchetti li marcheranno come tali. Se si sta usando aptitude, si vedrà un elenco di tali pacchetti alla voce “Pacchetti Obsoleti e Creati Localmente”. dselect fornisce una sezione simile ma l'elenco che presenta potrebbe differire. Inoltre, se si è utilizzato aptitude per installare manualmente dei pacchetti in sarge, esso avrà tenuto traccia di quei pacchetti che si sono installati manualmente e potrà marcare come obsoleti quei pacchetti introdotti dalle sole dipendenze che non sono più necessari se un pacchetto è stato rimosso. In più, aptitude, diversamente da deborphan, non marcherà come obsoleti pacchetti che siano stati installati manualmente, al contrario di quelli che siano stati installati automaticamente attraverso dipendenze.

Vi sono strumenti aggiuntivi che si possono usare per trovare pacchetti obsoleti come deborphan, debfoster o cruff. deborphan è altamente raccomandato, anche se (nella modalità predefinita) avvertirà solamente di librerie obsolete: i pacchetti nelle sezioni “libs” o “oldlibs” che non sono utilizzati da alcun altro pacchetto. Non si rimuovano a occhi chiusi i pacchetti che tali strumenti indicano, specialmente se si stanno utilizzando opzioni aggressive non predefinite che tendono a produrre falsi positivi. È altamente raccomandata una revisione manuale dei pacchetti di cui è suggerita la rimozione (p.e. contenuti, grandezza e descrizione) prima della rimozione stessa.

Il Sistema di tracciamento dei bug (BTS) di Debian fornisce spesso informazioni aggiuntive sul perché un determinato pacchetto è stato rimosso. Si dovrebbero visionare sia i rapporti per il pacchetto stesso sia i rapporti archiviati dei bug per lo pseudo-pacchetto ftp.debian.org.


4.10.1 Pacchetti virtuali

Alcuni pacchetti di sarge sono stati suddivisi in diversi pacchetti in etch, spesso per migliorare la manutenibilità del sistema. Per facilitare in tali casi il percorso di aggiornamento, etch fornisce spesso pacchetti “virtuali”: pacchetti vuoti che hanno il medesimo nome del pacchetto in sarge con dipendenze che causano l'installazione dei nuovi pacchetti. Tali pacchetti “virtuali” sono considerati pacchetti obsoleti dopo l'aggiornamento e possono essere rimossi in tutta sicurezza.

Le descrizioni della maggior parte dei pacchetti virtuali (ma non di tutti) indicano il loro scopo. Le descrizioni dei pacchetti per i pacchetti virtuali non sono comunque uniformi, sicché si potrebbe anche trovare utile deborphan con l'opzione --guess per individuarli nel proprio sistema. Si noti che alcuni pacchetti virtuali non sono concepiti per la rimozione dopo un aggiornamento ma sono, invece, utilizzati per tenere traccia della versione attualmente disponibile di un programma nel tempo.


[ precedente ] [ Contenuti ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ A ] [ successivo ]


Note di Rilascio per Debian GNU/Linux 4.0 ("etch"), Intel x86

$Id: release-notes.it.sgml,v 1.32 2007-08-10 15:34:46 jseidel Exp $

Josip Rodin, Bob Hilliard, Adam Di Carlo, Anne Bezemer, Rob Bradford, Frans Pop (attuale), Andreas Barth (attuale), Javier Fernández-Sanguino Peña (attuale), Steve Langasek (attuale)
debian-doc@lists.debian.org
Luca Brivio (traduzione italiana) lucab83@infinito.it