View previous topic :: View next topic |
Author |
Message |
topper_harley Guru
Joined: 05 Apr 2006 Posts: 363 Location: Treviso / Udine (Italy)
|
Posted: Thu Dec 21, 2006 3:25 pm Post subject: Gestione pulita degli overlay con eix-remote |
|
|
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 Code: | 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: Code: | 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?? _________________ http://topperh.ath.cx
Jabber: topper_harley@jabber.org
ICQ: 224179391
MSN: Topper_Harley80@gmail.com
Last FM |
|
Back to top |
|
|
mouser Veteran
Joined: 10 Aug 2004 Posts: 1419 Location: Milano
|
Posted: Thu Dec 21, 2006 4:11 pm Post subject: |
|
|
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:
Code: | 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 |
|
Back to top |
|
|
mrfree Veteran
Joined: 15 Mar 2003 Posts: 1303 Location: Europe.Italy.Sulmona
|
Posted: Thu Dec 21, 2006 4:15 pm Post subject: Re: Gestione pulita degli overlay con eix-remote |
|
|
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 _________________ Please EU, pimp my country!
ICE: /etc/init.d/iptables panic |
|
Back to top |
|
|
topper_harley Guru
Joined: 05 Apr 2006 Posts: 363 Location: Treviso / Udine (Italy)
|
Posted: Thu Dec 21, 2006 4:43 pm Post subject: |
|
|
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... _________________ http://topperh.ath.cx
Jabber: topper_harley@jabber.org
ICQ: 224179391
MSN: Topper_Harley80@gmail.com
Last FM |
|
Back to top |
|
|
federico Advocate
Joined: 18 Feb 2003 Posts: 3272 Location: Italy, Milano
|
|
Back to top |
|
|
Kernel78 Moderator
Joined: 24 Jun 2005 Posts: 3654
|
Posted: Fri Dec 22, 2006 8:28 am Post subject: |
|
|
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 ... _________________ Le tre grandi virtù di un programmatore: pigrizia, impazienza e arroganza. (Larry Wall).
Prima di postare un file togli i commenti con Code: | grep -vE '(^[[:space:]]*($|(#|!|;|//)))' |
|
|
Back to top |
|
|
mouser Veteran
Joined: 10 Aug 2004 Posts: 1419 Location: Milano
|
Posted: Fri Dec 22, 2006 9:57 am Post subject: |
|
|
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
Ciriciao
mouser |
|
Back to top |
|
|
Kernel78 Moderator
Joined: 24 Jun 2005 Posts: 3654
|
Posted: Fri Dec 22, 2006 10:19 am Post subject: |
|
|
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
Se volessi un sistema così instabile installerei winzozz _________________ Le tre grandi virtù di un programmatore: pigrizia, impazienza e arroganza. (Larry Wall).
Prima di postare un file togli i commenti con Code: | grep -vE '(^[[:space:]]*($|(#|!|;|//)))' |
|
|
Back to top |
|
|
topper_harley Guru
Joined: 05 Apr 2006 Posts: 363 Location: Treviso / Udine (Italy)
|
Posted: Fri Dec 22, 2006 10:35 am Post subject: |
|
|
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. _________________ http://topperh.ath.cx
Jabber: topper_harley@jabber.org
ICQ: 224179391
MSN: Topper_Harley80@gmail.com
Last FM |
|
Back to top |
|
|
mrfree Veteran
Joined: 15 Mar 2003 Posts: 1303 Location: Europe.Italy.Sulmona
|
Posted: Fri Dec 22, 2006 10:41 am Post subject: |
|
|
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 _________________ Please EU, pimp my country!
ICE: /etc/init.d/iptables panic |
|
Back to top |
|
|
mouser Veteran
Joined: 10 Aug 2004 Posts: 1419 Location: Milano
|
Posted: Fri Dec 22, 2006 10:43 am Post subject: |
|
|
Step 1
Qualcosina sta uscendo, pian piano
In pratica guardando, per esempio, xmms2
Code: | # 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
Code: | # ./emerge-overlay -o xmms2
[--] Overlay selected for package xmms2 - zugaina
# |
In situazioni un pò più complesse, invece, come questa:
Code: | # 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
Code: | # ./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 |
|
Back to top |
|
|
Kernel78 Moderator
Joined: 24 Jun 2005 Posts: 3654
|
Posted: Fri Dec 22, 2006 10:45 am Post subject: |
|
|
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 ).
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. _________________ Le tre grandi virtù di un programmatore: pigrizia, impazienza e arroganza. (Larry Wall).
Prima di postare un file togli i commenti con Code: | grep -vE '(^[[:space:]]*($|(#|!|;|//)))' |
|
|
Back to top |
|
|
Kernel78 Moderator
Joined: 24 Jun 2005 Posts: 3654
|
Posted: Fri Dec 22, 2006 10:54 am Post subject: |
|
|
mouser wrote: | In situazioni un pò più complesse, invece, come questa:
Code: | # 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
Code: | # ./emerge-overlay -o xmms
[--] Overlay selected for package xmms - zugaina |
|
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. _________________ Le tre grandi virtù di un programmatore: pigrizia, impazienza e arroganza. (Larry Wall).
Prima di postare un file togli i commenti con Code: | grep -vE '(^[[:space:]]*($|(#|!|;|//)))' |
|
|
Back to top |
|
|
Luca89 Advocate
Joined: 27 Apr 2005 Posts: 2107 Location: Agrigento (Italy)
|
Posted: Fri Dec 22, 2006 10:57 am Post subject: |
|
|
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. _________________ Running Fast! |
|
Back to top |
|
|
mouser Veteran
Joined: 10 Aug 2004 Posts: 1419 Location: Milano
|
Posted: Fri Dec 22, 2006 11:13 am Post subject: |
|
|
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 |
|
Back to top |
|
|
topper_harley Guru
Joined: 05 Apr 2006 Posts: 363 Location: Treviso / Udine (Italy)
|
Posted: Fri Dec 22, 2006 11:31 am Post subject: |
|
|
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... _________________ http://topperh.ath.cx
Jabber: topper_harley@jabber.org
ICQ: 224179391
MSN: Topper_Harley80@gmail.com
Last FM |
|
Back to top |
|
|
mouser Veteran
Joined: 10 Aug 2004 Posts: 1419 Location: Milano
|
Posted: Fri Dec 22, 2006 11:45 am Post subject: |
|
|
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 |
|
Back to top |
|
|
Kernel78 Moderator
Joined: 24 Jun 2005 Posts: 3654
|
Posted: Fri Dec 22, 2006 12:31 pm Post subject: |
|
|
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 ... _________________ Le tre grandi virtù di un programmatore: pigrizia, impazienza e arroganza. (Larry Wall).
Prima di postare un file togli i commenti con Code: | grep -vE '(^[[:space:]]*($|(#|!|;|//)))' |
|
|
Back to top |
|
|
Ic3M4n Advocate
Joined: 02 Nov 2004 Posts: 3489 Location: Bergamo.
|
Posted: Fri Dec 22, 2006 1:02 pm Post subject: |
|
|
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 -*. |
|
Back to top |
|
|
mouser Veteran
Joined: 10 Aug 2004 Posts: 1419 Location: Milano
|
Posted: Fri Dec 22, 2006 4:35 pm Post subject: |
|
|
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
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 |
|
Back to top |
|
|
topper_harley Guru
Joined: 05 Apr 2006 Posts: 363 Location: Treviso / Udine (Italy)
|
Posted: Fri Dec 22, 2006 5:06 pm Post subject: |
|
|
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
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 |
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. _________________ http://topperh.ath.cx
Jabber: topper_harley@jabber.org
ICQ: 224179391
MSN: Topper_Harley80@gmail.com
Last FM |
|
Back to top |
|
|
Luca89 Advocate
Joined: 27 Apr 2005 Posts: 2107 Location: Agrigento (Italy)
|
Posted: Fri Dec 22, 2006 10:42 pm Post subject: |
|
|
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. _________________ Running Fast! |
|
Back to top |
|
|
Ic3M4n Advocate
Joined: 02 Nov 2004 Posts: 3489 Location: Bergamo.
|
Posted: Fri Dec 22, 2006 10:56 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
topper_harley Guru
Joined: 05 Apr 2006 Posts: 363 Location: Treviso / Udine (Italy)
|
Posted: Fri Dec 22, 2006 10:58 pm Post subject: |
|
|
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". _________________ http://topperh.ath.cx
Jabber: topper_harley@jabber.org
ICQ: 224179391
MSN: Topper_Harley80@gmail.com
Last FM |
|
Back to top |
|
|
unz l33t
Joined: 28 Jul 2004 Posts: 819 Location: Roma, Italia
|
Posted: Fri Dec 22, 2006 11:31 pm Post subject: |
|
|
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. _________________ Ma che c'hai là? Sulla spalla!!!! http://lascimmia.it/ |
|
Back to top |
|
|
|