Attachment 70377 Details for Bug 108888 – kde-split-ebuilds.xml

kde-split-ebuilds.xml

kde-split-ebuilds.xml (text/plain), 18.91 KB, created by Massimo C. on 2005-10-11 09:34:51 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Massimo C.

Created: 2005-10-11 09:34:51 UTC

Size: 18.91 KB

patch

obsolete

><?xml version='1.0' encoding='UTF-8'?>
>
>
>
><!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
>
><guide link="/doc/it/kde-split-ebuilds.xml" lang="it">
>
><title>Guida agli Split Ebuilds di KDE</title>
>
><author title="Autore">
>  <mail link="danarmak@gentoo.org">Dan Armak</mail>
></author>
><author title="Traduttore">
>  <mail link="posta@massimo.biz">Massimo Canali</mail>
></author>
>
><abstract>
>Con KDE 3.4 sono stati introdotti in Portage gli 'split ebuilds'. Questa
>quida spiega i motivi di questo cambiamento, le nuove caratteristiche
>introdotte e come migrare dalla vecchia configurazione monolitica.
></abstract>
>
>
>
><license/>
>
><version>1.5</version>
><date>2005-07-02</date>
>
><chapter>
><title>Gli Split Ebuilds di KDE</title>
><section>
><title>Di cosa si tratta?</title>
><body>
>
><p>
>Fino a Gennaio 2005 gli unici ebuilds di KDE disponibili in Portage erano quelli
>'monolitici'. Come dire, 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.
></p>
>
><p>
>I nuovi split-ebuilds (ebuilds pacchettizzati) 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.
></p>
>
><p>
>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.
></p>
>
><p>
>Infine, segnaliamo che esistono split ebuilds anche per Koffice che mettono
>a disposizione kword, kugar ecc. come pacchetti separati.
></p>
>
></body>
></section>
><section>
><title>Installare gli split-ebuild</title>
><body>
>
><p>
>L'ultima versione stabile di KDE disponibile alla stesura di questo documento
>Ã¨ la 3.4.1. Portage offre entrambe le opportunitÃ  di installazione, splittata
>(pacchettizzata) e monolitica.
></p>
>
><ul>
>  <li>
>    Per emergere un particolare pacchetto, diciamo kmail, Ã¨ sufficiente
>    eseguire <c>emerge kmail</c>.
>  </li>
>  <li>
>    Per emergere l'ambiente base di KDE, che consente il login a una sessione
>    minimale, <c>emerge kdebase-startkde</c>.
>  </li>
>  <li>
>    Infine, per ottenere lo stesso effetto di uno dei pacchetti monolitici
>    usando gli split ebuilds - diciamo, per avere tutte le applicazioni
>    incluse in <c>kdebase</c> - eseguire <c>emerge kdebase-meta</c> (oppure
>    kdepim-meta, ecc.). Per ottenere tutti gli split ebuilds di KDE, eseguire
>    <c>emerge kde-meta</c>.
>  </li>
></ul>
>
><section>
><title>Migrare dalla versione monolitica alla versione pacchettizata</title>
><body>
>
><p>
>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 <c>emerge kde-meta</c>.
></p>
>
><p>
>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.
></p>
>
><p>
>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.
></p>
>
></body>
></section>
><section>
><title>Vantaggi degli split ebuilds</title>
><body>
>
><p>
>Ecco un breve elenco dei vantaggi che si ottengono passando agli split ebuilds:
></p>
>
><ul>
>  <li>
>    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.
>  </li>
>  <li>
>    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.
>  </li>
>  <li>
>    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.
>  </li>
>  <li>
>    Ã possibile organizzare al meglio l'installazione dei pacchetti. Per diversi
>    motivi:
>
>    <ul>
>      <li>
>        Hai problemi di tempo. <c>emerge kdebase kdepim kdenetwork</c> richiede
>        troppo tempo se tutto quello che ti occorre Ã¨ konqueror, kmail e kopete.
>        Inoltre, in certi casi il tempo di calcolo... Ã¨ denaro.
>      </li>
>      <li>
>        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.
>      </li>
>      <li>
>        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.
>      </li>
>      <li>
>        Sei un devoto sostenitore della
>        <uri link="/main/en/philosophy.xml">Filosofia di
>        Gentoo</uri>, 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).
>      </li>
>    </ul>
>  </li>
>  <li>
>    Infine, gli split ebuilds permettono una maggiore flessibilitÃ  delle flag
>    USE durante la compilazione.
>  </li>
></ul>
>
></body>
></section>
><section>
><title>Integrazione tra split ebuilds ed ebuilds monolitici</title>
><body>
>
><p>
>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.
></p>
>
><p>
>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).
></p>
>
><p>
>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.
></p>
>
></body>
></section>
></chapter>
>
><chapter>
><title>Questione di prestazioni</title>
><section>
><title>PerchÃ¨ gli split ebuilds sono lenti</title>
><body>
>
><p>
>In precedenza Ã¨ stato
><uri link="http://bugs.gentoo.org/show_bug.cgi?id=11123">detto</uri>
>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 <c>emerge kde-meta</c> completo puÃ² richiedere il 20-30% del tempo
>in piÃ¹ di un classico <c>emerge kde</c>, inaccettabile per una compilazione giï¿½di per se lunga.
></p>
>
><p>
>Non solo. Ora come ora gli split ebuilds eseguono sempre <c>make -f
>admin/Makefile.cvs</c> (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.
></p>
>
><p>
>Tenuto conto di questo, l'analisi appare deprimente. Comunque, nelle prossime
>sezioni verranno esposti diversi fattori che compensano in una certa misura
>questo rallentamento.
></p>
>
><p>
>Vale la pena di ripetere che con gli split ebuilds gli aggiornamenti di KDE
>dimezzeranno il tempo di compilazione - in alcuni casi lo ridurranno di dieci
>volte se non di piÃ¹ - aggiornando solo i pacchetti che sono effettivamente
>cambiati. I vantaggi di uno solo di questi aggiornamenti ripaga ampiamente del
>tempo richiesto dalla prima installazione.
></p>
>
><p>
>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.
></p>
>
></body>
></section>
><section>
><title>Miglioramenti alle prestazioni degli split ebuilds</title>
><body>
>
><p>
>Il miglioramento piÃ¹ ovvio sarÃ  quello di distribuire tarballs separati per ogni
>split ebuild invece di pezzi dei tarballs monolitici (kdebase, ecc.).
>Questo eliminerebbe due dei tre fattori di rallentamento: l'estrazione ripetuta
>dei tarballs e la rigenerazione dei makefile (la fase con <c>make -f
>admin/Makefile.cvs</c> di cui si parlava).
></p>
>
><p>
>Restiamo perÃ² con il problema delle esecuzioni ripetute di configure. La
>soluzione piÃ¹ appropriata Ã¨ confcache: una cache per configure condivisa tra le
>esecuzioni di emerge. Esiste giÃ  una implementazione in portage (il tool,
>non il package tree) in fase di sviluppo; una versione stabile con confcache
>potrebbe essere rilasciata tra sei mesi o giÃ¹ di lÃ¬.
></p>
>
></body>
></section>
><section>
><title>Altri fattori che possono compensare la lentezza degli split ebuilds</title>
><body>
>
><p>
>Nella sezione precedente abbiamo parlato dei metodi per migliorare le prestazioni
>degli split ebuilds. Ora parleremo brevemente di alcuni miglioramenti futuri
>applicabili anche agli ebuilds monolitici. Questi miglioramenti aiutano a
>rendere gli split ebuilds 'sufficientemente veloci' a prescindere da soluzioni
>con caratteristiche meno interessanti come gli ebuilds monolitici.
></p>
>
><ul>
>  <li>
>    KDE 4.0 dovrebbe essere in grado di usare <uri
>    link="http://www.kde.me.uk/index.php?page=unsermake">unsermake</uri> invece
>    di automake, il che, in alcune circostanze, migliora le prestazioni della
>    compilazione; piÃ¹ avanti, anche gli ebuilds di KDE 3.4 potrebbero usare
>    unsermake.
>  </li>
>  <li>
>    Gli split ebuilds supportano la flag USE kdexdeltas, che permette di
>    scaricare soltanto le differenze tra due versioni risparmiando sull'utilizzo
>    di banda.
>  </li>
>  <li>
>    Le prestazioni di tutti gli altri tools coinvolti nel processo di
>    compilazione migliorano col tempo, oppure sfruttano varie
>    caratteristiche correlate a KDE che migliorano le prestazioni. Due esempi
>    recenti sono visibility=hidden (GCC 3.4) e gli headers precompilati
>    (GCC 4.0). Certo, non dipendono direttamente dal passaggio agli split
>    ebuilds ma ci consentiranno di affrontare compilazioni che richiedono
>    una maggiore potenza di calcolo.
>  </li>
></ul>
>
></body>
></section>
></chapter>
>
><chapter>
><title>FAQ</title>
><section>
>
><title>Esiste giÃ  l'opzione DO_NOT_COMPILE: non produce lo stesso effetto?</title>
><body>
>
><p>
>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 <c>DO_NOT_COMPILE=konqueror emerge kdebase</c>
>si installa kdebase senza konqueror.
></p>
>
><p>
>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.
></p>
>
><p>
>Ecco un elenco incompleto dei problemi causati da DO_NOT_COMPILE:
></p>
>
><ul>
>  <li>
>    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.
>  </li>
>  <li>
>    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.
>  </li>
>  <li>
>    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.
>  </li>
>  <li>
>    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.
>  </li>
>  <li>
>    DO_NOT_COMPILE non puÃ² essere usato per creare pacchetti precompilati (come
>    GRP) che contengono singole applicazioni di KDE.
>    </li>
></ul>
>
></body>
></section>
>
><section>
><title>Non state caricando troppo i mantainer KDE di Gentoo?</title>
><body>
>
><p>
>Ã 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 :-)
></p>
>
><p>
>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.
></p>
>
></body>
></section>
><section>
><title>Avete intenzione di eliminare gli ebuilds vecchio stile (quelli
>monolitici)?</title>
><body>
>
><p>
>Ã nostra intenzione, ma piÃ¹ avanti. Comunque, ci saranno split ebuilds e ebuilds
>monolitici per tutte le versioni 3.4 di KDE.
></p>
>
><p>
>Se preferisci gli ebuilds monolitici a quelli splittati, per favore
><uri link="http://bugs.gentoo.org">facci sapere</uri> il motivo.
></p>
>
></body>
></section>
><section>
><title>Ci sono troppi ebuilds! Come faccio a trovare quello che mi serve?</title>
><body>
>
><p>
>Prima di tutto, nel momento in cui il pacchetto che stai cercando fa
>parte di kdebase, puoi ancora eseguire <c>emerge kdebase-meta</c>, con lo stesso
>risultato di <c>kdebase</c> monolitico. In realtÃ  le cose non sono peggiorate a
>causa degli split ebuilds.
></p>
>
><p>
>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.
></p>
>
><p>
>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.
></p>
>
></body>
></section>
><section>
><title>Come posso eseguire l'unmerge di un vecchio KDE?</title>
><body>
>
><p>
>Supponi che venga rilasciato KDE 4.0 e che tu voglia eseguire l'unmerge di KDE
>3.4. Siccome appartengono a slot differenti, emerge non lo potrÃ  fare, cosÃ¬ Ã¨
>necessario trovare un altro metodo.
></p>
>
><p>
>Una soluzione appropriata a questo problema richiede modifiche a portage. Un
>esempio si puÃ² trovare in
><uri link="http://www.gentoo.org/proj/en/glep/glep-0021.html">GLEP 21</uri>.
>Comunque, finchÃ¨ tali modifiche non saranno presenti, dovremo usare script come
>quello indicato piÃ¹ avanti.
></p>
>
>
><p>
>Fortunatamente tutti gli ebuilds di KDE appartengono alla directory kde-base (e
>tutti gli ebuilds nella categoria kde-base provengono da kde.org). CosÃ¬ Ã¨
>possibile usare il codice che segue:
></p>
>
><pre caption="Rimuovere KDE 3.4 dal sistema">
># <i>for x in `ls /usr/portage/kde-base`; do</i>
>> <i>if [ "$x" != "CVS" ]; then</i>
>> <i>echo -n "=kde-base/$x-3.4* "</i>
>> <i>fi</i>
>> <i>done |xargs emerge -Cp</i>
></pre>
>
><p>
>PuÃ² sembrare un hack ma in fin dei conti non lo Ã¨ visto che tutto ciÃ² che ci
>occorre Ã¨ una lista delle ebuilds di kde-base. Non Ã¨ una cosa difficile da fare,
>cosÃ¬ ci sarÃ  sempre un modo semplice per riuscirci.
></p>
>
></body>
></section>
><section>
><title>Come posso elencare oppure eseguire l'unmerge di tutti gli split ebuilds
>che derivano da un determinato pacchetto?</title>
><body>
>
><p>
>L'obiettivo Ã¨ elencare tutti gli split ebuilds di KDE che derivano, diciamo,
>dall'ebuild monolitico kdebase. L'implementazione piÃ¹ corretta (come <uri
>link="http://www.gentoo.org/proj/en/glep/glep-0021.html">GLEP 21</uri>) 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.
></p>
>
><p>
>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:
></p>
>
><pre caption="Esempio d'uso delle funzioni kde-functions">
>$ <i>function die() { echo $@; } # invocato per riportare eventuali errori</i>
>$ <i>source /usr/portage/eclass/kde-functions.eclass</i>
>$ <i>get-parent-package konqueror # cosÃ¬ non funziona: devi specificare il nome
>completo</i>
><i>Package konqueror not found in KDE_DERIVATION_MAP, please report bug #
>l'errore viene riportato</i>
>$ <i>get-parent-package kde-base/konqueror # il nome Ã¨ stato indicato
>correttamente</i>
><i>kde-base/kdebase # viene riportato il risultato</i>
>$ <i>get-child-packages kde-base/kdebase</i>
><i> # (segue l'elenco dei pacchetti)</i>
></pre>
>
><p>
>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.
></p>
>
></body>
></section>
></chapter>
></guide>

Actions: View

Attachments on bug 108888: 70377