# Multilple versions in the same slot

## Luc484

Dopo anni che uso Gentoo ancora non ho capito questa cosa: che si fa quando portage non può emergere pacchetti perché c'è un conflitto di versione? Ad esempio:

```
!!! Multiple versions within a single package slot have been pulled

!!! into the dependency graph, resulting in a slot conflict:

sys-kernel/linux-headers:0

  ('ebuild', '/', 'sys-kernel/linux-headers-2.6.23-r3', 'merge') pulled in by

    ('ebuild', '/', 'net-dialup/rp-pppoe-3.10', 'merge')

    @world

  ('installed', '/', 'sys-kernel/linux-headers-2.6.24', 'nomerge') pulled in by

    ('installed', '/', 'sys-apps/hal-0.5.11-r1', 'nomerge')

    @world
```

voglio dire, ho capito che non si può completare il processo per il semplice fatto che o non si soddisfa una dipendenza, o non si soddisfa l'altra, o almeno credo che significhi questo, ma che si fa? Mi succede spessissimo ormai, ed in genere sono problemi che si risolvono pochi giorni dopo con un nuovo sync. Questo problema specifico ho visto che è riportato in tra i bugs, quindi suppongo lo sistemeranno, ma sembrerebbe che fosse stato messo così perché non era ancora testato il funzionamento di rp-pppoe con altri linux-headers. Nel caso in cui venisse fuori che non è compatibile... che si dovrebbe fare? Voglio dire... la cosa mi blocca tutto ovviamente. In linea di principio come si procede?

Grazie mille per qualsiasi chiarimento!

----------

## riverdragon

Queste cose succedono quando hai il sistema stabile con diverse righe in package.keywords (anche io sono di questi).

In questo caso vuoi installare una versione recentissima di hal che vuole degli header recenti, e una versione di rp-pppoe che ha dipendenze opposte; visto che non puoi aggiornare rp-pppoe io tirerei indietro hal.

Ho controllato tra i miei ebuild (aggiornati oggi), e hal-0.5.11-r1 chiede gli headers 2.6.19, non i 2.6.24! Come mai da te invece è diverso?

----------

## Luc484

Per la verità ho il sistema completamente ~x86.

----------

## riverdragon

Chi è causa del suo mal pianga se stesso (cit)  :Laughing: 

Tramite package.mask porta hal ad una versione precedente e guarda se risolve.

----------

## Luc484

Io ho sempre pensato che il tutto dovesse essere consistente, quindi forse mi sbaglio. Può non esserci la possibilità di avere un sistema testing o unstable. Cioè, la cosa non è pensata per funzionare autonomamente e non si garantisce che queste cose non succedano, ho capito bene? Altrimenti questo sarebbe semplicemente un bug. Il fatto di avere un sistema completamente testing non garantisce che questi conflitti non ci siano, giusto? Io ero passato a testing proprio per evitare di dover continuamente gestire queste situazioni con un sistema che aveva qualche pacchetto testing ed altri stable, quindi mi sa che ho fatto male.

----------

## ckx3009

secondo me hai fatto bene...quelli sono i piccoli problemi che possono succederti con un world ~x86 ma fondamentalmente sono sciocchezze...maschera uno dei 2 pacchetti  come diceva riverdragon e dovresti facilmente risolvere tutto...al max avrai un sistema totalmente ~x86 con un pacchetto stabile  :Very Happy: 

----------

## Luc484

La questione non è così semplice: spesso mi trovo errori in compilazione ed il semplice sistema di mascherare il pacchetto non funzionante ho il piccolo effetto collaterale di richiedere il mascheramento di tutta una serie di pacchetti a catena. A voi non capita mai tutto ciò? E' alquanto scomodo!

----------

## djinnZ

No non capita a noialtri perchè non abbiamo tutto il sistema ~x86. Poichè mi pare che non lo dico solo io ma quasi tutti che ACCEPT_KEYWORDS="~x86" serve solo per il testing delle dipendenze e su gentoo, in quanto distribuzione non binaria, non è necessario per usare qualche pacchetto ancora instabile ma necessario.

Se vuoi un consiglio reinstalla da capo usando la versione stabile (la conversione è possibile ma non è facile e ci metteresti lo stesso tempo di fatto).

Quotando in standing ovation riverdragon, mi spiace se queste parole possono risultare sprezzanti ma è solo la realtà dei fatti.

----------

## Luc484

Questo è un bel problema allora... peccato, ci speravo che questa potesse essere una configurazione più comoda. Il fatto è che non è per nulla comodo (o almeno non lo era per me) smascherando solo i pacchetti di interesse, mantenendo però una configurazione sostanzialmente x86. Avevo questo sistema da 4 o 5 anni, ed a forza di smascherare pacchetti dipendenze di dipendenze di dipendenze di ... di pacchetti che volevo in testing, mi sono ritrovato con un package.keywords enorme, e che cresceva ad ogni upgrade del sistema. Però se dite che nemmeno un sistema ~x86 è comodo, a questo punto quasi quasi torno indietro. Tutto sommato forse tra i due mali però, questo potrebbe anche essere il minore. Eventualmente rimarrebbe sempre la cara vecchia stable completa.

----------

## djinnZ

tanto per curiosità quanti sono i pacchetti installati e quante dovrebbero essere le righe di package.keywords?

----------

## Luc484

Oddio, il numero di pacchetti installati non saprei dove trovarlo, mi pare che nel file world non siano esplicitati tutti no? Comunque il numero di linee in package.keywrods è 1114, contando però che ci sono tutti i pacchetti di KDE4 che ho messo solo perché vorrei vedere come va lo sviluppo ogni tanto e qualche spazio e commenti: stima approssimativa boh, diciamo 700 righe. Il problema non è tanto la dimensione, ma il fatto che di continuo mi tocca aggiungerci dentro pacchetti perché dipendenze varie di pacchetti che mi servono testing. In qualche anno è diventato enorme.

EDIT: Per la verità comunque pare che non sia l'unico: https://forums.gentoo.org/viewtopic-t-483373-start-0-postdays-0-postorder-asc-highlight-.html . Vedo che consigliano di passare a ~arch quando si va sulle centinaia. Mah... sono molto confuso al momento. Dai pochissimi pacchetti iniziali sono arrivato qui... bella voglia. Forse sono anche più di 700 senza KDE4.

----------

