L’aggiornamento alla nuova versione di Ubuntu è semplicemente acquolinoso:
Una volta lanciato il comando che vedete nella schermata basta leggere le istruzioni:
Molto carino… anche se non ho avuto ancora la voglia di prendere una decisione.
Ok, adesso… ogni deficiente può aggiornare Dapper->Edgy, ma noi che amiamo le cose eleganti vogliamo che l’aggiornamento consista di un solo comando e un solo riavvio del PC. Vorrei quindi dare un paio di consigli per aggiornare “bene“, specialmente a chi ha sfruculiato con repository “esotici” aggiungendo linee in sources.list. Ecco la procedura più corretta per non fare impazzire APT a risolvere dipendenze di cose che *non può sapere*. Questi passi vanno compiuti *prima* di aggiornare
Individuare i pacchetti non ufficiali installati nel sistema
Prima cosa da fare: segnarsi *cosa* c’è di esotico, ossia di non standard/ufficiale, nella vostra Dapper. Per fare questo basta dare un occhio in sources.list, ad esempio tra quelli che io ho spiccano per “esoticità” i repository di Gandalfn. Per fortuna una prassi di chi mantiene repository è quella di “segnare” i pacchetti, quindi tutti i pacchetti di quel repository hanno il numero di versione che termina per “~gandalfn”
A questo punto in Synaptic è facilissimo, tramite la funzione “Cerca”, individuare tutti i pacchetti di gandalfn:
Correggere potenziali problemi
l consiglio che do a questo punto è duplice:
- Se esiste una versione ufficiale del pacchetto, ossia fornita dai repository di Ubuntu, riportare la versione dei pacchetti a quella di Ubuntu. Questo si fa grazie alla funzione “Forza versione” nel menu “Pacchetto” di Synaptic.
- Se non esiste alcuna versione del pacchetto all’interno dei repository ufficiali è meglio disinstallare i pacchetti “incriminati”. Potrete poi installarli nuovamente quando avrete Edgy :-)
Nella schermata qui sopra potete vedere che i primi due pacchetti della lista si chiamano compiz-freedesktop e compiz-freedesktop-gnome. Notate che, anche se il contenuto è simile, i pacchetti originali per Ubuntu si chiamano semplicemente “compiz”. Quindi nel mio caso devo applicare la seconda opzione: disinstallarli
Dopo si può procedere all’eliminazione (o al commento) delle linee incriminate in sources.list
Individuare i pacchetti “locali o obsoleti”
Per questi pacchetti c’è la comoda e omonima categoria in Synaptic, per visualizzarla basta cliccare su “Stato” in basso a sinistra, e scegliere appunto “locale o obsoleto” dalla lista a sinistra. Sono tutti quei pacchetti che non sono in nessun repository e che avete installato sconsideratamente seguendo le mie guide :D
Per questi pacchetti il consiglio più sensato è: eliminate senza pietà, ci sono buone probabilità che non funzioneranno su Edgy.
Conclusioni
E’ tutto, questa semplice pulizia dovrebbe eliminare ogni problema di “tentata sovrascrittura del file X appartente al pacchetto Y” tipico quando si è installata molta roba non ufficiale.
Ovviamente il buon senso e un pizzico di esperienza valgono più di ogni altra cosa, quindi buone pulizie e buon aggiornamento :)
hmm, bel dilemma: to edgy or not to edgy. Ati sbrigati a rilasciare i drivers per aixgl che così la scelta si semplifica!
Ma non volevi passare a FC6? :D
hahaha se è per questo al momento sono fermo con Dapper… sono veramente indeciso :)
Convinto dal tuo articolo (ma soprattutto dalla portante della mia ADSL, che ieri sera ha deciso di prendersi una vacanza, impedendomi attività online maggiormente sociali), mi sono deciso a spulciare un po’ i pacchetti via synaptic, giusto per essere ben preparato all’avvento di edgy.
E ho avuto qualche sorpresa che, francamente dopo anni di apt, non mi aspettavo.
Premesso che non faccio una reinstallazione completa dai tempi di Hoary, un po’ di pasticcio è comprensibile, ma mi sono ritrovato ad eliminare ben 170 MB in pacchetti obsoleti.
Obsoleti non nel senso di “listati nella pagina apposita di synaptic”, ma nel senso di “stesso pacchetto, versione vecchia” rimasti lì ma non utilizzati da niente. C’erano librerie installate in 4 versioni diverse, le 3 più vecchie “purgabili” senza che per questo il sistema disinstallasse nessun altro file.
Quindi la prima domanda che mi pongo è: com’è possibile? Forse occorrerebbe un po’ più di accortezza per stabilire se una lib dev’essere tenuta o cancellata dal sistema alla disinstallazione del programma che la usa (o all’installazione della versione nuova della medesima lib).
Purgati anche quelli che sono sicuro siano “locali”, nella pagina “locale od obsoleto” rimangono ancora un bel po’ di pacchetti nel mio sistema. E non mi fido a rimuoverli, visto che a quanto pare ci sono pacchetti “ubuntu official” che dipendono da questi e se disinstallo tutto ciò che ho listato come “locale od obsoleto” mi tira via mezzo sistema (naturalmente non parlo di metapacchetti come ubuntu-desktop ma di pacchetti effettivi)
La seconda domanda allora è: com’è possibile che un pacchetto del repository dipenda da un pacchetto riconosciuto come “locale/obsoleto”?
Mi sono detto che era più probabile che fosse synaptic a valutare come obsoleto un pacchetto che non lo era…
Certo, stamattina mi sono accorto che non ho guardato se esisteva per tutti quei pacchetti una versione “ufficiale”, ma mi sembrano comunque tantini per avere tutti una versione ufficiale… mah. Rimedierò stasera con una spulciata più approfondita, se è il caso pacchetto per pacchetto.
Giusto per dire che forse il consiglio “eliminate senza pietà” è forse un tantino drastico.. ^_^;
Che senso ha aggiormare Dapper a una RC1 due giorni prima che esca la finale ?
La RC1 è già finale ? manca solo il SI di Mr.Ubuntu ?
@Habayusa:
Hai detto bene, non può essere che un pacchetto ufficiale dipenda da uno obsoleto! Infatti nel 100% dei casi troverai che esiste un pacchetto ufficial che magari ne richiede anche altri per sostituire le funzionalità offerte da pacchetti obsoleti. Il comportamento di APT in questi casi è conservativo.
Per le vecchie versioni installate… se sono nei repository significa che sono ancora utili a qualcosa, ossia se non sono nella pagina “obsoleti” significa appunto che non sono obsoleti :)
Sono d’accordo anche quando dici che forse sarebbe il caso di installare da zero… effettivamente Hoary->Breezy->Dapper->Edgy non è esattamente il massimo, non in quanto a funzionalità, perché difficilmente avresti problemi con apt, ma per pulizia :)
@antonio:
beh non si sa mai, non sarebbe la prima volta che cambiano funzionalità anche importanti proprio all’ultimo minuto, per questo ho scritto di aspettare il rilascio ufficiale “coscienziosamente” :)
Naturalmente sono coscio del fatto che sicuramente una installazione “da capo” sia preferibile quanto a pulizia, ma vuoi mettere la goduria di aggiornare un sistema operativo continuando nel mentre a chattare, postare etc… facendo UN riavvio alla fine e stop, mentre sul winxp del babbo per installare un antivirus sono serviti 4 reboot? :D
A parte ciò, stasera farò qualche ricerca ulteriore e più dettagliata sui pacchetti rimasti in “locale/obsoleto”, per vedere che si può fare ancora. Dopotutto oltre al testing di una installazione pulita, serve anche qualcuno che testi un upgrade come il mio. :)
Quel che rimane dl discorso è che comprendo la necessità di essere conservativi perché concordo che è meglio un sistema un po’ più “sporco” che un sistema piantato, ma forse apt potrebbe migliorarsi con qualche controllo in più (essere il migliore non vuol dire non potersi migliorare, no? )
Se installo “libfoo” versione x+1 è ho correntemente già operativa “libfoo” versione X, si potrebbe fare un controllo di dipendenze: cioè stabilire quali pacchetti installati richiedono la dipendenza da libfoo = X e quali da libfoo >= X.
Se ho solo pacchetti del secondo tipo (auspicabile), posso tranquillamente disinstallare libfoo X, in caso contrario si può cercare se esiste un pacchetto aggiornato che dipende da libfoo >= X e proporre l’aggiornamento anche di quello per poter togliere la libreria obsoleta e sarà l’admin a decidere se preferisce tenere di tutto la versione vecchia o aggiornare liberandosi della lib obsoleta.
Ancora meglio: aggiungendo nel database di apt un banale “counter” su quanti pacchetti dipendono da libfoo X, quando questo counter tocca zero libfoo X viene disinstallata in automatico ma potrà sempre venire reinstallata alla richiesta di un pacchetto con dipendenza specifica.
Naturalmente il discorso vale per le librerie, non per le applicazioni, che solitamente sono all’ultimo gradino della catena di dipendenze (dipendono da tutto ma da loro non dipende niente).
il “counter” che tu dici esiste già ed è appunto “autoremove”, funzione entrata da poco in apt. per la faccenda “conservativo vs sciagurato” non so… sono sostanzialmente d’accordo ma mi sta bene anche così, boh dipende molto dai casi specifici.
Generalmente un utente “normale” non si rende conto di qualche libreria in più e se te ne rendi conto …significa che sai come gestire la situazione …e se sai gestire la situazione, significa che sai mettere mano nelle budella di apt e quindi che sai come eliminare quei pacchetti. :D
cmq a breve scriverò qualcosa sulla pulizia maniacale di pacchetti e librerie :D
Pingback:Come tenere maniacalmente pulita una Ubuntu « pollycoke :)
NOTIZIA STRAORDINARIA.
EDGY EFT RILASCIATA.
Pingback:Aggiornamento (dist-upgrade): un problema solo per Ubuntu? « pollycoke :)
Pingback:Aggiornamento da Ubuntu Drapper Drake 6.06 a Ubuntu Edgy Eft 6.10 « sblogghiamo
Pingback:Da Ubuntu Edgy a Feisty: aggiornamento a prova di bomba! [gallery] « pollycoke :)
Pingback:The buffer Blog » Aggiornamento Edgy to Feisty
Pingback:Generazione Web » Come tenere maniacalmente pulita una Ubuntu