Guida agli Ebuild "split" (suddivisi) di KDE

1.  Gli Ebuild 'suddivisi' di KDE

Di cosa si tratta?

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

I nuovi ebuild 'split' (ndT. di seguito definiti 'suddivisi') (per konqueror, kmail, ...) hanno rimediato a questa situazione introducendo gli ebuild per le singole applicazioni di KDE. Questo porta gli ebuild della categoria kde-base ad un totale di 330.

Gli ebuild monolitici di KDE sono ancora disponibili per la versione 3.5 di KDE (fino alla versione 3.5.9) e possono interagire in maniera trasparente con quelli suddivisi. Tuttavia quest'ultimi sono il nuovo standard e dopo KDE 3.5.9 quelli monolitici non saranno più disponibili.

Infine, si segnala che esistono gli ebuild suddivisi anche per Koffice, i quali mettono a disposizione kword, kugar, ecc. come pacchetti separati.

Installare gli ebuild suddivisi

L'ultima versione stabile di KDE disponibile alla stesura di questo documento è la 3.5.9. L'ultima instabile (~arch) è la 3.5.10. Portage offre entrambe le opportunità di installazione, suddivisa e monolitica. Anche la versione 4.1.x è presente nell'albero di portage.

• Per installare un particolare pacchetto, per esempio kmail, è sufficiente eseguire emerge kmail.
• Per installare 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 ebuild suddivisi - per esempio, per avere tutte le applicazioni incluse in kdebase - eseguire emerge kdebase-meta (oppure kdepim-meta, ecc.). Per ottenere tutti gli ebuild suddivisi di KDE, eseguire emerge kde-meta.

Migrare dagli ebuild monolitici a quelli suddivisi

Se è installata la versione 3.4.x o 3.5.x. monolitica bisogna prima rimuoverla per poi installare gli ebuild suddivisi desiderati. Il processo di rimozione/installazione può essere eseguito per ciascuno degli ebuild monolitici; non è necessario rimuovere KDE in blocco.

Nel dubbio, ricordarsi che esistono delle dipendenze bloccanti tra ciascun ebuild monolitico e gli ebuild suddivisi che ne derivano. Portage impedirà automaticamente situazioni non consentite e permetterà di eseguire solo operazioni lecite.

Vantaggi degli ebuild suddivisi

Ecco un breve elenco dei vantaggi che si ottengono passando agli ebuild suddivisi:

• La maggior parte dei pacchetti di KDE non subisce aggiornamenti da un rilascio minore all'altro. Ad esempio, l'aggiornamento dalla versione 3.3.1 alla 3.3.2 ha coinvolto meno di 100 pacchetti su 320. I pacchetti suddivisi permettono di aggiornare gli ebuild che sono effettivamente cambiati, facendo risparmiare (in questo caso) più di due terzi del tempo necessario all'aggiornamento.
• Le patch solitamente riguardano un pacchetto specifico. Con gli ebuild suddivisi esse possono essere testate, approvate e rilasciate più rapidamente impegnando di meno gli sviluppatori: come accennato in precedenza, 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ò installare solo le applicazioni di KDE che preferisce senza doversi sobbarcare il carico (piuttosto pesante) di tutto il resto, di kdebase o di kdepim, per esempio.
• È possibile organizzare al meglio l'installazione dei pacchetti. Per diversi motivi:
  • Problemi di tempo. emerge kdebase kdepim kdenetwork richiede troppo tempo se tutto quello che occorre è konqueror, kmail e kopete. Inoltre, in certi casi il tempo di calcolo della CPU è denaro.
  • Problemi di spazio. Ogni pacchetto inutilizzato va a intasare lo spazio tra i settori del proprio disco. Un disco con più spazio disponibile respira meglio: è un disco che corre felice.
  • 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.
  • Si è devoti sostenitori della Filosofia di Gentoo, e non si riesce a sopportare che un povero utente sia costretto ad installare contro la propria volontà una serie di pacchetti che magari non userà. (Non lo sopportano neanche gli sviluppatori Gentoo).
• Infine, gli ebuild suddivisi permettono una maggiore flessibilità delle flag USE durante la compilazione.

Integrazione tra ebuild suddivisi ed ebuild monolitici

Ebuild monolitici e suddivisi possono essere mischiati liberamente. Con una sola restrizione: un ebuild monolitico ed uno suddiviso derivante da esso non possono essere installati contemporaneamente. Per questo motivo gli ebuild sono vincolati da dipendenze bloccanti: 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 ebuild suddivisi ad eccezione di particolari casi di macchine molto lente (mips).

Inoltre gli ebuild suddivisi sono quelli predefiniti. Questo significa che quando un ebuild dipende da un'altra applicazione di KDE, cercherà di installare uno ebuild suddiviso. Tuttavia, anche il corrispondente ebuild monolitico soddisferà quella dipendenza, e sarà così possibile installare manualmente l'ebuild monolitico e quindi l'ebuild che dipende da esso.

2.  Questione di prestazioni

Perchè gli ebuild suddivisi sono lenti

In precedenza è stato detto che gli ebuild suddivisi avrebbero impiegato più tempo degli 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 ebuild suddivisi 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 ebuild suddiviso deve estrarre file 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 ebuild suddivisi 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 ebuild suddivisi

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

