Guida agli Split Ebuilds di KDE

1.Gli Split Ebuilds di KDE

Di cosa si tratta? 

Fino a Gennaio 2005 gli unici ebuilds di KDE disponibili in Portage erano quelli 'monolitici'. Questo significa che c'erano solo 15 ebuilds e ciascuno installava diverse applicazioni che, di fatto, non dipendevano l'una dall'altra. Una situazione non esattamente ottimale, e non in stile Gentoo, ma accettata per diverso tempo.

I nuovi split-ebuilds (ebuilds pacchettizati per konqueror, kmail, ...) hanno rimediato a questa situazione introducendo gli ebuilds per le singole applicazioni di KDE. Questo porta gli ebuilds della categoria kde-base a un totale di 330.

Gli ebuilds monolitici di KDE sono ancora disponibili e possono interagire in maniera trasparente con quelli splittati. Comunque gli split ebuilds sono il nuovo standard e a partire da KDE 4.0 gli ebuilds monolitici non saranno più disponibili.

Infine, segnaliamo che esistono split ebuilds anche per Koffice che mettono a disposizione kword, kugar ecc. come pacchetti separati.

Installare gli split-ebuild 

L'ultima versione stabile di KDE disponibile alla stesura di questo documento è la 3.4.3. L'ultima instabile (package.masked) è la 3.5.0_beta2. Portage offre entrambe le opportunità di installazione, splittata (pacchettizzata) e monolitica.

• Per emergere un particolare pacchetto, diciamo kmail, è sufficiente eseguire emerge kmail.
• Per emergere l'ambiente base di KDE, che consente il login a una sessione minimale, emerge kdebase-startkde.
• Infine, per ottenere lo stesso effetto di uno dei pacchetti monolitici usando gli split ebuilds - diciamo, per avere tutte le applicazioni incluse in kdebase - eseguire emerge kdebase-meta (oppure kdepim-meta, ecc.). Per ottenere tutti gli split ebuilds di KDE, eseguire emerge kde-meta.

Migrare dalla versione monolitica alla versione pacchettizata 

Se hai installato la versione 3.3.x di KDE, puoi installare la versione 3.4.x pacchettizata senza interferire con l'installazione esistente mediante emerge kde-meta. Lo stesso vale per la versione 3.5.x.

Se invece hai la versione 3.4.x monolitica devi prima rimuoverla per poi emergere gli split ebuilds che desideri. Il processo di rimozione/installazione può essere eseguito per ciascuno degli ebuild monolitici; non è necessario rimuovere KDE in blocco.

Nel dubbio, ricorda che esistono delle 'blocking deps' tra ciascun ebuild monolitico e le split ebuilds che ne derivano. Portage impedirà automaticamente situazioni non consentite e ti permetterà di eseguire solo operazioni lecite.

Vantaggi degli split ebuilds 

Ecco un breve elenco dei vantaggi che si ottengono passando agli split ebuilds:

• La maggior parte dei pacchetti di KDE non subisce aggiornamenti da una minor release all'altra. Ad esempio, l'aggiornamento dalla versione 3.3.1 alla 3.3.2 ha coinvolto meno di 100 pacchetti su 320. I pacchetti splittati permettono di aggiornare gli ebuilds che sono effettivamente cambiati, facendo risparmiare (in questo caso) più di due terzi del tempo necessario all'aggiornamento.
• Le patch, di solito riguardano un pacchetto specifico. Con gli ebuilds pacchettizzati possono essere testate, approvate e rilasciate più rapidamente impegnando di meno gli sviluppatori: come sopra, l'utente impiegherà meno tempo per gli aggiornamenti. Questo fatto diventa ancora più importante per gli aggiornamenti di sicurezza.
• Chi usa altri ambienti desktop o Window Managers più leggeri può emergere solo le applicazioni di KDE che preferisce senza doversi sobbarcare il carico (piuttosto pesante) di tutto il resto, di kdebase o di kde pim, per esempio.
• È possibile organizzare al meglio l'installazione dei pacchetti. Per diversi motivi:
  • Hai problemi di tempo. emerge kdebase kdepim kdenetwork richiede troppo tempo se tutto quello che ti occorre è konqueror, kmail e kopete. Inoltre, in certi casi il tempo di calcolo... è denaro.
  • Hai problemi di spazio. Ogni pacchetto inutilizzato va a intasare lo spazio tra i settori del tuo disco. Un disco con più spazio disponibile respira meglio: è un disco che corre felice.
  • Hai problemi di sicurezza. Ogni pacchetto installato è una potenziale falla nella sicurezza del sistema e quando i punti deboli si trovano nel software inutilizzato non ci sono scuse.
  • Sei un devoto sostenitore della Filosofia di Gentoo, e non riesci a sopportare che un povero utente sia costretto ad installare contro la propria volontà una serie di pacchetti che magari non userà. (Non lo sopportiamo neanche noi).
