Qualche opzione di emerge

Gentoo mi piace, però qualche volta mi ritrovo con un sistema impossibile da aggiornare o con qualche problema di update; questa volta è stato un aggiornamento di perl, per scoprirlo ho dovuto leggere le news di gentoo come indicato alla fine dell’ultimo emerge:

$ eselect news list
News items:
[1]   read    2009-04-06  Migration to X.org Server 1.5
[2]   read    2009-04-18  Generation 1 Java Setup Deprecated
[3]   read    2009-07-12  xorg-x11-7.4 and xorg-server-1.5 kernel support
[4]   read    2009-10-02  Migration to X.org Server 1.6 and libxcb 1.4
[5]   read    2009-10-08  Upgrade to GNOME 2.26
[6]   read    2010-01-31  Removal of libGL.la
[7]   read    2010-02-28  Layman storage path changed from version 1.3.0 on
[8]   read    2010-02-21  MySQL 5.1 unmasking and upgrade procedures
[9]   read    2010-03-23  New desktop subprofiles for GNOME and KDE
[10]  read    2010-04-23  Upgrade to GNOME 2.28
[11]  read    2010-03-25  Python 3.1
[12]  read    2010-08-01  –as-needed enabled in default profiles
[13]  read    2010-10-22  Perl 5.12 upgrade procedure

Possiamo leggere la news nella maniera seguente

$ eselect news read 13
2010-10-22-perl-5.12-upgrade-procedure
Title                     Perl 5.12 upgrade procedure
Author                    perl-team <perl@gentoo.org>
Author                    Torsten Veller <tove@gentoo.org>
Posted                    2010-10-22
Revision                  1

==> Run `perl-cleaner –all` after upgrading to a new Perl version! <==

“Perl 5.12 is not binary compatible with prior releases of Perl. If
you have built extensions (i.e. modules that include C code) using an
earlier version of Perl, you will need to rebuild and reinstall those
extensions.” [1]

In fact, in Gentoo you currently have to rebuild all Perl modules and
all binaries linking libperl to get into a consistent state again.

perl-cleaner generates a list of broken packages and passes it to your
package manager to reinstall them. After reinstalling the packages,
perl-cleaner outputs a list of files the script could not deal with
(like modules installed not via the package manager).

See `man perl-cleaner` for its options.

[1] http://search.cpan.org/dist/perl-5.12.2/INSTALL#Changes_and_Incompatibilities

Il problema è che lanciando perl-cleaner non ottenevo l’effetto sperato in quanto mi diceva che dovevo unmaskare (~x86) un casino di pacchetti. Il problema non è l’unmaskare i packages (o almeno, se sai cosa stai facendo) ma il fatto che (di default) una volta lanciato l’emerge, esso ti manda l’avviso che bisogna unmaskare, però indicando solo il primo package che ha dato problema. Quindi se ce ne sono 15 ti tocca rilanciarlo 15 volte e non è carino visto che non è immediato.

Un primo approccio è stato de-unmaskare tutti i pacchetti che con i vari upgrade precedenti avevo unmaskato nell’ottica di eliminare dipendenze inverse particolari. Purtroppo anche de-unmaskando la situazione non è cambiata e quindi mi sono detto “è possibile che non esista una opzione che mi permetta di vedere in un colpo solo tutti i pacchetti che hanno problemi nell’emerge che voglio fare?” e ho pensato al sacro principio sancito dal RTFM.

Leggere la pagina di emerge è stata la mossa vincente e mi ha fatto arrivare alla seguente combinazione di opzioni (solo l’ultima è una innovazione, le altre le usavo già di default ma già che ci sono vi illumino di sapienza)

emerge --ask --update --verbose --deep --keep-going=True --autounmask system world

che posso spiegare brevemente così

• –ask: prima di effettuare l’effettivo aggiornamento chiedi
• –update: esegui l’aggiornamento dei pacchetti che hanno degli aggiornamenti disponibili
• –deep: esegui l’update anche per le dipendenze (l’opzione precedente aggiorna solo i pacchetti contenuti nel world, questa opzione dice di aggiornare anche i pacchetti da cui questi dipendono)
• –keep-going: in caso di errore nell’emerge continua con i rimanenti
• –autounmask: se ci sono dei pacchetti che per qualche motivo bloccano l’upgrade, mostra quali cambiamenti si necessitano e blocca l’upgrade

È proprio questa ultima opzione quella che cercavo: se ci sono problemi si blocca e mostra cosa bisogna scrivere in package.keyword e package.use per mandare a buon fine l’upgrade. Una volta copiato il tutto l’upgrade va che è un piacere e finalmente dopo più di un mese ho una installazione gentoo senza problemi di upgrade.

Liberare spazio in gentoo

Mi succede a volte che il mio spazio su disco si riempa, sopratutto sul portatile dove risiede la mia installazione di gentoo; dopo una piccola analisi a colpi di du(1) ho scoperto che la directory /usr/portage/distfiles/ contiene gli archivi dei sorgenti usati per le installazioni tramite emerge(1): per pulire questa roba bisogna usare il comando eclean(1). In particolare bisogna usare l’opzione –destructive in quanto altrimenti mantiene qualunque archivio per cui esiste un ebuild da qualche parte, con questa opzione invece elimina gli archivi dei programmi non più installati (versioni vecchie per esempio).

In questa maniera si liberano almeno qualche GB. 

OAFIID:GNOME_ClockApplet

Ogni tanto mi compaiono errori molto strani sul mio portatile e questa volta è toccato all’orologio nella barra del pannello gnome; quando mi loggavo nel mio account campariva un laconico messaggio

"OAFIID:GNOME_ClockApplet". Do you want to delete the applet from your
configuration?

Siccome l’orologio (in termini tecnici una applet) non è una vera e propria applicazione, ma una specie di plugin che la barra di gnome può caricare all’occorrenza, risulta difficile capire come trovare l’errore (fosse un’applicazione la lanci da terminale e speri in qualche warning sgamo). Grazie a Dyo esiste google ed ho trovato questo: in pratica controllando con ldd si può ottenere l’elenco di librerie che un programma necessita per funzionare; nel mio caso particolare ottengo

packz@godel ~ $  ldd /usr/lib/gnome-panel/libclock-applet.so | grep ‘not found’
    libssl3.so.12 => not found
    libsmime3.so.12 => not found
    libnssutil3.so.12 => not found
    libnss3.so.12 => not found
    libssl3.so.12 => not found
    libsmime3.so.12 => not found
    libnssutil3.so.12 => not found
    libnss3.so.12 => not found

Ohibo, quante librerie mancano? ovviamente devo dirvi che tutto questo avviene su gentoo;-) il programma per il controllo delle dipendenze inverse di hokuto delle librerie della scuola di Nanto esiste revdep-rebuild che però purtroppo in cotale caso non funziona automaticamente ma necessita di un mio aiuto; con l’aiuto della shell vincerò

LIBRARY=$(ldd /usr/lib/gnome-panel/libclock-applet.so | grep ‘not found’ | awk ‘{print "–library "$1}’ ); revdep-rebuild -i -p  $LIBRARY

 L’opzione -p serve a simulare l’azione da intraprendere (revdep-rebuild altrimenti partirebbe ad installare tutto in automatico). Una volta che il programma ha terminato ed emesso la sentenza, è possibile rilanciarlo senza argomenti per fargli eseguire realmente l’aggiornamento.

Prendete una birra e aspettate che finisca, lanciate killall gnome-panel e dopo un po’ di sfarfallio dovrebbe ricomparire la barra con l’orologio.