Go to:
Gentoo Home
Documentation
Forums
Lists
Bugs
Planet
Store
Wiki
Get Gentoo!
Gentoo's Bugzilla – Attachment 70377 Details for
Bug 108888
[it] translated kde-split-ebuilds.xml
Home
|
New
–
[Ex]
|
Browse
|
Search
|
Privacy Policy
|
[?]
|
Reports
|
Requests
|
Help
|
New Account
|
Log In
[x]
|
Forgot Password
Login:
[x]
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:
kde-split-ebuilds.xml
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'?> > ><!-- $Header: /var/www/www.gentoo.org/raw_cvs/gentoo/xml/htdocs/doc/it/kde-split-ebuilds.xml,v 1.3 2005/05/04 21:53:00 so Exp $ --> > ><!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> > ><!-- The content of this document is licensed under the CC-BY-SA license --> ><!-- See http://creativecommons.org/licenses/by-sa/2.5 --> ><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>
You cannot view the attachment while viewing its details because your browser does not support IFRAMEs.
View the attachment on a separate page
.
View Attachment As Raw
Actions:
View
Attachments on
bug 108888
: 70377