• Infine, gli split ebuilds permettono una maggiore flessibilità delle flag USE durante la compilazione.

Integrazione tra split ebuilds ed ebuilds monolitici 

Ebuilds monolitici e splittati possono essere mischiati liberamente. Con una sola restrizione: se un ebuild monolitico dipende da uno split ebuild, questi non possono essere installati contemporaneamente. Per questo motivo gli ebuilds sono vincolati da blocking deps: si può fare solo ciò che emerge permette.

Di solito, però, non c'è ragione di usare una configurazione così variegata. Infatti, si dovrebbero usare soltanto gli split ebuilds ad eccezione di particolari casi di macchine molto lente (mips).

Inoltre gli split ebuilds sono il default. Questo significa che quando un ebuild dipende da un'altra applicazione di KDE, cercherà di installare uno split ebuild. Tuttavia, anche il corrispondente ebuild monolitico soddisferà quella dipendenza, e sarà così possibile emergere manualmente l'ebuild monolitico e quindi l'ebuild che dipende da questa.

2.Questione di prestazioni

Perchè gli split ebuilds sono lenti 

In precedenza è stato detto che gli split ebuilds avrebbero impiegato più tempo negli emerge di quelle monolitici per il carico di lavoro maggiore dovuto all'estrazione e alla configurazione da ripetere per ciascun pacchetto. Un emerge kde-meta completo può richiedere il 20-30% del tempo in più di un classico emerge kde, inaccettabile per una compilazione già di per se lunga.

Non solo. Ora come ora gli split ebuilds eseguono sempre make -f admin/Makefile.cvs (significa che verranno eseguiti autoconf, automake, ecc. e una serie di altri script correlati a KDE). Questo comporta un ulteriore rallentamento, paragonabile all'esecuzione di configure.

Inoltre, uno split ebuild deve estrarre files specifici da un grosso archivio. Questo processo è più lento di quello che servirebbe per decomprimere un piccolo archivio, specifico per l'applicazione. Tuttavia, creare simili archivi per il sistema di compilazione di KDE 3.x, basato sugli autotools, non è affatto semplice.

Vale la pena di ripetere che con gli split ebuilds il tempo di compilazione degli aggiornamenti di KDE sarà notevolmente ridotto, aggiornando solo i pacchetti che sono effettivamente cambiati. I vantaggi di uno solo di questi aggiornamenti ripaga ampiamente del tempo richiesto dalla prima installazione.

Infine, l'installazione completa di KDE ha senso quando si vogliono valutare tutti i pacchetti disponibili o quando si vuole configurare un ambiente multiutente; tuttavia, molte persone usano solo una parte delle 300 e più applicazioni offerte da KDE. Chiunque si preoccupi veramente della durata delle compilazioni, come i possessori di macchine un po' datate, può guadagnare più tempo con l'installazione selettiva dei pacchetti di quanto ne perda per il carico supplementare di lavoro.

Miglioramenti alle prestazioni degli split ebuilds 

