[gentoolkit] il downgrade delle qt

[cloc3]

le nuove qt (4.7.*) non sono ancora mature per gli utenti finali.
(balordi: non quegli utenti finali - a cosa state pensando? )
con le schede intel di pochi soldi, infatti, combinano più di qualche pasticcio.
dopo pochi tentativi, mi sono trovato costretto a impostare il downgrade.

disdetta. emerge non vuole.
il downgrade delle qt non è supportato, e potrebbe corrompere il sistema.
è no! la mia gentoo box deve obbedire a me, non a emerge.

che faccio? prima di tutto, elimino le qt esistenti:

Code: Select all

s939 ~ # emerge -Cpv $(qlist -IC x11-libs/qt)

segue ripetizione del comando senza opzione pv.

poi riaggiorno:

Code: Select all

s939 ~ # emerge -uDNa @world

(uso portage in sviluppo)

controllo generale di coerenza:

Code: Select all

s939 ~ # emerge -a @preserved-rebuild
s939 ~ # revdep-rebuild -ipv

meraviglioso. esito negativo.
in apparenza, il sistema appare perfettamente stabile!

qui mi è sorto un sospetto. se era così facile, perché emerge ha rifiutato di eseguire la stessa operazione in automatico?
forse, per una ragione che ignoro (**), i pacchetti compilati contro le qt-4.7 potrebbero manifestare comportamenti indesiderati se forzati ad usare le qt-4.6 e dovrebbero quindi essere ricompilati uno ad uno. se così fosse, date le dimensioni di un simile impegno (centinaia di ebuild), si capirebbe bene la scelta degli sviluppatori di non supportare il downgrade.

ne è nato un piccolo problema di manutenzione, che al tempo stesso è un esercizio istruttivo e una sfida agli strumenti gentoo.
È possibile individuare in un modo pulito la totalità dei pacchetti lincati contro le qt e ricompilarli d'un fiato?

Certamente sì! in una sola riga di codice:

Code: Select all

s939 ~ # nohup revdep-rebuild -ipv --library $(qlist -C x11-libs/qt|grep \
--color=never "\.so\.4$"|xargs|sed 's/ /|/g') >revdep.log 2>&1 &

disclaimer: il comando richiede tre volte pazienza.
pazienza: per eseguire la ricerca, che è piuttosto lunga.
pazienza: per controllare i log e verificare la consistenza del sistema. qui ho dovuto risolvere un insieme di blocchi di dipendenze non banali, che mi hanno costretto a mettere un po' d'ordine in /etc/portage, dove non tutto era un giardino di fiori.
pazienza: per rilanciare il comando in compilazione, senza l'opzione -ipv.

ci è voluto il tempo che ci voleva, ma al termine ho riavuto la mia gBox, ripulita come un culetto di bimbo.


** che ignoravo, grazie bender86.

[bender86]

forse, per una ragione che ignoro, i pacchetti compilati contro le qt-4.7 potrebbero manifestare comportamenti indesiderati se forzati ad usare le qt-4.6 e dovrebbero quindi essere ricompilati uno ad uno.

Già. Se un programma viene compilato con Qt 4.7 potrebbe abilitare alcune funzioni che non esistono su 4.6, quindi non funzionerebbe su queste ultime. Ciò non succede all'interno della stessa versione (compilato su 4.6.23 -> funziona su qualsiasi 4.6.*).

È possibile individuare in un modo pulito la totalità dei pacchetti lincati contro le qt e ricompilarli d'un fiato?

:) Certamente sì! in una sola riga di codice:

Code: Select all

s939 ~ # nohup revdep-rebuild -ipv --library $(qlist -C x11-libs/qt|grep \
--color=never "\.so\.4$"|xargs|sed 's/ /|/g') >revdep.log 2>&1 &

Non mi torna... Così stai dicendo a revdep-build di controllare tutte le librerie dei pacchetti qt. Ma se lo lanci senza opzioni, non dovrebbe controllare tutte le librerie sul sistema?

ci è voluto il tempo che ci voleva, ma al termine ho riavuto la mia gBox, ripulita come un culetto di bimbo.

Ci sono state delle differenze tra revdep-rebuild liscio, e il comando che hai dato te?

[cloc3]

Ma se lo lanci senza opzioni, non dovrebbe controllare tutte le librerie sul sistema?

non ho detto di rilanciarlo senza opzioni, ma, senza le opzioni -ipv. cioè conservando l'opzione library, che è fondamentale.

