# Mascherare un pacchetto di un overlay

## riatiopene

ciao ragazzi,

è possibile mascherare un pacchetto di un overlay e mantenere quello del portage?

Mi spiego meglio: ho un overlay che ha un pacchetto con una versione superiore a quella del portage. Se do emerge -avuDN world, giustamente il pacchetto viene aggiornato alla versione dell'overlay. Ecco io vorrei evitare che accada questo e accettare aggiornamenti solo dal portage (più fidato). È possibile? Grazie

----------

## djinnZ

 :Twisted Evil: 

 :Twisted Evil: 

----------

## Peach

 *djinnZ wrote:*   

> 
> 
> 

 

[OT] che tecnica!!! complimenti djinnz!!  :Very Happy:  [/OT]

----------

## cloc3

ragazzi, cerchiamo di essere costruttivi.

riatiopene ha scritto solo 5 post su questo forum...

http://www.gentoo.org/doc/it/handbook/handbook-x86.xml?part=3&chap=3

https://forums.gentoo.org/viewtopic-t-713920-highlight-.html

----------

## djinnZ

Beh tanto vale che inizi subito a fare il callo con le mie bastardate, o discutibili tentativi di fare dello spirito, che dir si voglia...   :Cool: 

In fin dei conti è un novellino, deve temprare lo spirito e la capacità di smoccolo prima di raggiungere il nirvana... sempre che sia possibile l'impresa... :Twisted Evil: 

@ratiopene: ovviamente si cerca di sdrammatizzare. Tanto per curiosità il tuo nick da dove è spuntato fuori? Esiste un thread apposito per presentarsi...

@cloc3: Mi spieghi cosa c'entra la discussione sulle eapi 2?

In ogni caso anche se lo script di mouser è datato funziona ancora e giusto per amore di puntualità è buona norma evitare di caricare per intero gli overlay se non si sa esattamente quel che si sta facendo (taluni sconvolgono le virtual e le dipendenze mandando a "donnine allegre" la tua bella gentoo, fai molta attenzione).

----------

## cloc3

 *djinnZ wrote:*   

> 
> 
> @cloc3: Mi spieghi cosa c'entra la discussione sulle eapi 2?
> 
> 

 

non era una discussione sulle eapi, ma il problema di un utente che non riusciva a smascherare un pacchetto.

alla fine c'è una divagazione su autounmask.

----------

## djinnZ

 *riatiopene wrote:*   

> è possibile mascherare un pacchetto di un overlay e mantenere quello del portage?

 ehm... veramente è il contrario quel che si chiedeva.

----------

## riatiopene

 *cloc3 wrote:*   

> ragazzi, cerchiamo di essere costruttivi.
> 
> riatiopene ha scritto solo 5 post su questo forum...
> 
> http://www.gentoo.org/doc/it/handbook/handbook-x86.xml?part=3&chap=3
> ...

 

ho guardato quei link ma non ho trovato la risposta che cercavo. A mascherare e smasherare son capace, però io volevo mascherare solo i pacchetti di un overlay e non quelli del portage

----------

## djinnZ

