Tuttavia sono qui e ho appena iniziato lo spostamento del blog su un dominio tutto mio ( eh oh.. wordpress.com e’ una buona piattaforma.. ma voglio essere piu’ libero ).

Il blog sara’ raggiungibile su www.delian.it ( sono stato molto contento di trovare libero questo dominio ^^ , e’ valso anche l’obbligo di invio della LAR al N.I.C. che prende un  bel po’ di tempo ) . Abbiate pazienza per il restyling e l’organizzazione .

Colgo l’occasione per augurare a tutti ( soprattutto coloro che ancora passano a dare un’occhiata qui, nonostante non lo aggiorni da un po’), un buon ininizio di meritate vacanze Pasquali ^_^.

Per chi non lo sapesse, il nome della distro deriva da una specie di pinguini dal becco rosso, i gentoo penguins appunto.

In casa Gentoo, ultimamente, si sono concretizzati terremoti che hanno rivelato molte crepe sulla solidita’ del gruppo di sviluppo e generato (non poche) spiacevoli conseguenze.

Spesso si e’ arrivati a flame senza senso o discussioni inutili su cose gia’ dette: ci sono log pieni di persone che si insultano vicendevolmente, non basta per quello accendere la tv?. Mi direte: “c’e’ chi ha dato fuoco al pagliaio!” ma, a conti fatti, direi che ha poca importanza, perche’ non ha importanza chi ha ragione o chi no ma, il fatto che, i risultati che si ottengono alimentando questo fuoco, sono quello di perdere tempo e voglia dietro a scaramucce infantili.

Si tratta sempre del solito problema di vivere in una comunita’.

Si tratta del fatto che non siamo tutti uguali e non pensiamo, non agiamo allo stesso modo. E’ inevitabile discutere su qualcosa, non essere d’accordo.. anzi, e’ fondamentale per una crescita, se la discussione e posta in modo costruttivo.

Questo non e’ avvenuto. Probabilmente anche per una carenza della stessa politica di Gentoo che, a detta dal forum, ha prodotto forse troppe “prime donne” e troppe discussioni sfocianti in liberi insulti personali. A tal proposito e’ infatti in stesura un “Codice di Comportamento” per mettere un freno al trolling e flaming insensato e porre in primo piano la necessita’ di un rispetto reciproco, in favore di una piu’ pacifica e sicuramente piu’ proficua convivenza.

Ultimamente, questo comportamento, ha provocato l‘abbandono di alcune persone. E’ un evento spiacevole che toglie forza alla comunita’ senza un reale motivo. Nonostante sia comprensibile l’abbandono di queste persone, travolte da una situazione direi insostenibile, non mi trovo pienamente d’accordo con la loro decisione: comprendo che in un ambiente dove dopo tutto il tempo e le risorse impiegate in qualcosa si viene denigrati gratuitamente possa risultare scoraggiante ma, se davvero si crede in quello che si sta facendo, dovrebbe esser chiaro che andarsene non gioverebbe affatto anzi.. direi che lascerebbe piu’ spazio a chi il flamer lo fa di professione.

Particolarmente vorrei ( anche io, se ne parla parecchio in giro ) sottolineare l’episodio di Daniel Robbins, fondatore di Gentoo(a tal proposito vi consiglio questa lettura), che abbandono’ il progetto qualche anno’ fa e ando’ a lavorare da M$ con stupore di molti utenti (anche insulti, ma sappiamo da che tipo di utenti provenivano ). Il 16 Gennaio di quest’anno (oops.. ancora credo di essere nel 2006 ..perdonatemi . grazie randomaze della correzione) del 2006 si e’ licenziato e si e’ ultimamente ripresentato nella comunita’ con la voglia di riprendere a contribuire ma, come se si fosse seduto su un detonatore, e’ stato bersagliato in continuazione, tanto da spingerlo ad abbandonare nuovamente. Sono dell’idea che il fatto che abbia lavorato da M$ e il perche’ siano assolutamente cazzi cavoli suoi, e cio’ non dovrebbe in alcun modo pregiudicare il suo apporto alla comunita’. L’apporto che avrebbe potuto dare sarebbe stato veramente grande.. ma tant’e’ che ad alcune persone deve piacere darsi la zappa sui piedi.