La maggior parte, o addirittura la totalità dei problemi di velocità degli split ebuilds, è legata agli autotools - autoconf, automake e altri tools che gestiscono il sistema di compilazione ./configure; make; make install usato in KDE 3.x.

KDE 4 adotterà (per quello che ne sappiamo ora) un sistema di compilazone completamente nuovo, che tra le altre cose ridurrà di molto il tempo che l'equivalente di make -f admin/Makefile.common; ./configure impiegherà.

In passato, confcache era stato considerato un modo per diminuire i disagi causati dall'esecuzione ripetuta degli script configure generati dagli autotools. Confcache è un metodo per memorizzare i risultati dei test di configure. Tuttavia, non vi è ancora alcuna implementazione nell'albero stabile (2.0) del Portage. Anche se fosse aggiunta in futuro, ciò potrebbe non avvenire in tempo per permetterci di utilizzarlo per gli ebuilds KDE; potremmo preferire aspettare KDE 4.

3.Split ebuilds FAQ

Perché alcuni split packages non hanno ebuilds delle ultime versioni? 

Come spiegato sopra, non tutte le applicazioni vengono realmente aggiornate tra releases KDE minori, e quindi non tutte le applicazioni ricevono nuove versioni di ebuild. Per esempio, libkdenetwork non è stato aggiornato nella versione 3.5.0_beta2, quindi l'ultimo ebuild disponibile per quella release è il 3.5_beta1.

Questo viene fatto solo per ridurre il tempo di compilazione durante un aggiornamento. Se avessimo fatto un ebuild libkdenetwork-3.5.0_beta2, esso avrebbe installato esattamente gli stessi files della versione 3.5_beta1. Le varie dipendenze vengono aggiornate per funzionare correttamente (ad esempio nessun ebuild dipenderà da libkdenetwork-3.5.0_beta2).

Esiste già l'opzione DO_NOT_COMPILE: non produce lo stesso effetto? 

DO_NOT_COMPILE è una variabile interna all'ambiente di compilazione di KDE. Permette di scegliere quali sottodirectory non devono essere compilate. Tale funzione viene già utilizzata per compilare solo una parte dell'ebuild monolitico di KDE. Ad esempio con DO_NOT_COMPILE=konqueror emerge kdebase si installa kdebase senza konqueror.

Ad ogni modo, l'uso di DO_NOT_COMPILE non deve interferire con le operazioni di un tool per la gestione automatica dei pacchetti. Non funziona, può portare a problemi di sistema e non è mai stato supportato. Vi raccomandiamo vivamente di non usarlo.

Ecco un elenco incompleto dei problemi causati da DO_NOT_COMPILE:

• Distrugge completamente la gestione delle dipendenze di portage. Portage non è a conoscenza di DO_NOT_COMPILE e pensa che l'intero pacchetto monolitico sia stato installato e che possa soddisfare le dipendenze di altri pacchetti. Di conseguenza avremo problemi con la compilazione, via emerge, di altri pacchetti o il loro mancato funzionamento.
• Costringe l'utente a conoscere il nome e il significato di tutte le sottodirectory dei moduli di KDE. Pochi sono in grado di farlo, a meno che non siano sviluppatori di KDE: per questo è quasi impossibile fare un uso corretto di DO_NOT_COMPILE.
• Le sottodirectory dei moduli di KDE possono dipendere l'una dall'altra, possono richiedere un ordine di compilazione ben preciso, possono richiedere la presenza di un altra directory magari non effettivamente installata, e così via. Abbiamo fatto un gran lavoro per rendere gli split ebuild funzionanti. DO_NOT_COMPILE non raggiunge gli stessi risultati, neanche la sufficiente conoscenza da parte dell'utente. Tutto quello che puoi ottenere con questo metodo è di evitare di compilare solo una piccola parte delle applicazioni. È praticamente impossibile usarlo per installare solo kdebase e kdepim, per esempio.
• Se ieri ho installato kmail e oggi voglio installare korn, usando DO_NOT_COMPILE sarò comunque costretto a ricompilare kmail. Questo significa che DO_NOT_COMPILE resta comunque meno prestante degli split ebuilds.
• DO_NOT_COMPILE non può essere usato per creare pacchetti precompilati (come GRP) che contengono singole applicazioni di KDE.

