# Gestione pulita degli overlay con eix-remote

## topper_harley

Da quando ho scoperto la funzione "update-eix-remote" presente nelle ultime versioni di eix mi si è aperto un mondo.

Per chi non lo sapesse ancora il comando 

```
update-eix-remote update
```

 aggiorna nel database di eix tutti gli overlay conosciuti da layman, compresi quelli che non sono nella lista locale.

Ad esempio: 

```
andrea@caffeine ~ $ eix media-sound/xmms

* media-sound/xmms [1]

     Available versions:  1.2.10-r14 1.2.10-r15 ~1.2.10-r16

     Homepage:            http://www.xmms.org/

     Description:         X MultiMedia System

[1] /usr/portage/local/layman/zugaina

```

Mi dice che il pacchetto xmms (non presente nell'albero di portage) è presente nell'overlay zugaina (che non è presente nel mio sistema).

A questo punto se voglio se voglio installare xmms ho tre possibilità: 

[*] Abilitare con layman l'overlay zugaina, e installare il pacchetto

[*] Abilitare con layman l'overlay zugaina, installare il pacchetto e rimuovere l'overlay

[*] Abilitare con layman l'overlay zugaina, copiare l'ebuild nel mio overlay locale (/usr/local/portage), rimuovere l'overlay con layman e installare il pacchetto.

Ognuna di queste tre soluzioni ha delle controindicazioni: 

- La prima riempie il sistema di overlay e, in presenza di pacchetti instabili nel package.keywords, un update di world potrebbe aggiornare questi pacchetti a versioni indesiderate

- La seconda installa nel sistema pacchetti che non hanno un ebuild corrispondente nel portage tree.

- La terza è piuttosto laboriosa, in quanto spesso è necessario copiare dall'overlay anche gli ebuild di alcune dipendenze. Inoltre, è difficile tenersi aggiornati sull'esistenza di eventuali nuove versioni del pacchetto.

Dopo aver provato eix-remote mi viene in mente una soluzione più pulita, ma francamente non so se è realizzabile:

si tratta di (ad esempio per xmms):

1) capire a quale overlay è legato xmms (in questo caso zugaina)

2) fare il fetch dell'overlay zugaina

3) lanciare un emerge -p xmms

4) verificare quali delle dipendenze provengono dall'overlay stesso

5) copiare gli ebuild di xmms e delle eventuali dipendenze in usr/local/portage

6) eliminare l'overlay zugaina dal sistema

7) emergere xmms

L'ideale sarebbe automatizzare questo processo con uno script, ma non saprei da che parte cominciare.

La seconda parte della mia idea malsana sta nel tenere aggiornati i pacchetti in /usr/local/portage.

Si tratta di verificare quali deggli ebuild in /usr/local/portage siano presenti in world e, su questi pacchetti controllare (tramite eix) l'eventuale presenza di aggiornamenti negli overlay di layman.

Nel caso di possibili aggiornamenti, bisognerebbe trovare il modo di darli in pasto alla procedura di cui sopra.

Chiedo troppo??

----------

## mouser

Guarda ci sto già lavorando.... mi sembra ottima come cosa, ed è una miglioria che si potrebbe inserire nel gechi-overlay.

L'unica cosa che, di primo acchitto, mi sembra un casotto da risolvere è la presenza di differenti versioni degli stessi pacchetti in differenti overlay....

Giusto per darti un esempio:

```
root@golem# eix media-sound/xmms

* media-sound/xmms

     Available versions:  ~1.2.8-r5[2] ~1.2.10-r6[2] ~1.2.10-r8[2] 1.2.10-r14[3] 1.2.10-r15[3] ~1.2.10-r16[3] *20101010[1]

     Homepage:            http://xmms.org

     Description:         X Multimedia System

...

[1] (layman/fluidportage)

[2] (layman/gentoojp)

[3] (layman/zugaina)

```

Oltre al fatto che eix restituisce più risultati (si potrebbe giusto dare per buona la prima entry uscita, ma anche qui non saprei), è possibile vedere che gli ebuild di versioni differenti si trovano su differenti overlay, richiedendo così che lo script determini anche da quale overlay andare a prendere i pacchetti......

Spero di riuscire a tirar fuori qualcosa.... 

mumble mumble 

Ciriciao

mouser  :Wink: 

----------

## mrfree

 *topper_harley wrote:*   