KDE 4 ha adottato un sistema di compilazione completamente nuovo, cmake, che tra le altre cose riduce di molto il tempo impiegato dal del comando equivalente make -f admin/Makefile.common; ./configure.

3.  Domande frequenti per gli ebuild suddivisi

Perché alcuni pacchetti suddivisi non hanno ebuild delle ultime versioni?

Come spiegato in precedenza, non tutte le applicazioni vengono realmente aggiornate tra rilasci minori di KDE, 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 fosse stato fatto fatto un ebuild libkdenetwork-3.5.0_beta2, esso avrebbe installato esattamente gli stessi file della versione 3.5_beta1. Le varie dipendenze vengono aggiornate per funzionare correttamente (ad esempio nessun ebuild dipenderà da libkdenetwork-3.5.0_beta2).

Notare che, di conseguenza, se si vuole installare una versione mascherata di KDE, bisognerà anche smascherare i pacchetti da una versione precedente di KDE, se a loro volta sono mascherati. È consigliabile leggere questo bug per maggiori dettagli.

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 uno strumento per la gestione automatica dei pacchetti. Non funziona, può portare a problemi di sistema e non è mai stato supportato. Si raccomanda vivamente di non usarlo.

Ecco un elenco incompleto dei problemi causati da DO_NOT_COMPILE:

• Rovina 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. Ciò causerà il fallimento dell'installazione o dell'esecuzione di altri pacchetti.
• 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. È stato fatto un gran lavoro per rendere funzionanti gli ebuild suddivisi. DO_NOT_COMPILE non raggiunge gli stessi risultati, neanche con una sufficiente conoscenza da parte dell'utente. Tutto quello che si può 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 è stato installato kmail e oggi si vuole installare korn, usando DO_NOT_COMPILE si sarà comunque costretti a ricompilare kmail. Questo significa che DO_NOT_COMPILE resta comunque meno prestante degli ebuild suddivisi.
• DO_NOT_COMPILE non può essere usato per creare pacchetti precompilati (come GRP) che contengono singole applicazioni di KDE.

Non si stanno caricando troppo i mantenitori KDE di Gentoo?

È sorprendente vedere quanti pongano questa domanda. Gli sviluppatori sono felici che gli utenti li tengano così in considerazione. Si coglie l'occasione per assicurare quest'ultimi che gli sviluppatori si stanno occupando degli ebuild suddivisi per libera scelta, e che pensano di essere in grado di continuare a migliorarli, senza alcuna possibilità di essere dissuasi :-)

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

C'è l'intenzione di eliminare gli ebuild vecchio stile (quelli monolitici)?

Gli sviluppatori sono intenzionati a farlo, ma più avanti. Comunque, ci saranno ebuild suddivisi e ebuild monolitici per tutte le versioni 3.x di KDE fino alla 3.5.9. Per KDE 3.5.10 e versioni successive, e per KDE4, non verranno più forniti ebuild monolitici.

Se si preferiscono gli ebuild monolitici a quelli suddivisi, si prega di far sapere il motivo ai rispettivi sviluppatori.

Ci sono troppi ebuild! Come si può trovare quello di cui si ha bisogno?

Prima di tutto, nel momento in cui il pacchetto che si sta cercando fa parte di kdebase, è ancora possibile eseguire emerge kdebase-meta, con lo stesso risultato di kdebase monolitico. In realtà le cose non sono peggiorate a causa degli ebuild suddivisi.

Naturalmente tutti i metodi tradizionali per individuare un pacchetto restano validi. Come trovare il proprio ebuild facente parte di Gnome? Come minimo bisognerebbe conoscerne il nome.

Forse la situazione potrebbe essere migliorata introducendo più ebuild -meta. Sono soltanto liste di dipendenze, e non costerebbe nulla. Questo non è ancora stato deciso. Inoltre, sarebbe meglio avere la funzionalità "sets" (insiemi) in Portage prima che sia reso estensivo.

Come si può elencare oppure eseguire l'unmerge di tutti gli ebuild suddivisi che derivano da un determinato pacchetto?

L'obiettivo è elencare tutti gli ebuild suddivisi di KDE che derivano, per esempio, dall'ebuild monolitico kdebase. L'implementazione più corretta (come GLEP 21) può essere banale. Tuttavia bisognerebbe essere in qualche modo a conoscenza dell'implementazione delle eclass di KDE, così, se per caso si utilizza uno di questi approcci in qualche script che non sia per uso privato, farlo sapere agli sviluppatori.

kde-functions.eclass definisce delle funzioni chiamate get-parent-package() e get-child-packages(); saranno loro ad eseguire il lavoro al proprio posto. 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: bisogna 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 si sta usando uno script bash, è possibile passare kde-functions.eclasses a grep per estrarre la definizione (multilinea) della variabile KDE_DERIVATION_MAP, usata dalla funzione summenzionata. Questa variabile contiene una lista di parole separate da spazi: ogni coppia di parole lega un pacchetto padre all'ebuild suddiviso figlio.

I contenuti di questo documento sono rilasciati sotto la licenza Creative Commons - Attribution / Share Alike.