Non state caricando troppo i mantainer KDE di Gentoo? 

È sorprendente vedere quanti pongano questa domanda. Sono felice che gli utenti ci tengano così in considerazione. Colgo l'occasione per assicurarvi che ci stiamo occupando degli split ebuilds per nostra libera scelta, che pensiamo di essere in grado di continuare a migliorarli e che non c'è alcuna possibilità di dissuaderci :-)

Per la verità c'è da dire che i mantainer delle altre architetture si sono lamentati per l'aumento del lavoro di test dovuto a così tanti ebuilds separati. Stiamo lavorando per risolvere questo problema e questo è il motivo principale per cui gli ebuilds monolitici saranno ancora disponibili per KDE 3.4.

Avete intenzione di eliminare gli ebuilds vecchio stile (quelli monolitici)? 

È nostra intenzione, ma più avanti. Comunque, ci saranno split ebuilds e ebuilds monolitici per tutte le versioni 3.x di KDE.

Se preferisci gli ebuilds monolitici a quelli splittati, per favore facci sapere il motivo.

Ci sono troppi ebuilds! Come faccio a trovare quello che mi serve? 

Prima di tutto, nel momento in cui il pacchetto che stai cercando fa parte di kdebase, puoi ancora eseguire emerge kdebase-meta, con lo stesso risultato di kdebase monolitico. In realtà le cose non sono peggiorate a causa degli split ebuilds.

Naturalmente tutti i metodi tradizionali per individuare un pacchetto restano validi. Come avresti trovato il tuo ebuild se avesse fatto parte di Gnome? Come minimo avresti dovuto conoscerne il nome.

Forse la situazione potrebbe essere migliorata introducendo più -meta ebuilds. Sono soltanto liste di dipendenze, e non ci costerebbe nulla. Questo non è ancora stato deciso. Inoltre, sarebbe meglio avere la funzionalità delle impostazioni di Portage prima che sia reso estensivo.

Come posso elencare oppure eseguire l'unmerge di tutti gli split ebuilds che derivano da un determinato pacchetto? 

L'obiettivo è elencare tutti gli split ebuilds di KDE che derivano, diciamo, dall'ebuild monolitico kdebase. L'implementazione più corretta (come GLEP 21) può essere banale. Tuttavia potresti essere in qualche modo ferrato sull'implementazione delle eclasses di KDE, così, se per caso utilizzi uno di questi approcci in qualche script che non sia per uso privato, faccelo sapere.

kde-functions.eclass definisce delle funzioni chiamate get-parent-package() e get-child-packages(); saranno loro ad eseguire il lavoro al posto tuo. Queste due funzioni sono il modo corretto per eseguire quanto detto prima a partire da una ebuild o da uno script bash esterno. Ecco un esempio:

$ function die() { echo $@; } # invocato per riportare eventuali errori
$ source /usr/portage/eclass/kde-functions.eclass
$ get-parent-package konqueror # così non funziona: devi specificare il nome
completo
Package konqueror not found in KDE_DERIVATION_MAP, please report bug #
l'errore viene riportato
$ get-parent-package kde-base/konqueror # il nome è stato indicato
correttamente
kde-base/kdebase # viene riportato il risultato
$ get-child-packages kde-base/kdebase
 # (segue l'elenco dei pacchetti)

Se non stai usando uno script bash, puoi passare kde-functions.eclasses a grep per estrarre la definizione (multilinea) della variabile KDE_DERIVATION_MAP, usata dalla funzione di cui sopra. Questa variabile contiene una lista di parole separate da spazi: ogni coppia di parole lega un pacchetto padre allo split ebuild figlio.