> Mi dice che il pacchetto xmms (non presente nell'albero di portage) è presente nell'overlay zugaina (che non è presente nel mio sistema).

 

Wow! Mi stai dicendo che eix mi permette di ricercare un'ebuild negli overlay che non ho in locale... è proprio quello che cercavo... sei il top dei top, topper!

PS: scusa non ho resistito  :Smile: 

----------

## topper_harley

 *mouser wrote:*   

> Guarda ci sto già lavorando.... mi sembra ottima come cosa, ed è una miglioria che si potrebbe inserire nel gechi-overlay.
> 
> L'unica cosa che, di primo acchitto, mi sembra un casotto da risolvere è la presenza di differenti versioni degli stessi pacchetti in differenti overlay....
> 
> 

 

Intanto mi fa piacere sapere che la mia elucubrazione mentale non è proprio da buttare via. Purtroppo mi spiace non poter essere di aiuto pratico nella realizzazione dell script, viste le mie misere conoscenze in campo informatico.

Quanto al problema dei differenti overlay mi viene in mente un approccio del genere:

la prima volta lo script viene lanciato in modalità "pretend", ovvero mostra solo l'output di eix. A quel punto l'utente inserisce in pakage.keywords la versione che gli interessa e, il nostro script, una volta lanciato nuovamente sceglie l'overlay a cui corrisponde la versione più alta tra quelle smascherate. In caso la stessa versione sia presente in vari overlay credo che si possa scegliere indifferentemente una delle due.

Un secondo problema che mi viene in mente è che anche le dipendenze probabilmente saranno mascherate, quindi è necessario che l'emerge fallisca ogni volta finché l'utente non le smaschera tutte. Altrimenti sarebbe necessaria un integrazione con zorro/forcekeymask, che vedo un po' complicata.

 *mrfree wrote:*   

> Wow! Mi stai dicendo che eix mi permette di ricercare un'ebuild negli overlay che non ho in locale... è proprio quello che cercavo... sei il top dei top, topper!
> 
> PS: scusa non ho resistito 

 

E' necessaria la versione 0.8 o superiore di eix, che attualmente è mascherata ~x86

P.s. le mie ciabatte da coniglietto peloso mi ispirano sempre ottime idee...

----------

## federico

Spacca  :Smile:  Non uso layman, pero' spacca come idea  :Smile: 

----------

## Kernel78

Sarà che tendo a essere ultra-conservativo ed è già difficile che io installi qualcosa di hard-masked ma l'idea degli overlay mi fa rabbrividire  :Confused: 

Se non è in portage si richiede un ebuild ma se i devel non inseriscono o rimuovono qualcosa tendo a fidarmi di loro e ad accettare le loro scelte ...

----------

## mouser

 *Kernel78 wrote:*   

> Sarà che tendo a essere ultra-conservativo ed è già difficile che io installi qualcosa di hard-masked ma l'idea degli overlay mi fa rabbrividire 
> 
> Se non è in portage si richiede un ebuild ma se i devel non inseriscono o rimuovono qualcosa tendo a fidarmi di loro e ad accettare le loro scelte ...

 

Hai ragione, ma la forza di gentoo è proprio la possibilità di scelta.... quindi un'opzione in più non fà male, IMHO  :Cool: 

Ciriciao

mouser  :Wink: 

----------

## Kernel78

 *mouser wrote:*   

> Hai ragione, ma la forza di gentoo è proprio la possibilità di scelta.... quindi un'opzione in più non fà male, IMHO 

 

Il problema non è la scelta ma i problemi che si porta dietro... nonostante i test e le procedure che portano un sw ad essere considerato stabile all'interno di portage capita che ci siano cmq problemi di installazione o funzionamento (come testimoniano i vari post di questo forum), figurarsi l'instabilità potenziale che si raggiunge usando componenti non ufficiali ...

e addirittura figurarsi a quali risultati si potrebbe arrivare mischiando diversi overlay  :Rolling Eyes: 

Se volessi un sistema così instabile installerei winzozz  :Laughing: 

----------

## topper_harley

 *Kernel78 wrote:*   

> Sarà che tendo a essere ultra-conservativo ed è già difficile che io installi qualcosa di hard-masked ma l'idea degli overlay mi fa rabbrividire 
> 
> Se non è in portage si richiede un ebuild ma se i devel non inseriscono o rimuovono qualcosa tendo a fidarmi di loro e ad accettare le loro scelte ...

 

Credo che il bello stia proprio nella possibilità di usare un singolo ebuild proveniente da un overlay senza sporcare il sistema con l'overlay stesso.

Un po' come quando utilizziamo gli ebuild di bugs.gentoo.org, o degli ebuild fatti da noi. Con il vantaggio però, tramite eix-remote, di tenerci aggiornati sull'eventuale presenza negli overlay di nuove versioni.

Visto che gli overlay ci sono, e vengono utilizzati, credo che aumentare la stabilità dei sistemi di chi ne fa uso possa essere positivo.

----------

## mrfree

 *topper_harley wrote:*   

> Credo che il bello stia proprio nella possibilità di usare un singolo ebuild proveniente da un overlay senza sporcare il sistema con l'overlay stesso.

 

Si, una specie di funzione di import che copi l'ebuild e le eventuali dipendenze non in portage nell'overlay locale e che permetta un sync tra overlay remoto e locale sarebbe a mio avviso moooolto utile

----------

## mouser

Step 1

Qualcosina sta uscendo, pian piano

In pratica guardando, per esempio, xmms2

```
# eix -e xmms2

* media-sound/xmms2 [1]

     Available versions:  ~0.1_pre2 ~0.1_pre2-r1 ~0.1_pre2-r2 ~0.2 ~0.2.1 ~0.2.1-r1 ~0.2.2 ~0.2.3 ~0.2.3-r1 ~0.2.3-r2 ~0.2.5 ~0.2.6 ~0.2.7

     Homepage:            http://xmms2.xmms.org

     Description:         X(cross)platform Music Multiplexing System. The new generation of the XMMS player. (0.2DrHouse)

[1] (layman/zugaina)

#
```

il programmillo determina

```
# ./emerge-overlay -o xmms2

[--] Overlay selected for package xmms2 - zugaina

#
```

In situazioni un pò più complesse, invece, come questa:

```
# eix -e xmms

* media-sound/xmms

     Available versions:  ~1.2.8-r5[2] ~1.2.10-r6[2] ~1.2.10-r8[2] 1.2.10-r14[3] 1.2.10-r15[3] ~1.2.10-r16[3] *20101010[1]

     Homepage:            http://xmms.org

     Description:         X Multimedia System

[1] (layman/fluidportage)

[2] (layman/gentoojp)

[3] (layman/zugaina)
```

invece, riesce ad estrarre l'overlay dell'ultima versione stabile

```
# ./emerge-overlay -o xmms 

[--] Overlay selected for package xmms - zugaina
```

sto ora implementando la possibilità di inserire un file che permette di specificare la arch (tipo il keywords)

Ciriciao

mouser  :Wink: 

----------

## Kernel78

A volte mi rendo conto che ho la mentalità conservativa da vecchio dinosauro ma personalmente sono contrario a semplificare le cose, rendendole alla portata di tutti si incappa inevitabilmente nel problema che tra i "tutti" si nascondono molti che per un motivo o per l'altro agiscono prima di essersi documentati (mi ricordo la mia prima installazione gentoo con un bellissimo emerge kde su un p3 500  :Evil or Very Mad:  ).

Rendere più user-friendly procedure che mettono a rischio la stabilità della macchina si finisce inevitabilmente per avere più macchine instabili ... proprio come con winzozz ... M$ ha voluto instillare nella gente l'idea che il pc sia per tutti e che sia facile da usare mentre in realtà serve tempo e studio per riuscire ad usarlo bene.

----------

## Kernel78

 *mouser wrote:*   

> In situazioni un pò più complesse, invece, come questa:
> 
> ```
> # eix -e xmms
> 
> ...

 

Secondo me c'è un errore di fondo ...

mettiamo che un overlay abbia come ultima versione stabile la 1.2.3-r4 mentre un altro abbia la 1.2.3-r5

Presumo che il tuo script scelga la 1.2.3-r5 basandosi sul presupposto che tutti gli overlay usino la stessa numerazione ovvero che una r5 sia sempre meglio di una r4 ma a quanto ne so io gli overlay sono indipendenti tra di loro quindi la versione r4 di un overlay potrebbe essere più recente, aggiornata e funzionante di r5 e non c'è modo di scoprirlo basandosi sul numero di versione.

----------

## Luca89

Non tutti gli overlay fanno casini nel sistema, per esempio l'overlay sunrise contiene ebuild che non fanno parte del portage ufficile, quindi tu smascheri quelli che vuoi e li installi, gli altri non vengono visti da portage perchè sono mascherati. 

Questa idea di copiare l'ebuild sull'overlay locale mi sembra parecchio macchinosa, che problemi ci sono ad aggiungere tutto l'overlay desidarato tramite layman? Poi basta smascherare solo il pacchetto che si vuole usare e via, non capisco quali altri problemi ci dovrebbero essere. Negli overlay è difficile che ci siano ebuild marcati stabili, quindi smascherando solo quello che serve il sistema non si "sporca".

Naturalmente se poi l'utente mischia overlay a destra e a sinistra senza un po di buon senso, quello è un altro discorso.

----------

## mouser

 *Kernel78 wrote:*   

> Presumo che il tuo script scelga la 1.2.3-r5 basandosi sul presupposto che tutti gli overlay usino la stessa numerazione ovvero che una r5 sia sempre meglio di una r4...

 

Ero convinto che la numerazione della versione di un pacchetto fosse data dal mantenitore del pacchetto stesso, non dall'ebuild che lo installa...... in pratica mi stai dicendo che, per esempio, la versione 1.5_rc1-r11 di firefox nell'overlay zugaina potrebbe essere più aggiornata della 2.0.0.1 presente nell'overlay mozilla?

hmmm

Ciriciao

mouser  :Wink: 

----------

## topper_harley

 *Luca89 wrote:*   

> Non tutti gli overlay fanno casini nel sistema, per esempio l'overlay sunrise contiene ebuild che non fanno parte del portage ufficile, quindi tu smascheri quelli che vuoi e li installi, gli altri non vengono visti da portage perchè sono mascherati. 
> 
> Questa idea di copiare l'ebuild sull'overlay locale mi sembra parecchio macchinosa, che problemi ci sono ad aggiungere tutto l'overlay desidarato tramite layman? Poi basta smascherare solo il pacchetto che si vuole usare e via, non capisco quali altri problemi ci dovrebbero essere. Negli overlay è difficile che ci siano ebuild marcati stabili, quindi smascherando solo quello che serve il sistema non si "sporca".
> 
> Naturalmente se poi l'utente mischia overlay a destra e a sinistra senza un po di buon senso, quello è un altro discorso.

 

Poniamo il caso che io voglia installare l'ultima versione di media-sound/listen presente nell'overlay gnome-experimantal in quanto ha delle features che per me sono di vitale importanza.

Se io abilito questo overlay rischio, nel caso nel mio package keywords ci sia la versione ~x86 di evolution (che reputo piuttostoo stabile), con un emerge -uD world di portare il mio sistema ad aggiornamenti assurdi...

----------

## mouser

Inserita gestione per il file /etc/portage/package.overlay.keywords.

E' possibile inserire le voci direttamente in ~x86 o -* per selezionare i pacchetti relativi (ed il programma riesce ad estrarre i relativi overlay)

Ora inizio ad occuparmi dell'installazione (anche se, essendo al lavoro e non funzionando layman, non potrò postare i risultati dei test prima di stasera!!!

Ciriciao

mouser  :Wink: 

----------

## Kernel78

 *mouser wrote:*   

> Ero convinto che la numerazione della versione di un pacchetto fosse data dal mantenitore del pacchetto stesso, non dall'ebuild che lo installa...... in pratica mi stai dicendo che, per esempio, la versione 1.5_rc1-r11 di firefox nell'overlay zugaina potrebbe essere più aggiornata della 2.0.0.1 presente nell'overlay mozilla?

 

O mi sono spiegato male o non mi hai capito, in ogni caso abbiamo fatto un po' di confusione, provo a rispiegarmi ...

La versione di un ebuild è composta di due versioni diverse, quella del pacchetto e quella opzionale dell'ebuild stesso.

es. firefox 2.0.0.1 avrà un primo ebuild con versione 2.0.0.1 ma se in seguito si palesasse la necessità di modificare l'ebuild per garantire il corretto funzionamento dell'applicazione il manutentore dell'ebuild aggiornerebbe la versione a 2.0.0.1-r1 e via dicendo ...

Va da se che overlay diversi avranno manutentori diversi per ebuild diversi relativi agli stessi pacchetti, o meglio ...

es. xmms versione 1.2.3 (ipotetica) gestita in due overlay (chiamiamoli A e B) avrà in entrambi un ebuild versione 1.2.3 (che in quanto gestiti da due persone diverse saranno probabilmente diversi), durante alcuni test successivi al rilascio si rileva la necessità di una patch quindi gli ebuild devono essere modificati ma i due manutentori seguono strade diverse e il manutentore dell'overlay A, più esperto del suo corrispettivo di B, riesce a risolvere ogni problema nella versione 1.2.3-r1 del suo ebuild mentre su B si deve attendere la versione 1.2.3-r4 per vedere risolto ogni problema.

Stessa versione di sw, diversa versione di ebuild e impossibilità di ricavare informazioni su quale sia il migliore basandosi sulla versione ...

----------

## Ic3M4n

Kernel78: personalmente utilizzo alcuni programmi presi da overlay, essenzialmente sono programmi che soffrono di qualche problema di giovantu, però fanno il loro sporco lavoro ed a volte averli direttamente da cvs rispetto alle regolari versioni può tornare utile perchè di giorno in giorno vengono aggiunte nuove features che rendono il lavoro meno pesante o migliorano la compatibilità operativa con del codice esistente.

un'esempio: geany è un IDE in gtk2 secondo me molto ben fatto e rispetto a colossi come eclipse lavora molto meglio, soprattutto per la gestione di codice in C / C++. ha già ora delle features in più rispetto ad altri programmi tipo anjuta che non ho mai sopportato.

sotto determinati punti di vista lo preferisco anche a emacs. però o me lo becco da overlay o non lo posso utilizzare. quindi ben vengano gli overlay se mi possono permettere di utilizzare software che mi torna utile. logicamente uno non può pensare di utilizzare un sistema costruito quasi esclusivamente sugli overlay. ma per qualche applicazione non determinante per la stabilità del sistema non ci vedo niente di male.

EDIT: In ogni caso concordo sul fatto che uno debba sapere ciò che sta facendo. proprio adesso mi è saltata fuori una versione  1.2.4-r90 di cairo marcata non si sa come stabile nell'overlay di sabayon. personalmente preferirei che tutti gli ebuild fossero inseriti in testing e quelli da cvs in -*.

----------

## mouser

 *Kernel78 wrote:*   

> O mi sono spiegato male o non mi hai capito, in ogni caso abbiamo fatto un po' di confusione, provo a rispiegarmi ...

 

Ok, non avevo proprio capito.... adesso è più chiaro.

In effetti questo è un bel problemino, ed è difficilmente aggirabile con un programma.... insomma, potrebbe anche parsare i changelog, ma da qui ad interpretarli  :Rolling Eyes: 

Mi viene in mente un modo carino per affrontare il problema (o aggirarlo, a seconda di come si preferisce).

Di default il programma si comporta come portage, quindi se sono in stable, in ~x86 o in -* (specificandolo in /etc/portage/package.overlay.keywords), ed avvio l'installazione vado a selezionare l'ultima release tra quelle disponibili dalla keywords.

Poi, se uno vede che la particolare release è più aggiornata (anche se con rel-number più piccolo), mette direttamente il pacchetto con la versione (sempre nel file di cui sopra) e il programma andrà a forzare l'installazione di quella versione.

Come vi sembra come soluzione?

Ciriciao

mouser  :Wink: 

----------

## topper_harley

 *mouser wrote:*   

>  *Kernel78 wrote:*   O mi sono spiegato male o non mi hai capito, in ogni caso abbiamo fatto un po' di confusione, provo a rispiegarmi ... 
> 
> Ok, non avevo proprio capito.... adesso è più chiaro.
> 
> In effetti questo è un bel problemino, ed è difficilmente aggirabile con un programma.... insomma, potrebbe anche parsare i changelog, ma da qui ad interpretarli 
> ...

 

Io la trovo ottima, anche perché ha sì ragione Kernel78 nel dire che non è detto che una -r3 di un determinato overlay sia superiore ad una -r1 di un altro overlay, ma in realta non possiamo nemmeno saperlo utilizzando layman alla vecchia maniera.

Mi spiego meglio: se io abilito con layman 2 overlay che contengono lo stesso pacchetto, e questo pacchetto è marcato ~x86 nel mio package.keywords, lo stesso portage si fida di quello che legge e mi installa quello con la versione apparentemente più alta.

----------

## Luca89

 *topper_harley wrote:*   

> Poniamo il caso che io voglia installare l'ultima versione di media-sound/listen presente nell'overlay gnome-experimantal in quanto ha delle features che per me sono di vitale importanza.
> 
> Se io abilito questo overlay rischio, nel caso nel mio package keywords ci sia la versione ~x86 di evolution (che reputo piuttostoo stabile), con un emerge -uD world di portare il mio sistema ad aggiornamenti assurdi...

 

Previeni gli aggiornamenti assurdi utilizzando i vari "=mail-client/evolution-2.8.0.1" et similia.

----------

## Ic3M4n

 *Luca89 wrote:*   

>  *topper_harley wrote:*   Poniamo il caso che io voglia installare l'ultima versione di media-sound/listen presente nell'overlay gnome-experimantal in quanto ha delle features che per me sono di vitale importanza.
> 
> Se io abilito questo overlay rischio, nel caso nel mio package keywords ci sia la versione ~x86 di evolution (che reputo piuttostoo stabile), con un emerge -uD world di portare il mio sistema ad aggiornamenti assurdi... 
> 
> Previeni gli aggiornamenti assurdi utilizzando i vari "=mail-client/evolution-2.8.0.1" et similia.

 

si, però il caso che ho riportato sopra di un pacchetto inserito come stabile potrebbe comunque portare grossi problemi.

----------

## topper_harley

 *Luca89 wrote:*   

>  *topper_harley wrote:*   Poniamo il caso che io voglia installare l'ultima versione di media-sound/listen presente nell'overlay gnome-experimantal in quanto ha delle features che per me sono di vitale importanza.
> 
> Se io abilito questo overlay rischio, nel caso nel mio package keywords ci sia la versione ~x86 di evolution (che reputo piuttostoo stabile), con un emerge -uD world di portare il mio sistema ad aggiornamenti assurdi... 
> 
> Previeni gli aggiornamenti assurdi utilizzando i vari "=mail-client/evolution-2.8.0.1" et similia.

 

E' quello che faccio attualmente... 

Ma se volessi avere sempre l'ultima versione instabile in portage, senza per forza avere quella bleeding edge dell'overlay?

Oltre a questo tengo anche in considerazione che avere nel repo locale solo listen e le sue dipendenze rende il lavoro di portage molto più veloce che avere tutto il tree dell'overlay "gnome-experimental".

----------

## unz

 *topper_harley wrote:*   

> 
> 
> Oltre a questo tengo anche in considerazione che avere nel repo locale solo listen e le sue dipendenze rende il lavoro di portage molto più veloce che avere tutto il tree dell'overlay "gnome-experimental".

 

E' l'unico motivo per cui sto seguendo questo topic. 

Il dramma degli overlay è lo "spam" di ebuild non voluti. 

A volte i develpers ci infilano robe senza alcuna attinenza con la specificità dell'overlay.

C'è il modo di segare singole categorie [ex: media-video] ... ma è una rottura e soprattutto per categorie molto popolate [ex: *-lib] sarebbe impossibile filtrare l'utile dall'inutile.

----------

## mouser

Ok, direi che la funzione che va ad estrarre l'overlay è praticamente pronta. Attualmente è possibile:

1) Senza opzioni e/o file, determinare l'overlay nel quale è presente l'ultima release "stable" del pacchetto

2) Inserendo "<categoria>/<software> ~x86" in /etc/portage/package.overlay.keywords estrarre l'overlay contenente l'ultima release "tilde" del pacchetto

3) Inserendo "<categoria>/<software> -*" in /etc/portage/package.overlay.keywords estrarre l'overlay contenente l'ultima versione "-*" del pacchetto

4) Inserendo "<categoria>/<software> <versione>" in /etc/portage/package.overlay.keywords estrarre l'overlay contenente la versione desiderata del pacchetto.

Ecco qui alcuni esempi:

```
# eix -e xmms

* media-sound/xmms

     Available versions:  ~1.2.8-r5[2] ~1.2.10-r6[2] ~1.2.10-r8[2] 1.2.10-r14[3] 1.2.10-r15[3] ~1.2.10-r16[3] *20101010[1]

     Homepage:            http://xmms.org

     Description:         X Multimedia System

[1] (layman/fluidportage)

[2] (layman/gentoojp)

[3] (layman/zugaina)
```

Quindi, lo scrippettonzo restituisce:

```
# cat /etc/portage/package.overlay.keywords

# ./emerge-overlay -o xmms

[--] Overlay selected for package xmms - zugaina

#
```

```
# echo "media-sound/xmms ~x86" > /etc/portage/package.overlay.keywords

# cat /etc/portage/package.overlay.keywords

media-sound/xmms ~x86

# ./emerge-overlay -o xmms

[--] Overlay selected for package xmms - zugaina

#
```

```
# echo "media-sound/xmms -*" > /etc/portage/package.overlay.keywords

# cat /etc/portage/package.overlay.keywords

media-sound/xmms -*

# ./emerge-overlay -o xmms

[--] Overlay selected for package xmms - fluidportage

#
```

```
# echo "media-sound/xmms 1.2.10-r8" > /etc/portage/package.overlay.keywords

# cat /etc/portage/package.overlay.keywords

media-sound/xmms 1.2.10-r8

# ./emerge-overlay -o xmms

[--] Overlay selected for package xmms - gentoojp

#
```

E fin qui mi sembra tutto ok.... Altre idee/migliorie da poter fare????

Ciriciao

mouser  :Wink: 

ps:

Ah, una piccola chicca....

```
# eix -e portage

[I] sys-apps/portage

     Available versions:  2.0.51.22-r3 ~2.1_pre4-r1[1] 2.1-r2 2.1.1-r1 2.1.1-r2 ~2.1.2_rc3 ~2.1.2_rc4 ~2.1.2_rc4-r1

     Installed versions:  2.1.1-r2(23:20:48 12/18/06)(-build -doc -elibc_FreeBSD elibc_glibc -elibc_uclibc -linguas_pl -selinux -userland_Darwin userland_GNU)

     Homepage:            http://www.gentoo.org/proj/en/portage/index.xml

     Description:         The Portage Package Management System. The primary package management and distribution system for Gentoo.

[1] (layman/ebuild-exchange)

# ./emerge-overlay -o portage

[--] Package present only in current portage, not into any overlay.

[--] Sorry, today you can't break your gentoo :D

#
```

 :Cool:   :Cool:   :Cool: 

----------

## Bionicle

Mi sono ritrovato con lo stesso problema, con il vecchio portage la versione 2.0.x potevo abilitare l'overlay nel make.conf installare il programma e poi togliere la riga dal .conf, portage mi segnalava solo che non trovava il pacchetto ma potevo fare i miei aggiornamenti.

Al momento ho installato beryl-svn la versione 9999 usando il repository xeffect. Con il nuovo portage 2.1 non si può più fare il giochetto citato sopra perché mi blocca l'emerge. Anche se copio gli ebuild in locale non me li riconosce e mi da errore.

Con questo programma sarebbe fattibile? se si dove lo posso trovare?

Io ho installato beryl la versione 9999 se do un emerge -puDN world e ho i file copiati localmente nel /usr/local/portage ecco cosa esce:

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

Calculating dependencies -

!!! All ebuilds that could satisfy "=x11-plugins/beryl-dbus-0.1.4" have been masked.

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

- x11-plugins/beryl-dbus-0.1.4 (masked by: ~x86 keyword)

For more information, see MASKED PACKAGES section in the emerge man page or

refer to the Gentoo Handbook.

(dependency required by "x11-plugins/beryl-plugins-0.1.4" [ebuild])

```

per toglire l'errore devo per forza abilitare l'overlay xeffect e questo comporta anche l'aggiornamento di altri pacchetti che non voglio.

Grazie

----------

## Onip

beh, basta che smascheri quell'ebuild...

----------

## mouser

Sto ultimando lo scrippettonzo..... ho qualche problema con il debugging, e procedo con lentezza poichè al lavoro non riesci ad utilizzare layman.... Spero di riuscire a sputare fuori una release alpha a breve  :Very Happy: 

Ciriciao

mouser  :Wink: 

----------

## mrfree

 *mouser wrote:*   

> Spero di riuscire a sputare fuori una release alpha a breve

  Ottimo   :Cool: 

----------

## mouser

Come promesso il buon mouser.....

emerge-overlay

----------

## Apetrini

 *mrfree wrote:*   

> 
> 
> Wow! Mi stai dicendo che eix mi permette di ricercare un'ebuild negli overlay che non ho in locale... ï¿½ proprio quello che cercavo... sei il top dei top, topper!
> 
> PS: scusa non ho resistito 

 

Quoto in pieno.... si sentiva l'esigenza di questa cosa.

----------

