# [atom] dipendenze. dubbio sui due punti[risolto]

## cloc3

ho bisogno di eseguire il downgrade di una installazione a libpng-1.2.44.

per certi pacchetti (ad esempio media-libs/gd), compare la  seguente dipendenza:

```

s939 ~ # grep -rH png? /usr/portage/media-libs/gd/

/usr/portage/media-libs/gd/gd-2.0.35-r2.ebuild:   png? ( >=media-libs/libpng-1.2.43-r2:0

/usr/portage/media-libs/gd/gd-2.0.35-r1.ebuild:   png? ( >=media-libs/libpng-1.2.43-r2:0

s939 ~ # qatom -c media-libs/libpng-1.2.44 media-libs/libpng-1.2.43-r2:0

media-libs/libpng-1.2.44 > media-libs/libpng-1.2.43-r2:0

```

eppure:

```

s939 ~ # emerge -pv media-libs/gd

These are the packages that would be merged, in order:

Calculating dependencies... done!

!!! All ebuilds that could satisfy ">=media-libs/libpng-1.2.43-r2:0" have been masked.

!!! One of the following masked packages is required to complete your request:

- media-libs/libpng-1.4.3 (masked by: package.mask)

(dependency required by "media-libs/gd-2.0.35-r1" [ebuild])

(dependency required by "media-libs/gd" [argument])

For more information, see the MASKED PACKAGES section in the emerge

man page or refer to the Gentoo Handbook.

```

secondo me, nel mio sistema, libpng-1.2.44 non è mascherato:

```

s939 ~ # grep -rH libpng /etc/portage

/etc/portage/package.mask/media-libs:>media-libs/libpng-1.4

s939 ~ # qatom -c media-libs/libpng-1.2.44 media-libs/libpng-1.4

media-libs/libpng-1.2.44 < media-libs/libpng-1.4

 
```

c'è qualcosa che non mi torna.

----------

## Onip

non ti torna lo slot.

I pacchetti richiedono un pacchetto che sia > 1.2.43-r2, ma nello slot 0, attualmente (sync di ieri) c'è solo 1.4.3 che soddisfa le richieste.

E poi 1.2.44 installa solamente i .so, niente .h quindi non riusciresti ad usarlo per compilare niente: serve solo per eseguire i vari -bin che ancora sono compilati con la vecchia versione 1.2 di libpng, tipo www-client/chromium-bin

----------

## cloc3

 *Onip wrote:*   

> non ti torna lo slot.
> 
> 

 

mi spiegheresti, per cortesia, cosa si intende per slot?

è un concetto che non mi è ancora ben chiaro.

il guaio è che sto tendando il downgrade perché in quella installazione uso vmware, che continua a distribuire i binari linkati alle libpng-1.2*.

come se ne potrebbe uscire?

p.s: sto cominciando a capire.

gentoo mi permette tranqillamente di mantenere entrambe le librerie senza conflitti.

----------

## Onip

 *cloc3 wrote:*   

> 
> 
> come se ne potrebbe uscire?
> 
> 

 

Io sul portatile ho chromium-bin installato e ho entrambe le versioni di libpng installate. Ci pensa portage (se l'ebuild è scritto bene). Qui qualche indicazione in più.

 *cloc3 wrote:*   

> mi spiegheresti, per cortesia, cosa si intende per slot?

 

Normalmente di un pacchetto si può avere una sola versione installata nel sistema. Con l'utilizzo degli slot (la sintassi nell'atom è categoria/pacchetto:numero_slot) viene reso possibile, tecnicamente non so come eh  :Very Happy: , si rende possibile la presenza di più versioni in parallelo, una per slot.

libpng, in questo caso, è un po' atipico in quanto la versione 1.2 è mantenuta solamente per compatibilità con "vecchi" pacchetti binari ed è, quindi, "mutilata" degli header. Normalmente le versioni parallele sono assolutamente complete.

----------

## Peach

 *cloc3 wrote:*   

>  *Onip wrote:*   non ti torna lo slot.
> 
>  
> 
> mi spiegheresti, per cortesia, cosa si intende per slot?
> ...

 

come diceva Onip, generalmente la possibilita' di installare diverse versioni dello stesso pacchetto

se usi eix puoi notare che i numeri tra parentesi indicano gli slot, ad esempio i kernel sono sempre slottati, quindi un aggiornamento non rimuove la versione precedente ma semplicemente la affianca.

 :Smile: 

[edit] ops mi ero perso meta' del post di Onip dove effettivamente spiegava quanto da me detto, pardonne moi.

----------

## cloc3

 *Peach wrote:*   

> 
> 
> [edit] ops mi ero perso meta' del post di Onip dove effettivamente spiegava quanto da me detto, pardonne moi.

 

figurati.

cominciavo a capire il trucco mentre facevo la domanda.

fino ad ora, avevo usato gli slot solo per ragioni dirette, tipo avere kde4 e kde3.5 sulla stessa installazione.

il meccanismo delle librerie non lo avevo mai usato fino ad ora. almeno, non consapevolamente.

un'altro caso attuale è openssl. per gestire il passaggio dalla versione 1.0.0a alla precedente 0.9.8o.

esiste il pacchetto in tilde 0.9.8o-r1 con il proprio installer ad hoc:

```

s939 ~ # grep -A3 src_install /usr/portage/dev-libs/openssl/openssl-0.9.8o-r1.ebuild

src_install() {

   dolib.so lib{crypto,ssl}.so.0.9.8 || die

}

```

solo che questi strumenti implicano un uso un po' esperto di portage.

io me ne sono reso conto solo perché sto usando la versione hardmask di portage (2.2_rc67), con il meccanismo delle preserved-libs.

con il portage stabile sarei dovuto aggiustare a posteriori, ricorrendo a revdep-rebuild.

è necessario, inoltre, osservare che, per ottenere una stabilizzazione del sistema, non basta smascherare la versione preserved, ma bisogna anche installarla richiamando espliciemente la versione del pacchetto e senza usare il -1.

```

emerge =openssl-0.9.8o-r1

```

in modo da inserire il pacchetto slotted in /var/lib/portage/world. e questa è un'operazione che richiede una riflessione specifica.

credo che rimanga aperto anche il problema della disinstallazione. fra qualche tempo la librerie obsoleta diventerà inutile, ma dubito che il sistema sarà in grado di avvisarmi per indurmi a disinstallarla.

----------

## Onip

non vedo perchè sia necessario installare una qualsiasi libreria senza -1. Salvo errori dei dev negli ebuild sarà emerge (o paludis o vattelapesca) a risolvere le dipendenze e ad installare le librerie necessarie. Prova a vedere il RDEPEND di chromium-bin con libpng e media-libs/jpeg ad esempio.

----------

## cloc3

 *Onip wrote:*   

> Prova a vedere il RDEPEND di chromium-bin con libpng e media-libs/jpeg ad esempio.

 

giusto.

allora adesso mi è proprio tutto chiaro.

guardando più bene, nel mio sistema si scopre una differenza tra libpng e openssl.

libpng è completamente automatizzata dalla scrittura corretta degli ebuild (vmware-server funziona proprio come chromium-bin).

invece openssl no. ma la versione 1.0.0a è stata smascherata manualmente da me per non so quale motivo (in una singola delle mie installazioni).

ovvio che gli ebuild dei binari non lo sappiano.

in teoria, portage offre gli strumenti per aggiungere qualche ulteriore controllo per risolvere anche questi casi.

ma mi sembra ovvio che gli ebuild ufficiali non possano tenere conto di tutte le complicazioni di ogni singola installazione.

grazie.

 :Smile: 

----------