Se lo script di mouser (in relatà sotto gli emoticons c'è un link solo che non viene evidenziato) non ti va bene non hai altre soluzioni con emerge.

Mi pare che paludis dovesse implementare qualcosa del genere.

Altrimenti potresti provare ad usare il portage come overlay ed un overlay locale minimo come portage base. Soluzione un tantino perversa ma efficace a breve termine.

Questo per dare precedenza al portage sui pacchetti in overlay. Ma in ogni caso ti becchi la più alta versione stabile disponibile.

----------

## cloc3

 *riatiopene wrote:*   

> Se do emerge -avuDN world, giustamente il pacchetto viene aggiornato alla versione dell'overlay. 

 

perché? se la versione superiore è mascherata, non dovrebbe accadere.

in /etc/portage è possibile utilizzare anche le espressioni =, >= e (credo) <=, come previsto in man portage.

si tratta solo si sbattersi un po' per creare la configurazione desiderata.

sempre che abbia finalmente capito la domanda, perché oggi non è che ci azzecchi un gran che   :Embarassed:  .

----------

## djinnZ

A parte il fatto che tra te e peach mi avete guastato la bastardata (ma pagherete il fio dei vostri misfatti prima o poi  :Laughing:  ) quel che mi pare di aver capito è che ratiopene vuole evitare che un certo pacchetto sia installato usando gli ebuild dell'overlay ma solo con quelli del portage ufficiale.

Quindi o metti il portage stesso come overlay in modo che abbia precedenza (non mi ricordo se vanno in ordine inverso o meno, tra l'altro non mi pare sia una cosa documentata ed è "un tantinello perversa") ed usi package.mask per evitare che le versioni superiori a quella in portage siano installate oppure non usi (aggiungi a make.conf) l'intero overlay ma solo i pacchetti che ti servono mettendoli nell'overlay locale.

Paludis mi pare che possa fare un mascheramenbto per overlay emerge no.

@ratiopene: ora mi pare sia il caso di svelare l'arcano e farci capire cosa intendevi, oltre a presentarti. Siamo curiosi.

@cloc3: pare che sia giunto il momento di portare la sfera di cristallo in assistenza, la tua ha smesso proprio di funzionare...  :Laughing: 

----------

## cloc3

 *riatiopene wrote:*   

> ho un overlay che ha un pacchetto con una versione superiore a quella del portage.

 

continuo a non capire.

non mi pare che, in questo caso, si discuta tra pacchetti con versione uguale collocati in overlay differenti (cosa intrinsecamente scorretta, d'altra parte. gli overlay vanno costruti con garbo, utilizzando numeri di versione esotici proprio a questo scopo).

se due overlay possiedono pacchetti con numeri di versione diversa, la selezione deve avvenire secondo l'ordine di versione, che è precedente a quello di overlay.

----------

## Kind_of_blue

io sono perplesso

in teoria l'ultimo pacchetto stabile è sempre quello del portage tree, a meno che non sia stata smascherata una versione presente in un overlay no?

se portage per forza vuole aggiornare una versione a quella presente in un overlay, o in package.unmask e in package.keywords oppure solo in package.keywords ci dovrebbe essere una riga indesiderata do rimuovere

sbaglio di molto?

----------

## lucapost

[OT]Io adoro i browser testuali! è impossibile nasconderli un link! ah ah ah [/OT]

----------

## cloc3

 *lucapost wrote:*   

> [OT]Io adoro i browser testuali! [/OT]

 

sfido io. con l'avatar isterico che ti sei scelto, non puoi fare altro che rifugiarti in un browser testuale.

----------

## djinnZ

 *Kind_of_blue wrote:*   

> a meno che non sia stata smascherata

 e chi ti dice che nell'overlay sia stata mascherata?

(per comodità nel mio overlay locale non maschero mica i pacchetti, li metto come stabili. Lo so che non è molto rigoroso ma sono pigro e me ne vanto.)

In ogni caso finchè ratiopene non si esprime non potremo saperlo.

Diversa è la questione che in ogni caso i pacchetti disponibili da overlay hanno la precedenza su quelli da portage.

@lucapost: mi hai riportato alla mente le infinite discussioni con un paio di debianisti (noto "fattone" titolare di portale su linux e noto incubo di tutti i f****** niubbi debian italiani il secondo, indovinate chi sono?) perchè si doveva avere la libertà di poter usare un client testuale su terminale seriale 7+1 senza problemi per leggere le ML...  :Twisted Evil: 

----------

## cloc3

 *djinnZ wrote:*   

> 
> 
> Diversa è la questione che in ogni caso i pacchetti disponibili da overlay hanno la precedenza su quelli da portage.
> 
> 

 

allora.

mi copio l'ebuild di app-text/antixls-0.2b da /usr/portage al layman gechi. con tutta la sua cartella.

modifico la linea del download per evitare errori di fetch e rinomino antixls-0.2b in antixls-0.1b. adesso:

```

s939 antixls # pwd

/usr/portage/local/layman/gechi/app-text/antixls

s939 antixls # ebuild antixls-0.1b.ebuild digest

>>> Creating Manifest for /usr/portage/local/layman/gechi/app-text/antixls

  digest.assumed                 1

   antixls-0.1b::antixls-0.2b.perl

s939 antixls # emerge -pv antixls

WARNING: repository at /usr/local/portage is missing a repo_name entry

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

Calculating dependencies... done!

[ebuild   R   ] app-text/antixls-0.2b  4 kB

Total: 1 package (1 reinstall), Size of downloads: 4 kB

```

controprova:

```

s939 antixls # mv antixls-0.1b.ebuild antixls-0.3b.ebuild 

s939 antixls # ebuild antixls-0.3b.ebuild digest

>>> Creating Manifest for /usr/portage/local/layman/gechi/app-text/antixls

  digest.assumed                 1

   antixls-0.3b::antixls-0.2b.perl

s939 antixls # emerge -pv antixls

WARNING: repository at /usr/local/portage is missing a repo_name entry

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

Calculating dependencies... done!

[ebuild     U ] app-text/antixls-0.3b [0.2b] 4 kB [0=>1]

Total: 1 package (1 upgrade), Size of downloads: 4 kB

Portage tree and overlays:

 [0] /usr/portage

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

```

mi sembra chiaro che la precedenza nella selezione è sul numero di versione e non sull'ordine dell'overlay.

----------

## lucapost

Con portage, le rare volte che per necessità ( rimuovere una dipendenza...  :Rolling Eyes:   ) ho messo le mani su un ebuild, l'ho sempre copiato nell'overlay locale e rinominato aggiungendoci -r1, -r2, ecc. mai avuto alcun problema.

Già da diverso tempo, se non sbaglio, paludis ha la possibilità di mascherare o meno l'ebuild di un'overlay, e l'albero principale per paludis è un'overlay come tutti glia altri.

Almeno era così qualche tempo fa, ora non saprei se è ancora così...

@cloc3, il tuo avatar è da femmine!   :Laughing: 

----------

## djinnZ

 *cloc3 wrote:*   

> mi sembra chiaro che la precedenza nella selezione è sul numero di versione e non sull'ordine dell'overlay.

 No, la precedenza è per numero di versione e poi per per ordine dell'overlay.

Se hai due ebuild con la stessa versione, uno in portage ed uno in overlay viene installato quello in overlay, se hai due ebuild di diverse versioni viene installato quello con la versione più alta, independentemente da dove sia.

Per il primo problema l'unica soluzione, con emerge, è mettere il portage stesso come overlay; per il secondo usi package.mask.

Il problema è che non puoi dire a portage maschera il pacchetto per la versione >=qualcosa in overlay ma se in portage nel frattempo arriva una versione pari o superiore stabile usala.

Ovvero quel che credo sia il problema di ratiopene, cui non c'è una vera e propria soluzione.

----------

