# [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?   :Rolling Eyes:  )

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.   :Twisted Evil: 

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

```

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

```

segue ripetizione del comando senza opzione pv.

poi riaggiorno:

```

s939 ~ # emerge -uDNa @world

```

(uso portage in sviluppo)

controllo generale di coerenza:

```

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?

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

```

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.

 :Smile: 

** che ignoravo, grazie bender86.

----------

## bender86

 *cloc3 wrote:*   

> 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.*).

 *cloc3 wrote:*   

> È 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:
> 
> ```
> ...

 

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?

 *cloc3 wrote:*   

> 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

 *bender86 wrote:*   

> 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

 *cloc3 wrote:*   

>  *bender86 wrote:*   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.

 *cloc3 wrote:*   

> 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.
> ...

 

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

 *bender86 wrote:*   

> 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:

```

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:

 *man revdep-rebuild wrote:*   

> 
> 
> --library NAME | -L NAME
> 
>               Search for reverse dependencies for a particular library ...
> ...

 

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

 :Smile: 

----------

## 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

 *man revdep-rebuild wrote:*   

> --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

 *bender86 wrote:*   

> 
> 
> Ho capito bene?

 

Direi di sì

----------

## cloc3

 *cloc3 wrote:*   

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

 

 *bender86 wrote:*   

> 
> 
> significa che li riemerge direttamente, senza fare nessun controllo?
> 
> 

 

 :Smile: 

certo che è curioso.

siamo riusciti a decrivere lo stesso fenomeno, usando parole diametralmente opposte.

----------

## bender86

 *cloc3 wrote:*   

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

 

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

```
> /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.

----------

