| 1 |
scen 08/05/01 13:15:59 |
| 2 |
|
| 3 |
Modified: kde-split-ebuilds.xml |
| 4 |
Log: |
| 5 |
Version 2, revision 1.16 of EN CVS |
| 6 |
|
| 7 |
Revision Changes Path |
| 8 |
1.11 xml/htdocs/doc/it/kde-split-ebuilds.xml |
| 9 |
|
| 10 |
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/it/kde-split-ebuilds.xml?rev=1.11&view=markup |
| 11 |
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/it/kde-split-ebuilds.xml?rev=1.11&content-type=text/plain |
| 12 |
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/it/kde-split-ebuilds.xml?r1=1.10&r2=1.11 |
| 13 |
|
| 14 |
Index: kde-split-ebuilds.xml |
| 15 |
=================================================================== |
| 16 |
RCS file: /var/cvsroot/gentoo/xml/htdocs/doc/it/kde-split-ebuilds.xml,v |
| 17 |
retrieving revision 1.10 |
| 18 |
retrieving revision 1.11 |
| 19 |
diff -u -r1.10 -r1.11 |
| 20 |
--- kde-split-ebuilds.xml 17 Jan 2008 23:44:36 -0000 1.10 |
| 21 |
+++ kde-split-ebuilds.xml 1 May 2008 13:15:59 -0000 1.11 |
| 22 |
@@ -1,8 +1,8 @@ |
| 23 |
<?xml version='1.0' encoding='UTF-8'?> |
| 24 |
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> |
| 25 |
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/it/kde-split-ebuilds.xml,v 1.10 2008/01/17 23:44:36 scen Exp $ --> |
| 26 |
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/it/kde-split-ebuilds.xml,v 1.11 2008/05/01 13:15:59 scen Exp $ --> |
| 27 |
|
| 28 |
-<guide link="/doc/it/kde-split-ebuilds.xml" lang="it"> |
| 29 |
+<guide redirect="/proj/it/desktop/kde/kde-split-ebuilds.xml" lang="it"> |
| 30 |
<title>Guida agli Ebuild "split" (suddivisi) di KDE</title> |
| 31 |
|
| 32 |
<author title="Autore"> |
| 33 |
@@ -31,462 +31,17 @@ |
| 34 |
<!-- See http://creativecommons.org/licenses/by-sa/2.5 --> |
| 35 |
<license/> |
| 36 |
|
| 37 |
-<version>1.11</version> |
| 38 |
-<date>2008-01-16</date> |
| 39 |
+<version>2</version> |
| 40 |
+<date>2008-04-26</date> |
| 41 |
|
| 42 |
<chapter> |
| 43 |
-<title>Gli Ebuild 'suddivisi' di KDE</title> |
| 44 |
+<title>Documento spostato</title> |
| 45 |
<section> |
| 46 |
-<title>Di cosa si tratta?</title> |
| 47 |
<body> |
| 48 |
|
| 49 |
<p> |
| 50 |
-Fino a Gennaio 2005 gli unici ebuild di KDE disponibili in Portage erano quelli |
| 51 |
-'monolitici'. Questo significa che c'erano solo 15 ebuild (<c>kdebase</c>, |
| 52 |
-<c>kdenetwork</c>, ...) e ciascuno installava diverse applicazioni che, di |
| 53 |
-fatto, non dipendevano l'una dall'altra. Questa era una situazione non |
| 54 |
-esattamente ottimale, e non in stile Gentoo, ma accettata per diverso tempo. |
| 55 |
-</p> |
| 56 |
- |
| 57 |
-<p> |
| 58 |
-I nuovi ebuild 'split' (ndT. di seguito definiti 'suddivisi') (per |
| 59 |
-<c>konqueror</c>, <c>kmail</c>, ...) hanno rimediato a questa situazione |
| 60 |
-introducendo gli ebuild per le singole applicazioni di KDE. Questo porta gli |
| 61 |
-ebuild della categoria kde-base ad un totale di 330. |
| 62 |
-</p> |
| 63 |
- |
| 64 |
-<p> |
| 65 |
-Gli ebuild monolitici di KDE sono ancora disponibili per la versione 3.5 di KDE |
| 66 |
-e possono interagire in maniera trasparente con quelli suddivisi. Tuttavia |
| 67 |
-quest'ultimi sono il nuovo standard e dopo KDE 4.0 quelli monolitici non |
| 68 |
-saranno più disponibili. |
| 69 |
-</p> |
| 70 |
- |
| 71 |
-<p> |
| 72 |
-Infine, si segnala che esistono gli ebuild suddivisi anche per Koffice, i quali |
| 73 |
-mettono a disposizione <c>kword</c>, <c>kugar</c>, ecc. come pacchetti separati. |
| 74 |
-</p> |
| 75 |
- |
| 76 |
-</body> |
| 77 |
-</section> |
| 78 |
-<section> |
| 79 |
-<title>Installare gli ebuild suddivisi</title> |
| 80 |
-<body> |
| 81 |
- |
| 82 |
-<p> |
| 83 |
-L'ultima versione stabile di KDE disponibile alla stesura di questo documento è |
| 84 |
-la 3.5.7. L'ultima instabile (~arch) è la 3.5.8. Portage offre entrambe le |
| 85 |
-opportunità di installazione, suddivisa e monolitica. La versione 4.0.0 entrerà |
| 86 |
-a breve nell'albero di portage in stato "hardmasked". |
| 87 |
-</p> |
| 88 |
- |
| 89 |
-<ul> |
| 90 |
- <li> |
| 91 |
- Per installare un particolare pacchetto, per esempio kmail, è sufficiente |
| 92 |
- eseguire <c>emerge kmail</c>. |
| 93 |
- </li> |
| 94 |
- <li> |
| 95 |
- Per installare l'ambiente base di KDE, che consente il login a una sessione |
| 96 |
- minimale, <c>emerge kdebase-startkde</c>. |
| 97 |
- </li> |
| 98 |
- <li> |
| 99 |
- Infine, per ottenere lo stesso effetto di uno dei pacchetti monolitici |
| 100 |
- usando gli ebuild suddivisi - per esempio, per avere tutte le applicazioni |
| 101 |
- incluse in <c>kdebase</c> - eseguire <c>emerge kdebase-meta</c> (oppure |
| 102 |
- <c>kdepim-meta</c>, ecc.). Per ottenere tutti gli ebuild suddivisi di KDE, |
| 103 |
- eseguire <c>emerge kde-meta</c>. |
| 104 |
- </li> |
| 105 |
-</ul> |
| 106 |
- |
| 107 |
-</body> |
| 108 |
-</section> |
| 109 |
-<section> |
| 110 |
-<title>Migrare dagli ebuild monolitici a quelli suddivisi</title> |
| 111 |
-<body> |
| 112 |
- |
| 113 |
-<p> |
| 114 |
-Se è installata la versione 3.3.x di KDE, è possibile installare gli ebuild |
| 115 |
-suddivisi della versione 3.5.x senza interferire con l'installazione esistente |
| 116 |
-mediante <c>emerge kde-meta</c>. |
| 117 |
-</p> |
| 118 |
- |
| 119 |
-<p> |
| 120 |
-Se invece è installata la versione 3.4.x o 3.5.x. monolitica bisogna prima |
| 121 |
-rimuoverla per poi installare gli ebuild suddivisi desiderati. Il processo di |
| 122 |
-rimozione/installazione può essere eseguito per ciascuno degli ebuild |
| 123 |
-monolitici; non è necessario rimuovere KDE in blocco. |
| 124 |
-</p> |
| 125 |
- |
| 126 |
-<p> |
| 127 |
-Nel dubbio, ricordarsi che esistono delle dipendenze bloccanti tra ciascun |
| 128 |
-ebuild monolitico e gli ebuild suddivisi che ne derivano. Portage impedirà |
| 129 |
-automaticamente situazioni non consentite e permetterà di eseguire solo |
| 130 |
-operazioni lecite. |
| 131 |
-</p> |
| 132 |
- |
| 133 |
-</body> |
| 134 |
-</section> |
| 135 |
-<section> |
| 136 |
-<title>Vantaggi degli ebuild suddivisi</title> |
| 137 |
-<body> |
| 138 |
- |
| 139 |
-<p> |
| 140 |
-Ecco un breve elenco dei vantaggi che si ottengono passando agli ebuild |
| 141 |
-suddivisi: |
| 142 |
-</p> |
| 143 |
- |
| 144 |
-<ul> |
| 145 |
- <li> |
| 146 |
- La maggior parte dei pacchetti di KDE non subisce aggiornamenti da un |
| 147 |
- rilascio minore all'altro. Ad esempio, l'aggiornamento dalla versione 3.3.1 |
| 148 |
- alla 3.3.2 ha coinvolto meno di 100 pacchetti su 320. I pacchetti suddivisi |
| 149 |
- permettono di aggiornare gli ebuild che sono effettivamente cambiati, |
| 150 |
- facendo risparmiare (in questo caso) più di due terzi del tempo necessario |
| 151 |
- all'aggiornamento. |
| 152 |
- </li> |
| 153 |
- <li> |
| 154 |
- Le patch solitamente riguardano un pacchetto specifico. Con gli ebuild |
| 155 |
- suddivisi esse possono essere testate, approvate e rilasciate più |
| 156 |
- rapidamente impegnando di meno gli sviluppatori: come accennato in |
| 157 |
- precedenza, l'utente impiegherà meno tempo per gli aggiornamenti. Questo |
| 158 |
- fatto diventa ancora più importante per gli aggiornamenti di sicurezza. |
| 159 |
- </li> |
| 160 |
- <li> |
| 161 |
- Chi usa altri ambienti desktop o Window Managers più leggeri può installare |
| 162 |
- solo le applicazioni di KDE che preferisce senza doversi sobbarcare il |
| 163 |
- carico (piuttosto pesante) di tutto il resto, di <c>kdebase</c> o di |
| 164 |
- <c>kdepim</c>, per esempio. |
| 165 |
- </li> |
| 166 |
- <li> |
| 167 |
- È possibile organizzare al meglio l'installazione dei pacchetti. Per diversi |
| 168 |
- motivi: |
| 169 |
- <ul> |
| 170 |
- <li> |
| 171 |
- Problemi di tempo. <c>emerge kdebase kdepim kdenetwork</c> richiede |
| 172 |
- troppo tempo se tutto quello che occorre è <c>konqueror</c>, |
| 173 |
- <c>kmail</c> e <c>kopete</c>. Inoltre, in certi casi il tempo di calcolo |
| 174 |
- della CPU è denaro. |
| 175 |
- </li> |
| 176 |
- <li> |
| 177 |
- Problemi di spazio. Ogni pacchetto inutilizzato va a intasare lo spazio |
| 178 |
- tra i settori del proprio disco. Un disco con più spazio disponibile |
| 179 |
- respira meglio: è un disco che corre felice. |
| 180 |
- </li> |
| 181 |
- <li> |
| 182 |
- Problemi di sicurezza. Ogni pacchetto installato è una potenziale falla |
| 183 |
- nella sicurezza del sistema e quando i punti deboli si trovano nel |
| 184 |
- software inutilizzato non ci sono scuse. |
| 185 |
- </li> |
| 186 |
- <li> |
| 187 |
- Si è devoti sostenitori della <uri |
| 188 |
- link="/main/it/philosophy.xml">Filosofia di Gentoo</uri>, e non si |
| 189 |
- riesce a sopportare che un povero utente sia costretto ad installare |
| 190 |
- contro la propria volontà una serie di pacchetti che magari non userà. |
| 191 |
- (Non lo sopportano neanche gli sviluppatori Gentoo). |
| 192 |
- </li> |
| 193 |
- </ul> |
| 194 |
- </li> |
| 195 |
- <li> |
| 196 |
- Infine, gli ebuild suddivisi permettono una maggiore flessibilità delle flag |
| 197 |
- USE durante la compilazione. |
| 198 |
- </li> |
| 199 |
-</ul> |
| 200 |
- |
| 201 |
-</body> |
| 202 |
-</section> |
| 203 |
-<section> |
| 204 |
-<title>Integrazione tra ebuild suddivisi ed ebuild monolitici</title> |
| 205 |
-<body> |
| 206 |
- |
| 207 |
-<p> |
| 208 |
-Ebuild monolitici e suddivisi possono essere mischiati liberamente. Con una sola |
| 209 |
-restrizione: un ebuild monolitico ed uno suddiviso derivante da esso non possono |
| 210 |
-essere installati contemporaneamente. Per questo motivo gli ebuild sono |
| 211 |
-vincolati da dipendenze bloccanti: si può fare solo ciò che emerge permette. |
| 212 |
-</p> |
| 213 |
- |
| 214 |
-<p> |
| 215 |
-Di solito, però, non c'è ragione di usare una configurazione così variegata. |
| 216 |
-Infatti, si dovrebbero usare soltanto gli ebuild suddivisi ad eccezione di |
| 217 |
-particolari casi di macchine molto lente (mips). |
| 218 |
-</p> |
| 219 |
- |
| 220 |
-<p> |
| 221 |
-Inoltre gli ebuild suddivisi sono quelli predefiniti. Questo significa che |
| 222 |
-quando un ebuild dipende da un'altra applicazione di KDE, cercherà di installare |
| 223 |
-uno ebuild suddiviso. Tuttavia, anche il corrispondente ebuild monolitico |
| 224 |
-soddisferà quella dipendenza, e sarà così possibile installare manualmente |
| 225 |
-l'ebuild monolitico e quindi l'ebuild che dipende da esso. |
| 226 |
-</p> |
| 227 |
- |
| 228 |
-</body> |
| 229 |
-</section> |
| 230 |
-</chapter> |
| 231 |
- |
| 232 |
-<chapter> |
| 233 |
-<title>Questione di prestazioni</title> |
| 234 |
-<section> |
| 235 |
-<title>Perchè gli ebuild suddivisi sono lenti</title> |
| 236 |
-<body> |
| 237 |
- |
| 238 |
-<p> |
| 239 |
-In precedenza è stato <uri |
| 240 |
-link="http://bugs.gentoo.org/show_bug.cgi?id=11123">detto</uri> che gli ebuild |
| 241 |
-suddivisi avrebbero impiegato più tempo degli emerge di quelle monolitici per il |
| 242 |
-carico di lavoro maggiore dovuto all'estrazione e alla configurazione da |
| 243 |
-ripetere per ciascun pacchetto. Un <c>emerge kde-meta</c> completo può |
| 244 |
-richiedere il 20-30% del tempo in più di un classico <c>emerge kde</c>, |
| 245 |
-inaccettabile per una compilazione già di per se lunga. |
| 246 |
-</p> |
| 247 |
- |
| 248 |
-<p> |
| 249 |
-Non solo. Ora come ora gli ebuild suddivisi eseguono sempre <c>make -f |
| 250 |
-admin/Makefile.cvs</c> (significa che verranno eseguiti autoconf, automake, |
| 251 |
-ecc. e una serie di altri script correlati a KDE). Questo comporta un ulteriore |
| 252 |
-rallentamento, paragonabile all'esecuzione di configure. |
| 253 |
-</p> |
| 254 |
- |
| 255 |
-<p> |
| 256 |
-Inoltre, uno ebuild suddiviso deve estrarre file specifici da un grosso |
| 257 |
-archivio. Questo processo è più lento di quello che servirebbe per decomprimere |
| 258 |
-un piccolo archivio, specifico per l'applicazione. Tuttavia, creare simili |
| 259 |
-archivi per il sistema di compilazione di KDE 3.x, basato sugli autotools, non è |
| 260 |
-affatto semplice. |
| 261 |
-</p> |
| 262 |
- |
| 263 |
-<p> |
| 264 |
-Vale la pena di ripetere che con gli ebuild suddivisi il tempo di compilazione |
| 265 |
-degli aggiornamenti di KDE sarà notevolmente ridotto, aggiornando solo i |
| 266 |
-pacchetti che sono effettivamente cambiati. I vantaggi di uno solo di questi |
| 267 |
-aggiornamenti ripaga ampiamente del tempo richiesto dalla prima installazione. |
| 268 |
-</p> |
| 269 |
- |
| 270 |
-<p> |
| 271 |
-Infine, l'installazione completa di KDE ha senso quando si vogliono valutare |
| 272 |
-tutti i pacchetti disponibili o quando si vuole configurare un ambiente |
| 273 |
-multiutente; tuttavia, molte persone usano solo una parte delle 300 e più |
| 274 |
-applicazioni offerte da KDE. Chiunque si preoccupi veramente della durata delle |
| 275 |
-compilazioni, come i possessori di macchine un po' datate, può guadagnare più |
| 276 |
-tempo con l'installazione selettiva dei pacchetti di quanto ne perda per il |
| 277 |
-carico supplementare di lavoro. |
| 278 |
-</p> |
| 279 |
- |
| 280 |
-</body> |
| 281 |
-</section> |
| 282 |
-<section> |
| 283 |
-<title>Miglioramenti alle prestazioni degli ebuild suddivisi</title> |
| 284 |
-<body> |
| 285 |
- |
| 286 |
-<p> |
| 287 |
-La maggior parte, o addirittura la totalità dei problemi di velocità degli |
| 288 |
-ebuild suddivisi, è legata agli autotools - autoconf, automake ed altri |
| 289 |
-strumenti che gestiscono il sistema di compilazione <c>./configure; make; make |
| 290 |
-install</c> usato in KDE 3.x. |
| 291 |
-</p> |
| 292 |
- |
| 293 |
-<p> |
| 294 |
-KDE 4 adotterà (in base alle informazioni attuali) un sistema di compilazione |
| 295 |
-completamente nuovo, che tra le altre cose ridurrà di molto il tempo che |
| 296 |
-l'equivalente di <c>make -f admin/Makefile.common; ./configure</c> impiegherà. |
| 297 |
-</p> |
| 298 |
- |
| 299 |
-</body> |
| 300 |
-</section> |
| 301 |
-</chapter> |
| 302 |
- |
| 303 |
-<chapter> |
| 304 |
-<title>Domande frequenti per gli ebuild suddivisi</title> |
| 305 |
-<section> |
| 306 |
-<title>Perché alcuni pacchetti suddivisi non hanno ebuild delle ultime |
| 307 |
-versioni?</title> |
| 308 |
-<body> |
| 309 |
- |
| 310 |
-<p> |
| 311 |
-Come spiegato in precedenza, non tutte le applicazioni vengono realmente |
| 312 |
-aggiornate tra rilasci minori di KDE, e quindi non tutte le applicazioni |
| 313 |
-ricevono nuove versioni di ebuild. Per esempio, libkdenetwork non è stato |
| 314 |
-aggiornato nella versione 3.5.0_beta2, quindi l'ultimo ebuild disponibile per |
| 315 |
-quella release è il 3.5_beta1. |
| 316 |
-</p> |
| 317 |
- |
| 318 |
-<p> |
| 319 |
-Questo viene fatto solo per ridurre il tempo di compilazione durante un |
| 320 |
-aggiornamento. Se fosse stato fatto fatto un ebuild libkdenetwork-3.5.0_beta2, |
| 321 |
-esso avrebbe installato esattamente gli stessi file della versione 3.5_beta1. Le |
| 322 |
-varie dipendenze vengono aggiornate per funzionare correttamente (ad esempio |
| 323 |
-nessun ebuild dipenderà da libkdenetwork-3.5.0_beta2). |
| 324 |
-</p> |
| 325 |
- |
| 326 |
-</body> |
| 327 |
-</section> |
| 328 |
-<section> |
| 329 |
-<title>Esiste già l'opzione DO_NOT_COMPILE: non produce lo stesso |
| 330 |
-effetto?</title> |
| 331 |
-<body> |
| 332 |
- |
| 333 |
-<p> |
| 334 |
-DO_NOT_COMPILE è una variabile interna all'ambiente di compilazione di KDE. |
| 335 |
-Permette di scegliere quali sottodirectory non devono essere compilate. Tale |
| 336 |
-funzione viene già utilizzata per compilare solo una parte dell'ebuild |
| 337 |
-monolitico di KDE. Ad esempio con <c>DO_NOT_COMPILE=konqueror emerge kdebase</c> |
| 338 |
-si installa kdebase senza <c>konqueror</c>. |
| 339 |
-</p> |
| 340 |
- |
| 341 |
-<p> |
| 342 |
-Ad ogni modo, l'uso di DO_NOT_COMPILE non deve interferire con le operazioni |
| 343 |
-di uno strumento per la gestione automatica dei pacchetti. Non funziona, può |
| 344 |
-portare a problemi di sistema e non è mai stato supportato. Si raccomanda |
| 345 |
-vivamente di non usarlo. |
| 346 |
-</p> |
| 347 |
- |
| 348 |
-<p> |
| 349 |
-Ecco un elenco incompleto dei problemi causati da DO_NOT_COMPILE: |
| 350 |
-</p> |
| 351 |
- |
| 352 |
-<ul> |
| 353 |
- <li> |
| 354 |
- Rovina completamente la gestione delle dipendenze di Portage. Portage non è |
| 355 |
- a conoscenza di DO_NOT_COMPILE e pensa che l'intero pacchetto monolitico sia |
| 356 |
- stato installato e che possa soddisfare le dipendenze di altri pacchetti. |
| 357 |
- Ciò causerà il fallimento dell'installazione o dell'esecuzione di altri |
| 358 |
- pacchetti. |
| 359 |
- </li> |
| 360 |
- <li> |
| 361 |
- Costringe l'utente a conoscere il nome e il significato di tutte le |
| 362 |
- sottodirectory dei moduli di KDE. Pochi sono in grado di farlo, a meno che |
| 363 |
- non siano sviluppatori di KDE: per questo è quasi impossibile fare un uso |
| 364 |
- corretto di DO_NOT_COMPILE. |
| 365 |
- </li> |
| 366 |
- <li> |
| 367 |
- Le sottodirectory dei moduli di KDE possono dipendere l'una dall'altra, |
| 368 |
- possono richiedere un ordine di compilazione ben preciso, possono richiedere |
| 369 |
- la presenza di un altra directory magari non effettivamente installata, e |
| 370 |
- così via. È stato fatto un gran lavoro per rendere funzionanti gli ebuild |
| 371 |
- suddivisi. DO_NOT_COMPILE non raggiunge gli stessi risultati, neanche con |
| 372 |
- una sufficiente conoscenza da parte dell'utente. Tutto quello che si può |
| 373 |
- ottenere con questo metodo è di evitare di compilare solo una piccola parte |
| 374 |
- delle applicazioni. È praticamente impossibile usarlo per installare solo |
| 375 |
- <c>kdebase</c> e <c>kdepim</c>, per esempio. |
| 376 |
- </li> |
| 377 |
- <li> |
| 378 |
- Se ieri è stato installato kmail e oggi si vuole installare korn, usando |
| 379 |
- DO_NOT_COMPILE si sarà comunque costretti a ricompilare kmail. Questo |
| 380 |
- significa che DO_NOT_COMPILE resta comunque meno prestante degli ebuild |
| 381 |
- suddivisi. |
| 382 |
- </li> |
| 383 |
- <li> |
| 384 |
- DO_NOT_COMPILE non può essere usato per creare pacchetti precompilati (come |
| 385 |
- GRP) che contengono singole applicazioni di KDE. |
| 386 |
- </li> |
| 387 |
-</ul> |
| 388 |
- |
| 389 |
-</body> |
| 390 |
-</section> |
| 391 |
- |
| 392 |
-<section> |
| 393 |
-<title>Non si stanno caricando troppo i mantenitori KDE di Gentoo?</title> |
| 394 |
-<body> |
| 395 |
- |
| 396 |
-<p> |
| 397 |
-È sorprendente vedere quanti pongano questa domanda. Gli sviluppatori sono |
| 398 |
-felici che gli utenti li tengano così in considerazione. Si coglie l'occasione |
| 399 |
-per assicurare quest'ultimi che gli sviluppatori si stanno occupando degli |
| 400 |
-ebuild suddivisi per libera scelta, e che pensano di essere in grado di |
| 401 |
-continuare a migliorarli, senza alcuna possibilità di essere dissuasi :-) |
| 402 |
-</p> |
| 403 |
- |
| 404 |
-<p> |
| 405 |
-Per la verità c'è da dire che i mantenitori delle altre architetture si sono |
| 406 |
-lamentati per l'aumento del lavoro di test dovuto a così tanti ebuild separati. |
| 407 |
-Si sta lavorando per risolvere questo problema e questo è il motivo principale |
| 408 |
-per cui gli ebuild monolitici saranno ancora disponibili per KDE 3.5. |
| 409 |
-</p> |
| 410 |
- |
| 411 |
-</body> |
| 412 |
-</section> |
| 413 |
-<section> |
| 414 |
-<title>C'è l'intenzione di eliminare gli ebuild vecchio stile (quelli |
| 415 |
-monolitici)?</title> |
| 416 |
-<body> |
| 417 |
- |
| 418 |
-<p> |
| 419 |
-Gli sviluppatori sono intenzionati a farlo, ma più avanti. Comunque, ci saranno |
| 420 |
-ebuild suddivisi e ebuild monolitici per tutte le versioni 3.x di KDE. |
| 421 |
-</p> |
| 422 |
- |
| 423 |
-<p> |
| 424 |
-Se si preferiscono gli ebuild monolitici a quelli suddivisi, si prega di <uri |
| 425 |
-link="http://bugs.gentoo.org">far sapere</uri> il motivo ai rispettivi |
| 426 |
-sviluppatori. |
| 427 |
-</p> |
| 428 |
- |
| 429 |
-</body> |
| 430 |
-</section> |
| 431 |
-<section> |
| 432 |
-<title>Ci sono troppi ebuild! Come si può trovare quello di cui si ha |
| 433 |
-bisogno?</title> |
| 434 |
-<body> |
| 435 |
- |
| 436 |
-<p> |
| 437 |
-Prima di tutto, nel momento in cui il pacchetto che si sta cercando fa parte di |
| 438 |
-kdebase, è ancora possibile eseguire <c>emerge kdebase-meta</c>, con lo stesso |
| 439 |
-risultato di <c>kdebase</c> monolitico. In realtà le cose non sono peggiorate |
| 440 |
-a causa degli ebuild suddivisi. |
| 441 |
-</p> |
| 442 |
- |
| 443 |
-<p> |
| 444 |
-Naturalmente tutti i metodi tradizionali per individuare un pacchetto restano |
| 445 |
-validi. Come trovare il proprio ebuild facente parte di Gnome? Come minimo |
| 446 |
-bisognerebbe conoscerne il nome. |
| 447 |
-</p> |
| 448 |
- |
| 449 |
-<p> |
| 450 |
-Forse la situazione potrebbe essere migliorata introducendo più ebuild -meta. |
| 451 |
-Sono soltanto liste di dipendenze, e non costerebbe nulla. Questo non è ancora |
| 452 |
-stato deciso. Inoltre, sarebbe meglio avere la funzionalità "sets" (insiemi) in |
| 453 |
-Portage prima che sia reso estensivo. |
| 454 |
-</p> |
| 455 |
- |
| 456 |
-</body> |
| 457 |
-</section> |
| 458 |
-<section> |
| 459 |
-<title>Come si può elencare oppure eseguire l'unmerge di tutti gli ebuild |
| 460 |
-suddivisi che derivano da un determinato pacchetto?</title> |
| 461 |
-<body> |
| 462 |
- |
| 463 |
-<p> |
| 464 |
-L'obiettivo è elencare tutti gli ebuild suddivisi di KDE che derivano, per |
| 465 |
-esempio, dall'ebuild monolitico <c>kdebase</c>. L'implementazione più corretta |
| 466 |
-(come <uri link="/proj/en/glep/glep-0021.html">GLEP 21</uri>) può essere banale. |
| 467 |
-Tuttavia bisognerebbe essere in qualche modo a conoscenza dell'implementazione |
| 468 |
-delle eclass di KDE, così, se per caso si utilizza uno di questi approcci in |
| 469 |
-qualche script che non sia per uso privato, farlo sapere agli sviluppatori. |
| 470 |
-</p> |
| 471 |
- |
| 472 |
-<p> |
| 473 |
-kde-functions.eclass definisce delle funzioni chiamate get-parent-package() e |
| 474 |
-get-child-packages(); saranno loro ad eseguire il lavoro al proprio posto. |
| 475 |
-Queste due funzioni sono il modo corretto per eseguire quanto detto prima a |
| 476 |
-partire da una ebuild o da uno script bash esterno. Ecco un esempio: |
| 477 |
-</p> |
| 478 |
- |
| 479 |
-<pre caption="Esempio d'uso delle funzioni kde-functions"> |
| 480 |
-$ <i>function die() { echo $@; } </i> <comment># invocato per riportare eventuali errori</comment> |
| 481 |
-$ <i>source /usr/portage/eclass/kde-functions.eclass</i> |
| 482 |
-$ <i>get-parent-package konqueror</i> <comment># così non funziona: bisogna specificare il nome completo</comment>> |
| 483 |
-Package konqueror not found in KDE_DERIVATION_MAP, please report bug <comment># l'errore viene riportato</comment> |
| 484 |
-$ <i>get-parent-package kde-base/konqueror</i> <comment># il nome è stato indicato correttamente</comment> |
| 485 |
-kde-base/kdebase <comment># viene riportato il risultato</comment> |
| 486 |
-$ <i>get-child-packages kde-base/kdebase</i> |
| 487 |
-<comment> # (segue l'elenco dei pacchetti)</comment> |
| 488 |
-</pre> |
| 489 |
- |
| 490 |
-<p> |
| 491 |
-Se non si sta usando uno script bash, è possibile passare kde-functions.eclasses |
| 492 |
-a grep per estrarre la definizione (multilinea) della variabile |
| 493 |
-KDE_DERIVATION_MAP, usata dalla funzione summenzionata. Questa variabile |
| 494 |
-contiene una lista di parole separate da spazi: ogni coppia di parole lega un |
| 495 |
-pacchetto padre all'ebuild suddiviso figlio. |
| 496 |
+Questo documento è stato spostato in |
| 497 |
+<uri>/proj/it/desktop/kde/kde-split-ebuilds.xml</uri> |
| 498 |
</p> |
| 499 |
|
| 500 |
</body> |
| 501 |
|
| 502 |
|
| 503 |
|
| 504 |
-- |
| 505 |
gentoo-commits@l.g.o mailing list |
Archives