sta proprio qui la differenza con un revdep-rebuild semplice.
il revdep-rebuild semplice cerca le librerie mancanti, non le librerie sbagliate.
dopo aver rimosso le qt nuove e ripristinato (con emerge -uDNa @world) quelle nuove, il sistema si trova in uno stato stabile (apparentemente, cioè dal punto di vista del revdep-rebuild semplice). infatti, nessuna libreria risulta mancante e il controllo di coerenza è negativo.
in pratica, il revdep-rebuild semplice non è in grado di distinguere la versione 4.6 dalla 4.7.

ecco la necessità di ricorrere a una procedura di ricerca più selettiva con l'opzione --library.
ma, purtroppo, anche molto più pesante.

[bender86]

Ma se lo lanci senza opzioni, non dovrebbe controllare tutte le librerie sul sistema?

non ho detto di rilanciarlo senza opzioni, ma, senza le opzioni -ipv. cioè conservando l'opzione library, che è fondamentale.

Sì, quello che non capisco è proprio la differenza tra specificare le librerie o lasciare fare a lui.

sta proprio qui la differenza con un revdep-rebuild semplice.
il revdep-rebuild semplice cerca le librerie mancanti, non le librerie sbagliate.
dopo aver rimosso le qt nuove e ripristinato (con emerge -uDNa @world) quelle nuove, il sistema si trova in uno stato stabile (apparentemente, cioè dal punto di vista del revdep-rebuild semplice). infatti, nessuna libreria risulta mancante e il controllo di coerenza è negativo.
in pratica, il revdep-rebuild semplice non è in grado di distinguere la versione 4.6 dalla 4.7.

Questo è quello che non capisco. Hai specificato di controllare solo i file "*.so.4" che fanno parte delle librerie Qt. Perché revdep-rebuild non li controlla quando viene lanciato senza parametri? Non dovrebbe controllare tutte le librerie sul sistema?

[cloc3]

Perché revdep-rebuild non li controlla quando viene lanciato senza parametri?

chi ha detto che non li controlla?
li controlla senz'altro. solo che prende le decisioni in logica negata.
per esempio:

Code: Select all

cloc3@aspi2 ~ $ ldd `which ls`|tail -1
	libattr.so.1 => /lib/libattr.so.1 (0xb75bd000)

supponiamo a che me stiano sul'anima tutti i pacchetti lincati contro libattr.so.1.
se lancio revdep-rebuild senza parametri, il programma ls viene controllato con esito negativo.
quindi non viene richiesta alcuna compilazione.
se volessi ricompilare ls, facendo uso di revdep-rebuilb, dovrei rimuovere o spostare il file /lib/libattr.so.1.

ma converrai che sarebbe un po' scemo. molto meglio lanciare revdep-rebuild con l'opzione --library e il parametro libattr.so.1, perché in questo caso il controllo darebbe esito positivo:

--library NAME | -L NAME
Search for reverse dependencies for a particular library ...
Emerge packages that use the named library.

e a pensarci bene, anche alla luce di questo topic, se non fosse così, gli sviluppatori gentoo avrebbero scritto un programma stupido...

[bender86]

Allora non avevo la minima idea di cosa facesse revdep-rebuild.
Pensavo:
- controlla tutte le librerie sul sistema;
- per ognuna di esse controlla tutti i binari che la usano;
- trova tutti quelli che hanno qualche problema (tipo usano simboli non definiti);
- ricompila i pacchetti corrispondenti.
In effetti non sembra molto fattibile.

Se adesso invece ho capito dovrebbe essere:
- controlla tutti i binari sul sistema;
- per ognuno di essi controlla che esistano tutte le librerie;
- ricompila quelli che usano librerie inesistenti.

Quindi

--library NAME | -L NAME
Search for reverse dependencies for a particular library ...
Emerge packages that use the named library.

significa che li riemerge direttamente, senza fare nessun controllo?

Quindi (prendendo esempio dall'ultimo aggiornamento ssl 0.9->1.0), emerge lascia libssl.0.9.so, io lancio revdep-rebuild --library libssl.0.9.so, lui ricompila tutti i pacchetti che la usano, che verranno linkati a libssl.1.so. A quel punto la libreria vecchia si può eliminare.
Ho capito bene?

[Onip]

Ho capito bene?

Direi di sì

[cloc3]

chi ha detto che non li controlla?
li controlla senz'altro.

significa che li riemerge direttamente, senza fare nessun controllo?

certo che è curioso.
siamo riusciti a decrivere lo stesso fenomeno, usando parole diametralmente opposte.

[bender86]

:)
certo che è curioso.
siamo riusciti a decrivere lo stesso fenomeno, usando parole diametralmente opposte.

Beh, con "senza fare nessun controllo" io intendevo:

Code: Select all

> /lib/libc.so
revdep-rebuild --library /lib/libc.so

revdep-rebuild ricompila tutti i pacchetti che usano libc.so, senza nemmeno accorgersi che quella non è più nemmeno una libreria.

Grazie per la spiegazione.