 |
|
Gentoo Linux Cascading/Stackable Profiles 1.Introduzione Storicamente, una delle caratteristiche più apprezzate di Gentoo è stata la mancanza di disordine. Ne sono un perfetto esempio le eclass di Dan Armak, codice posto in un file separato ma condivisibile in caso di necessità. D'altra parte la gerarchia della directory ${PORTDIR}/profiles è diventata ultimamente vittima di molto disordine. I cascading profile (anche conosciuti come stackable profile) sono l'approccio "object-oriented" per il Gentoo system profile. Quali potrebbero essere i benefici del cascading profile. Una rapida occhiata ad ogni profilo (prendiamo per esempio i profili della versione 2004.0 per le architetture x86, ppc, sparc e sparc64) rivela che si sono molte cose in comune. L'esempio più ovvio è il virtual file. Fino ad ora, ogni volta che veniva introdotto un nuovo pacchetto virtuale, tutti i virtual file in ogni profile directory dovevano essere aggiornati. Inoltre, per ogni sistema Gentoo di Base, c'è un insieme comune di pacchetti. Da qui, la domanda del perché ripetere queste informazioni per ogni profilo presente e futuro. E da qui anche la soluzione: l'introduzione dei cascading profile. 2.Sezionare lo stack Chris PeBenito ha posto le basi per il cascading profile, selezionando un insieme base di pacchetti richiesto da ogni sistema *nix di base. ${PORTDIR}/profiles/base contiene la descrizione di questo sistema di base. In questa directory ogni profilo di Gentoo aveva finora la lista di questi pacchetti nel file packages, ogni profilo ha gli stessi pacchetti virtuali definiti nel file virtuals ed infine i flag USE che sono comuni a tutte le architetture sono descritti nel file use.defaults. Dando un'occhiata al file packages potrebbe sorprendere dov'è finito il pacchetto util-linux. Così, vedendo anche lo sforzo di espandere Gentoo nel mondo di GNU/Hurd, OpenBSD ed altri, il pensiero è stato che il profilo base dovrebbe essere comune a tutte queste entità. Dobbiamo pur ammettere che le coreutils sono un pò più GNU specifiche, ma facciamo un passo alla volta. Speriamo che una volta letti i file nella directory base, siate d'accordo che molte parti descrivono un'implementazione agnostica minima per sistemi *nix. Il profilo predefinito (Linux/GNU) Questo profilo descrive in termini relativamente ad alto livello il profilo definito default-linux. Storicamente, ogni nuova architettura supportata da Gentoo ha avuto un profilo default, default-linux è una sostituzione ad alto livello di questo. Tra il profilo base e il profilo default-linux dovremmo avere un descrizione completa di un sistema GNU/Linux minimale. Questo è ottenuto aggiungendo (o rimuovendo) la lista dei pacchetti aggregata, mappe virtuali e definendo una mappa di flag USE (introducendo eventualmente nuovi flag USE o mascherandone altri). I profili per architetture specifiche Questi profile estendono il profilo aggregato default-linux aggiungendo o rimuovendo dei pacchetti, definendo specifiche mappe virtuali e flag USE. Inoltre, possono essere mascherati flag USE. I profili per sotto-architetture Questa specificità è completamente opzionale. Nell'implementazione corrente, il profilo per sparc è definito in maggiore dettaglio in una famiglia di profili per architetture SPARC 32-bit e SPARC 64-bit, dato che la famiglia SPARC ha molte consistenze e similitudini. Anche le sotto-architetture MIPS saranno definite in profili per sotto-architetture. Questi profili, essenzialmente delineano, sempre in termini ad alto livello, le differenze tra le sotto-architetture. Per esempio gcc-sparc64 è richiesto dai profili SPARC64, ma non ne è permesso l'uso nei profili SPARC32, entrambe usano lo stesso bootloader. Per questo, il bootloader dovrebbe essere in un profilo comune (specifico per architettura), mentre il pacchetto gcc-sparc64 dovrebbe essere definito nel profilo della sotto-architettura sparc64. Questo profilo è usato primariamente per bloccare specifiche versioni di pacchetti (anche se profili di livello più alto sono altrettanto liberi di farlo) e definire, per esempio, a cosa serve esattamente il profilo sparc64-2004.0 e come differisce dai profili sparc64-1.4 e sparc64-gcc33, e come differiscono i profili x86/2004.0 e x86/gcc2. 3.Le classi di profili Storicamente, ogni nuova architettura che Gentoo supporta risiede in una directory default-${arch}-${version} in ${PORTDIR}/profiles. Inevitabilmente sono stati profili basati su linux. Il futuro, comunque, è aperto. Così con i cascading profile possiamo definire classi di profili che estendono il profilo base. La prima classe da cui derivano tutte le architetture correnti, sarà default-linux. Le altre classi di profili sono selinux e hardened. Questo documento si focalizza esclusivamente sulla classe di profili default-linux dato che le altre due sono classi estremamente specialistiche gestite dall' Hardened team. Il profilo (Linux) predefinito La directory default-linux contiene i file parent, packages, use.default, use.mask, e virtuals, insieme a directory che prenderemo in esame nella prossima sezione. Il file parent contiene il percorso relativo del profilo da cui vengono ereditati gli attributi. In questo caso, dovrebbe contenere: ../base. Il file packages estende semplicemente il file packages del profilo base in tre modi:
Il file use.default svolge un'azione simile. Potete usare questo file per aggiungere mappe di flag USE per questa classe di profili o sovrascrivere una mappa di flag USE descritta nel profilo parente. Il file use.mask è usato per invalidare certi flag USE in questa classe di profili. Per esempio, il flag USE selinux è valido solo nelle classi di profili hardened e selinux, ma creerà caos nel profilo della classe default-linux. Per questo sarà mascherato in questo file. Il file virtuals estende il file virtuals parente. Potete continuare ad usarlo per aggiungere mappe virtuali che dovrebbero essere valide solo in questo profilo, o per sovrascrivere le mappe parenti. 4.I profili per architettura Con i profili per architettura siamo vicino alla fine del cascading profile. Questo è il livello nel quale saranno aggiunte nuove architetture. Per ricapitolare, abbiamo il profile base e il profilo default-linux che definiscono un sistema base indipendente dalle architetture. Per molte architetture, questo livello della cascata (o stack se preferite) definisce alcune specifiche, Per esempio, la mappatura del virtual/bootloader può essere definita in questo livello dato che ogni classe di architettura usa un differente bootloader predefinito. In aggiunta, ci potrebbero essere cose specifiche per architettura che sono richieste come parte del sistema di base, come: sparc-utils per SPARC. Alcune architetture mascherano i flag USE per le altre architetture. Per esempio, il profilo sparc ha x86, ppc, alpha e mips nel file use.mask a questo levello. Profili per sotto-architetture Questo è un livello opzionale nella cascata. La premessa è che se una famiglia di architetture (per esempio SPARC e MIPS) ha basilarmente le stesse necessità per un sistema di base con solo alcune differenze (siano esse pacchetti, pacchetti virtuali o flag USE), queste sono espresse qui. 5.Il profilo finale Parte della ragione per il palleggio dei profili è stata l'aggiunta di un profilo per ogni nuova release dei liveCD. Quando passate dai vecchi profili al nuovo sistema a cascata, analizzate minuziosamente le differenze reali tra i profili della vostra architettura. Nel caso dei profili per x86, troverete che quelli della 1.4 e della 2004.0 sono identici, per questo in nuovi sistema saranno uniti in profili 2004.0 a cascata. I team releng e dev-portage hanno determinato insieme che la soluzione ideale è di creare un nuovo profilo solo quando assolutamente necessario. Il profilo finale conterrà un file indicante che è veramente la fine della cascata. Questo è il file make.defaults. Come sopra, il file parent punterà alla directory parente e, naturalmente, i file packages, use.defaults, use.mask e virtuals potranno essere sovrascritti o estesi. Idealmente, qui è dove possono essere bloccate cose per specifiche versioni. Usare questo per definire concretamente il vostro profilo. 6.Conclusioni Dobbiamo ammettere che la migrazione dei vostri profili ad uno schema a cascata è un pò tedioso, ma alla fine il guadagno è inestimabile. Per esempio, nuovi pacchetti virtuali non dovranno essere più aggiunti ad ogni singolo file virtuals in ogni singola directory per profilo. Una volta aggiunti ai livelli base o default-linux, il gioco è fatto. Se avete domande, indirizzatele e Seemant, SHeN o agli altri membri del team releng. |
|