I recenti scossoni lasciano, a mio avviso, il segnale un problema di fondo nell’organizzazione di sviluppo: si sente la mancanza di un leader, non un dittatore ma un leader. E’ bello che ci sia questa sorta di democrazia a livello di sviluppo ma, inevitabilmente, portera’ a diverse fratture d’opinione.

Per me Daniel Robbins sarebbe potuto essere la colla per tenere assieme il tutto. ( Lo ammetto.. forse fantastico un po’ )
Ma.. un attimo.. non vorrei lasciar trasparire che sia solo una questione tra developers: utenti del suddetto tipo ce ne sono (purtroppo) abbastanza e non fanno altro che danneggiare la comunita’.

Io amo Gentoo, penso si sia capito, perche’ mi fa ottenere da lei esattamente quello che voglio, perche’ c’e’ un’enormita’ di documentazione, howto, strumenti, idee.. e’ la distribuzione che fa per me, che piu’ si avvicina alle mie esigenze. Effettivamente non sono mai stato eccessivamente contento di alcuni comportamenti di superiorita’ presunta e milioni di “RTFM” e, quando mi avvicinai per la prima volta a Gentoo, non e’ stato per niente incoraggiante.. ( non me ne vogliate se, ad esempio, nomino esplicitamente il canale #gentoo sul server azzurra.. ma li, in passato, sono incorso spesso in situazioni di questo tipo) perche’, ammettiamolo, Gentoo richiede una certa dimestichezza con strumenti e nozioni per iniziare ad usarla e, alcune volte, anche seguendo le sterminate guide, ci si trova intoppati. Gentoo, di solito, annovera come utilizzatori i cosi’ detti “Power User” ma, credo, che troppo Power a qualcuno abbia dato alla testa.. una buona dose di umilta’ farebbe bene a molte persone. Dov’e’ la passione per l’informatica, la gioia di condividere idee, opinioni, la volonta’ di migliorare sempre a beneficio di tutti? Quando la smetteremo di punzecchiarci a vicenda invece di costruire qualcosa insieme?

La perdita di valori nella societa’ inevitabilmente colpisce anche questo mondo e cio’ mi rattrista enormemente..

Sono tornato questa mattina e.. sono piu’ o meno a pezzi XD ( maledetti treni espresso ).

Al prossimo post.. appena mi riprendero’ !

^_^

Al solito, introduzione

La variabile USE e’ molto importante in una Gentoo-Box. Grazia ad essa e’ possibile compilare gli applicativi abilitando o disabilitando eventuali elementi degli stessi come funzionalita’ aggiuntive, collegamenti con altri applicativi, supporto a specifiche librerie. E’ una funzionalita’ molto potente, in quanto permette un totale controllo su quello che verra’ installato e, molto spesso evitera’ molte dipendenze inutili e sprechi anche di spazio su HD ( anche se la tecnologia lo permette, perche’ sprecarlo? ). Di default, in base al profilo, sono attivate automaticamente aclune flags, ma e’ possibile poi scegliere secondo le nostre esigenze. Esistono delle USE Flags “Globali”, definite per tutti i packages, che sono quelle dichiarate nel file /etc/make.conf, e delle USE Flags “Locali”, ovvero definite per un singolo pacchetto ma… facciamo un esempio:

Vogliamo la gui di lshw e non abbiamo gtk nelle USE Flags “Globali” per nostra scelta. Se attivassimo gtk nella USE Globale, tutti i pacchetti con “la possibilita’ di quella USE Flag” vorrebbero essere ricompilati per aggiungere il supporto a gtk. Non e’ questo che vogliamo. La soluzione e’ inserire nel file /etc/portage/package.use la riga sys-apps/lshw gtk. In questo modo solo lshw verra’ compilato con il supporto a gtk.

package.use puo’ essere molto utile quando viceversa vogliamo disattivare localmente una USE Flag definita globalmente, ad esempio disattiviamo il supporto a java per firefox:

www-client/mozilla-firefox-bin -java

Dove invece java era presente nelle USE globali.

Terminata questa piccola introduzione, veniamo alla modifica della variabile USE : come modificarla?

Il metodo “a manina” prevede di editare manualmente il famoso/pericoloso file /etc/make.conf. ( ad esempio non provate mai a cambiare la variabile CHOST senza sapere cosa state facendo )

Oltre ad essere una pratica scomoda, non consente di avere un buon controllo ad esempio sul significato di alcune flag e, quando iniziano a diventare un numero consistente, puo’ generare confusione e portare via tempo nella ricerca dell’USE desiderata ( vi sfido a mantenerla ordinata in ordine alfabetico a manina con almeno 50 flags ).

Ed ecco che interviene ufed.

ufed e’ l’acronimo di USE Flags EDitor, e che dire..fa solo questo e lo fa bene! La filosofia e’ certamente in linea con quella *nix.

E’ un programma scritto in perl che fa uso delle ncurses e dotato di un’ottima usabilita’ ( migliorata nelle ultime versioni ) grazie a cui, digitando le prime lettere, ci consente rapidamente di abilitare/disabilitare ( basta usare la barra spaziatrice ) una determinata USE e uscire al volo premendo enter e nuovamente enter per confermare, il tutto senza toccare /etc/make.conf direttamente.

Oltretutto consente di avere sottomano anche il significato di tutte le USE ed eventualmente, se ha valori diversi per packages diversi, le spiegazioni separate relative ad ognuno di essi. Comodo vero?

Al solito, se non lo conoscete gia’, vi invito ad una rapida prova:

root@ # emerge ufed

root@ # ufed

ed ecco come dovrebbe apparirvi (sempre click per ingrandire ^^):

pronto alle modifiche secondo le vostre esigenze.

Per concludere anche il discorso con l’introduzione alle USE flags sappiate che le modifiche apportate non sono immediate, ma verranno applicate solo alla successiva ricompilazione dei pacchetto con tali USE Flags. Se volete aggiornare tutti i pacchetti, secondo la scelta di USE flags che avete operato, e’ sufficiente aggiungere ad emerge l’opzione –newuse ( o -N in versione contratta ) :

root@ # emerge –ask –verbose –update –deep –newuse world

o in versione contratta

root@ # emerge -avuDN world

e avrete tutti i packages che e’ necessario ricompilare, in quanto non allineati con l’attuale configurazione di USE flags.

Al solito, vi rimando ai sempre utili man per eventuali approfondimenti ^^.

Girovagando, come mio solito, mi sono imbattuto in questo simpatico programma che fa uso appunto delle ncurses ( delle librerie grafiche per la console, utilizzate per esempio nel menuconfig del kernel ) giudicate voi la differenza (click per ingrandire):

Notiamo subito che e’ possibile scorrere tra i processi, fare ricerche, evidenziare un processo ( con il tasto spazio ), ordinare in base al campo scelto, tutto in modo molto intuitivo e veloce.Molto carino il grafico sull’occupazione di CPU,Memoria e Swap: anche se mangia parecchio spazio, lo preferisco al voler comprimere tutto per far entrare molte informazioni; se non siete della mia stessa idea, non disperate, nel setup e’ possibile personalizzare molti aspetti di htop.

Tra gli altri menu’ sull’ultima riga, notiamone alcuni che aggiungono una piccola interattivita’ con i processi: possiamo lanciare kill su un processo o variarne la priorita’.

Non e’ il programma del secolo ma, per l’uso che ne faccio io, lo trovo piu’ funzionale rispetto a top, e questo mi basta.

Il consiglio per giudicarlo e’, come sempre, di provarlo ^^

Sulla nostra Gentoo-box diamo un bel

root@ # emerge htop

e in brevissimo avremo htop pronto a servirci.

P.S. Se vi preoccupa il suo consumo di risorse, non differisce da quello di top anzi, sul mio pc, consuma anche leggermente meno memoria

/ecco alcuni search engines che ho scelto/

Per installarli e’ sufficiente andare al seguente link http://mycroft.mozdev.org , scegliere il Search-Engine ( i nomi sono abbastanza autoesplicativi) e accettare di aggiungere il Motore di Ricerca.

Prima di trovare tali search-engine mi ero messo a farne uno io per packages.gentoo.org e, devo ammettere che non e’ fatto difficile con la nuova specifica OpenSearch, anche supportata da IE7.

Se volete avere informazioni su come creare un search-engine ( ma non fate come me, cercate prima se esiste gia’ XD.. a meno che non lo facciate per fine educativo ^^ ) vi rimando a questo link e ai link citati in basso sullo stesso sito.

In particolare sottolineo questa sezione, di un sito citato sempre nella stessa pagina, in cui, inserendo le informazioni richieste per il motore di ricerca, genera automaticamente il plugin pronto per essere utilizzato ^^.

Buona ricerca

Innanzitutto installiamo eix

root@ # emerge eix

non dovrebbe avere particolari dipendenze ( a meno che non decidiate di attivare la USE sqlite e, nel caso non lo aveste ancora installato, istallera’ anche sqlite) ma non dobbiamo preoccuparcene: come sempre emerge fara’ da solo il suo lavoro.

A questo punto e’ necessario costruire la eix-cache tramite il seguente comando:

root@ # update-eix

Il programma fara’ una scansione del nostro MainTree e anche degli Overlay costruendo la cache di eix.

Adesso non resta che usarlo . Vediamo il suo uso piu’ comune, la ricerca di un pacchetto tramite il suo nome (come noterete e’ possibilie fare ricerche anche da un utente non presente nel gruppo portage):

# eix beryl

di cui riporto un estratto dell’output complessivo ( la chiave beryl viene interpretata da eix come se fosse *beryl*, includendo nei risultati per esempio un package di nome beryl-core ma anche uno ( lo sto inventando ) di nome icon-beryl ):

/cliccate sull’immagine per vederla intera/

Capite l’importanza di mostrare l’immagine piuttosto che il testo . Vediamo di comprendere l’output: Il alto a sinistra vediamo [I] in cui eix ci informa che il package e’ installato ed e’ l’ultima versione disponibile secondo la configurazione.

Successivamente vediamo le versioni disponibili: qui sono molto importanti i colori; il verde indica una versione dichiarata Stable, in arancio una versione “masked by ~” ( in testing ) e, in questo caso, anche una versione in rosso con cui vengono indicate versioni masked che, di solito, conviene non istallare in quanto instabili o, come in questo caso (quando vedete un package con versione 9999 ), versioni in sviluppo, prese direttamente dai repository, CVS o SVN e similia, degli sviluppatori ( ma potrebbe anche indicare versioni non disponibili per la propria architettura) . Accanto ad alcune versioni notate un numero in celeste tra parentesi quadre, voliamo alla fine dell’output di eix per trovarne una spiegazione:

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

Il package appartiene ad un’overlay e non al MainTree utilissima informazione.

Procedendo ancora, eix ci informa di quale versione abbiamo sul nostro sitema e quando l’abbiamo installata, fornendo, inoltre, una lista delle USE del package ( in rosa le attive e, in grigio precedute da un “-”, quelle non attive) . Le ultime due righe mostrano l’homepage del programma e una sua descrizione.

Tutte queste “entryes” possono essere campo di ricerca attivando la relativa flag, esempio:

# eix -C app-portage

restituira’ tutti gli ebuilds appartenenti alla categoria “app-portage”. Ma possono essere anche combinate fra loro:

# eix -C app-portage -S USE

Inoltre e’ possibile ricercare solo tra i pacchetti installati, invertire le ricerche e, per chi le conosce, utilizzare le potenti espressioni regolari (utilizzando la flag -r).

Rimando per una lista dei campi, per informazioni aggiuntive sul significato di colori e simboli e ulteriori opzioni di ricerca ( trattarli tutti avrebbe reso l’articolo un po’ troppo pesante ) al sempre indispensabile

# man eix

Ora vi chiederete, ma quando aggiorno il MainTree con emerge –sync, eix fa tutto da solo e aggiorna la sua cache? Purtroppo no. Essendo il DB di eix indipendente da Portage, sarebbe necessario ricreare la cache dopo ogni emerge –sync ( ed era cosi’ nelle prime versioni ); nelle ultime versioni, pero’ ,e’ disponibile un comodissimo script chiamato eix-sync che, non solo lancia emerge –sync, ma alla fine lancia il comando diff-eix, che compara il vecchio DB e il nuovo, mostrandone le differenze ( utilizzando sempre lo schema di colori e simboli di eix ) come l’aggiunta di packages, la rimozione, gli aggiornamenti..

Osservate come ordinatamente ci mostra le nuove versioni, i nuovi packages, e le rimozioni.

Ma non e’ finita qui..Avete uno o piu’ overlays gestiti con layman e vi noia fare prima layman -S e poi eix-sync ( certo che siamo proprio pigroni XD ) e volete fare un sync generale in un sol colpo? Eix puo’ farlo per voi:

root@ # echo -e ‘# Aggiorniamo tutti gli overlays con layman \n!layman -S’ >> /etc/eix-sync.conf

(controllate bene cosa vien fuori usando il copia/incolla, worpress opera alcune sostituzioni che possono produrre risultati indesiderati )

in questo modo eix-sync lancera’ prima layman -S, poi emerge –sync e, successivamente, vi mostrera’ tutti gli aggiornamenti.

Adesso, avete per le mani uno strumento veloce e potente per scandagliare e tenere sott’occhio tutti i vostri ebuilds nei minimi dettagli; usatelo ,se non lo fate gia’, e vi chiederete come abbiate potuto farne a meno fino ad ora .

Vi siete mai chiesti perche’, sui notebook, la nostra Gentoo si ostini ad avviare l’interfaccia eth0 ( nel mio caso ), anche se il servizio non e’ presente nei runlevels ( potete verificare cio’ eseguendo # rc-update show ) e nessuno cavo e’ stato inserito?

UPDATE: ecco un ottimo workaround proposto da mambro, che ringrazio: modificare da root il file /etc/conf.d/rc inserendo ( o aggiungendo nella stessa se esiste gia’) la seguente variabile:

RC_PLUG_SERVICES=”!net.eth0″

che in pratica nega al servizio net.eth0 di avviarsi in automatico. La ricerca della soluzione al problema titolo del post, pero’ , mi ha portato a conoscere simpatiche funzioni come preup() e predown() e altre, che possono avere svariati utilizzi. Per saperne di piu’ continuate a leggere ^^!

Me lo sono chiesto anche io.. Molte.. molte volte. Non e’ un problema particolarmente rilevante per chi usa, per collegarsi, l’interfaccia ethernet ma, per quanto mi riguarda, utilizzo un Adattatore USB Wireless e, per molto tempo, sono stato succube di una tediosa routine dopo l’avvio dell’ambiente grafico:

1. Aprire la console
2. Diventare root
3. Fermare il servizio net.eth0
4. Inserire l’adattatore

Questo perche’, essendo gia’ attivo il servizio net.eth0, anche inserendo l’Adattatore Wireless, la rotta predefinita e’ impostata verso l’interfaccia eth0.

Ho pensato anche a qualche dipendenza (un servizio poteva necessitare eth0) ma la domanda era sempre: perche’ solo sui notebook? .

Cercando qua e la’ non sono riuscito a trovare delucidazioni in merito ( anzi, invito chiunque ne conosca la causa a farla presente ) e mi sono adattato con la tediosa routine . Ultimamente, pero’, ho configurato una Gentoo-Box sul portatile di mio padre e, francamente, avere come obbligo all’avvio il fermare un servizio da root etc., se gia’ era scomodo per me ( che almeno so il significato di quelle azioni ) figuriamoci per mio padre.. poi, diciamocelo, e’ veramente uno spreco inutile di tempo.

Armato di una modesta decisione, ho cercato un modo di risolvere questo problema e cerca qua, cerca la’.. ho notato, nella configurazione delle interfacce di rete, qualcosa che non avevo mai notato: alcune funzioni che, se definite, vengono chiamate in precisi momenti della “vita” dei servizi delle interfacce di rete. Subito e’ balzata all’occhio la funzione che faceva per me, ne riporto direttamente la definizione tratta dal file di esempio (ho tradotto la spiegazione dall’inglese per comodita’):

preup() {
# Controlla la presenza di segnale sull’interfaccia prima di avviarla.
# Funziona soltanto su alcuni adattatori di rete e richiede di installare
# il package mii-diag.
if mii-tool “${IFACE}” 2> /dev/null | grep -q ‘no link’; then
ewarn “No link on ${IFACE}, aborting configuration”
return 1
fi
# Controlla la presenza di segnale sull’interfaccia prima di avviarla.
# funziona soltanto su alcuni adattatori di rete e richiede di installare
# il package ethtool.
if ethtool “${IFACE}” | grep -q ‘Link detected: no’; then
ewarn “No link on ${IFACE}, aborting configuration”
return 1
fi
# Remember to return 0 on success
return 0
}

Bene! Ora e’ sufficiente installare uno dei due programmi ( a me e’ andato bene ethtool )

root@ # emerge ethtool

e inserire la funzione ( con solo il controllo da parte del programma che abbiamo scelto ) nel file /etc/conf.d/net; nel mio caso ho inserito:

preup() {
# Controlla la presenza di segnale sull’interfaccia prima di avviarla.
# funziona soltanto su alcuni adattatori di rete e richiede di installare
# il package ethtool.
if ethtool “${IFACE}” | grep -q ‘Link detected: no’; then
ewarn “No link on ${IFACE}, aborting configuration”
return 1
fi
# Remember to return 0 on success
return 0
}

et voila’.. riavviare per credere: ethtool non trova il link e il servizio net.eth0 non viene avviato ^^.

N.B. Il controllo verra’ effettuato su tutte le interfacce.

Ammetto che questo e’ un mezzo workaround ( workaround = non una genuina risoluzione del problema alla fonte ma un tappabuchi temporaneo ) ma, almeno finche’ non carpiro’ il mistero celato dietro quell’avvio automatico ( che ripeto, solo sui Notebook :/ ), fa il suo lavoro. Nonostante questo, mi ha permesso di scoprire queste simpatiche funzioni che, in molte situazioni, possono tornare molto comode. Per una conoscenza ravvicinata, vi consiglio di spulciare il file /etc/conf.d/net.example o attendere un mio prossimo post: sono cose utili e verranno certamente trattate .

Spero di aver eliminato da qualche vita una noiosa routine. ^^

Ecco a voi una “piccolezza.. ma non troppo” per chi come me vuole avere una gestione pulita e ordinata del package.keywords.

Al solito, piccola introduzione

Gli ebuilds che dovessero essere marcati come “in Testing” o “Unstable” non vengono presi in considerazione da emerge, questo per evitare che vengano installate versioni o programmi non abbastanza sicuri o stabili.

A proprio rischio e pericolo e’ possibile smascherare (dato che gli ebuilds in questo stato vengono detti masked) tali ebuilds aggiungendo, da root, il nome del pacchetto nel file ( se non avete mai seguito nessun procedimento per smascherare un ebuilds probabilmente non avrete tale file ma, bastera’ crearlo di sana pianta) /etc/portage/package.keywords, ad esempio se voglio emergere kdmtheme (alla stesura ancora marcato ~x86 ossia “in Testing per l’architettura x86″) il mio package.keywords dovrebbe risultare cosi’:

kde-misc/kdmtheme ~x86

cio’ ordina al Portage di accettare tutte le versioni bloccate dalla marcatura ~x86 di kdmtheme. Notate che per evitare omonimie la sintassi prevede di indicare anche la categoria. E’ possibile anche fare una precisa distinzione della versione che vogliamo smascherare con questa esplicativa sintassi:

=www-client/mozilla-firefox-2.0.0.1-r4

oppure con operatori “maggiore di” “minore di”

>=www-client/mozilla-firefox-2.0.0.1-r2

Notate che in questo caso e’ necessario specificare la versione che intendiamo smascherare. Comunque non vi preocucpate.. se il file ha un qualche errore di sintassi, Portage si limitera’ a ignorare la riga e lamentarsi ogni volta che fate un emerge .

Mi pare una buona soluzione, no?

Si, parte della filosofia di gentoo e’ proprio la sicurezza di avere tutti i file di configurazione/gestione in plain/text ma, questo file, e’ accettabile se si hanno due o tre package smascherati; quando, iniziano a diventare abbastanza, lo trovo confusionario e poco flessibile.

La soluzione che adottavo era di dividere, tramite un commento, i “gruppi di package smascherati”(no, non e’ un’associazione di carnevale ), una situazione frequente, dato che, molto spesso, programmi marcati ~*(nel mio caso ~x86 ma esistono anche altre arch, facciamo un discorso generale ), richiedono qualche dipendenza anch’essa marcata ~*. Era un piccolo miglioramento di gestione ma.. era sempre un’ammucchiata di ebuilds.. e, eliminare qualche riga per fare pulizia, era sempre un impresa noiosa.
Di recente sono venuto a conoscenza della possibilita’ di applicare una gestione leggermente differente: e’ possibile, invece del file /etc/portage/package.keywords, creare una directory con lo stesso nome e, ogni file inserito in quella directory ( sempre con la sintassi descritta prima ) risultera’ come fosse parte di un unico /etc/portage/package.keywords.

Puo’ non sembrare un’eccessiva miglioria ma, oltre ad una struttura piu’ pulita e ordinata, aggiunge una “chicca” che altrimenti prima non sarebbe stata possibile:

Alcuni overlay, tra i loro files, portano anche un file ( in stile package.keywords) con la lista dei packages da smascherare, gia’ sistemata, da linkare nella cartella da noi creata.

Vantaggi:

1. Evitare di aggiungere ad uno ad uno i pacchetti necessari al software in questione ( pratica decisamente pallosa e perditempo )
2. Il file e’ sotto un controllo remoto da parte di chi gestisce l’overlay che, quindi, puo’ automaticamente sistemare e risolvere eventuali problemi ( ad esempio la necessita’ di downgradare un pacchetto o usarne una differente versione, o l’aggiunta di un nuovo pacchetto da smascherare) in modo a noi del tutto trasparente.

Svantaggi:

1. Non possiamo avere una visione completa dei packages smascherati. Ma.. ammetto che di questo IMHO non ne sentiro’ la mancanza.. era una tale accozzaglia di nomi…

Voglio questo cambiamento!

Bene! Se abbiamo gia’ sotto le mani un file package.keywords, rinominiamolo in qualcosa di consono come, ad esempio:

# mv /etc/portage/package.keywords /etc/portage/varius

Nel caso contrario creiamo direttamente la cartella

# mkdir -p /etc/portage/package.keywords

Sempre se lo avevamo in precedenza, spostiamo varius nella cartella appena creat

# mv /etc/portage/varius /etc/portage/package.keywords/

e iniziamo a creare file con i gruppi ( ad esempio kde-3.5.6 ) e fare finalmente un po’ di pulizia, lasciando varius per i “packages spaiati”.

Fine

Bene, adesso avete una gestione leggermente piu’ ordinata dei packages smascherati. Per la potenzialita’ descritta prima con gli overlays, vi rimando ad un prossimo articolo che sto scrivendo su enlightenment.

Buon unmask!

Layman e’ un comodissimo script in Python che aiuta a gestire comodamente gli overlays che si vuole includere nella propria Gentoo-Box.

Iniziamo pero’ introducendo cosa sono gli Gentoo-Overlays.

Nella comunita’ Gentoo, tutto il software disponibile, tramite il meraviglioso programma di gestione pacchetti che e’ Portage, e’ categorizzato e sistemato nell’albero principale di Portage ( d’ora in poi MainTree) come ebuilds (files che contengono le informazioni necessare da fornire al Portage per reperire i sorgenti e compilarli) .

Ci sono software, o versioni dello stesso, che, dopo varie prove, potrebbero essere stati marcati come instabili, che potrebbero corrompere il sistema, o che per altri motivi non siano stati inclusi nel MainTree. Spesso accade di desiderare proprio quel software che non e’ presente nel MainTree, oppure vogliamo provare delle versioni non testate ( che non e’ detto che siano instabili ) o sperimentali: nulla ci vieta di scrivere noi un ebuild per quel software che ci interessa ( e’ piu’ facile di quanto si pensi) , posizionarlo in un “MainTree locale” e poi darlo in pasto al Portage.. ma poi dovremo farci noi carico dell’aggiornamento dello stesso ( cambio di indirizzo per i sorgenti, nuove versioni.. etc).

A tal proposito, molte persone, scrivono ebuilds per tali software che vengono raccolti in “mini-alberi aggiuntivi”, gli Overlays.

E a questo punto interviene layman..

Layman viene in nostro soccorso aiutandoci a gestirne, in modo semplice e ordinato, la loro aggiunta, rimozione e aggiornamento.

Fase 1: installiamo layman

In una Gentoo-Box e’ la cosa piu’ semplice del mondo basta dare:

# emerge layman

e Portage si occupera’ di risolvere dipendenze, scaricare e compilare i pacchetti necessari per l’installazione.

Fase 2: la configurazione

Dopo aver emerso il programma, Portage vi comunichera’ delle informazioni gia’ sufficienti per un rapido uso di layman.. ma vediamole insieme.

Se e’ la prima volta che installiamo layman e’ necessario modificare il file /etc/make.conf aggiungendo la seguente riga (bisogna essere root per modificare questo importante file,prestate attenzione a cosa modificate) alla fine del file:

source /usr/portage/local/layman/make.conf

questo consentira’ a layman di dire al Portage dove sono i nostri overlays.( ancora la veggenza non e’ parte di Portage, ci stanno lavorando )

Fase 3: Scegliere ed aggiungere un Overlay

Per visualizzare gli Overlays disponibili e’ sufficente dare un:

# layman -L

questo comando ritorna una lista che, tolto qualche nome, puo’ non essere autoesplicativa sul conenuto dell’overlay. A tal riguardo consiglio di spulciare il seguente sito http://overlays.gentoo.org/proj/.

Una volta scelto l’overlay desiderato sara’ sufficiente dare:

# layman -a nomeoverlay

ad esempio

# layman -a xeffects

aggiungera’ l’overlay dedicato a programmi come compiz o beryl ( nelle loro ultime versioni non ancora passate MainTree di Portage).

Bene, la magia e’ compiuta! Ora avete, al fianco del Main Gentoo Portage Package Tree ( per fare i pignoloni XD ), gli ebuilds dall’overlay scelto. Non vi resta che installarli .

Fase 4: aggiornare gli overlays

Come ogni tanto ( vi ricordo che, per evitare di sovraccaricare gli rsync server, e’ buona cosa non fare il sync del MainTree piu’ di una volta al giorno ) diamo

# emerge –sync

anche gli ebuilds nell’overlay devono essere aggiornati. Può deluderci il nostro amico layman? Giammai!

# layman -s nomeOverlay

# layman -S

dove, il primo comando fa il sync per un singolo overlay e, il secondo, fa il sync per tutti gli overlays aggiunti alla nostra Gentoo-Box (tramite layman ovviamente).

Volendo unire con l’emerge –sync:

# emerge –sync && layman -S

cosi’ in un colpo avremo aggiornato il MainTree e tutti i nostri overlays.

Nel caso usaste eix ( programma che consiglio altamente e che sara’ tema di un prossimo articolo ) diamo un bel:

# layman -S && eix-sync

in modo che eix possa aggiungere nel suo DB anche gli ebuilds aggiornati dei nostri overlays.

Fase 5: eliminare un overlay

Nel caso dovesse essere necessario rimuovere un overlay, sara’ sufficiente avvalersi del seguente semplice comando:

# layman -d nomeOverlay

e layman provvedera’ a farlo sparire dalla vostra Gentoo-Box .

Beh, con questo si conclude questa mini-guida su questo comodo script; probabilmente in alcuni punti ho sottolineato cose che potrebbero sembrare scontate ma, dato che nessuno e’ nato con la conoscenza inculcata.. . Ci sono altre funzioni di questo programma che non ho menzionato, data la non utilita’ per una gestione base ma, per chi volesse approfondire, e’ sufficente il solito

# man layman

Eventualmente dovessero esserci dubbi, sono a disposizione ( nel limite delle mie capacita’) per delucidazioni in proposito.