[gentoo-commits] gentoo commit in xml/htdocs/doc/it: kde-split-ebuilds.xml

[gentoo-commits] gentoo commit in xml/htdocs/doc/it: kde-split-ebuilds.xml

[Davide Cendron (scen)]

scen        07/11/07 20:58:53

  Modified:             kde-split-ebuilds.xml
  Log:
  Properly lixed links to available Italian translated docs

Revision  Changes    Path
1.8                  xml/htdocs/doc/it/kde-split-ebuilds.xml

file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/it/kde-split-ebuilds.xml?rev=1.8&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/it/kde-split-ebuilds.xml?rev=1.8&content-type=text/plain
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/it/kde-split-ebuilds.xml?r1=1.7&r2=1.8

Index: kde-split-ebuilds.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/doc/it/kde-split-ebuilds.xml,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- kde-split-ebuilds.xml	26 Jun 2007 21:01:10 -0000	1.7
+++ kde-split-ebuilds.xml	7 Nov 2007 20:58:53 -0000	1.8
@@ -1,6 +1,6 @@
 <?xml version='1.0' encoding='UTF-8'?>
 <!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/it/kde-split-ebuilds.xml,v 1.7 2007/06/26 21:01:10 scen Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/it/kde-split-ebuilds.xml,v 1.8 2007/11/07 20:58:53 scen Exp $ -->
 
 <guide link="/doc/it/kde-split-ebuilds.xml" lang="it">
 <title>Guida agli Ebuild "split" (suddivisi) di KDE</title>
@@ -178,7 +178,7 @@
       </li>
       <li>
 	Si è devoti sostenitori della <uri
-        link="/main/en/philosophy.xml">Filosofia di Gentoo</uri>, e non	si
+        link="/main/it/philosophy.xml">Filosofia di Gentoo</uri>, 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).



-- 
gentoo-commits@gentoo.org mailing list

[gentoo-commits] gentoo commit in xml/htdocs/doc/it: kde-split-ebuilds.xml

[Davide Cendron (scen)]

scen        08/01/17 23:44:37

  Modified:             kde-split-ebuilds.xml
  Log:
  Version 1.11, revision 1.15 of EN CVS

Revision  Changes    Path
1.10                 xml/htdocs/doc/it/kde-split-ebuilds.xml

file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/it/kde-split-ebuilds.xml?rev=1.10&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/it/kde-split-ebuilds.xml?rev=1.10&content-type=text/plain
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/it/kde-split-ebuilds.xml?r1=1.9&r2=1.10

Index: kde-split-ebuilds.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/doc/it/kde-split-ebuilds.xml,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- kde-split-ebuilds.xml	13 Dec 2007 22:24:40 -0000	1.9
+++ kde-split-ebuilds.xml	17 Jan 2008 23:44:36 -0000	1.10
@@ -1,6 +1,6 @@
 <?xml version='1.0' encoding='UTF-8'?>
 <!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/it/kde-split-ebuilds.xml,v 1.9 2007/12/13 22:24:40 scen Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/it/kde-split-ebuilds.xml,v 1.10 2008/01/17 23:44:36 scen Exp $ -->
 
 <guide link="/doc/it/kde-split-ebuilds.xml" lang="it">
 <title>Guida agli Ebuild "split" (suddivisi) di KDE</title>
@@ -31,8 +31,8 @@
 <!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
 <license/>
 
-<version>1.10</version>
-<date>2007-06-23</date>
+<version>1.11</version>
+<date>2008-01-16</date>
 
 <chapter>
 <title>Gli Ebuild 'suddivisi' di KDE</title>
@@ -58,7 +58,7 @@
 <p>
 Gli ebuild monolitici di KDE sono ancora disponibili per la versione 3.5 di KDE
 e possono interagire in maniera trasparente con quelli suddivisi. Tuttavia
-quest'ultimi sono il nuovo standard e a partire da KDE 4.0 quelli monolitici non
+quest'ultimi sono il nuovo standard e dopo KDE 4.0 quelli monolitici non
 saranno più disponibili.
 </p>
 
@@ -75,8 +75,9 @@
 
 <p>
 L'ultima versione stabile di KDE disponibile alla stesura di questo documento è
-la 3.5.5. L'ultima instabile (~arch) è la 3.5.7. Portage offre entrambe le
-opportunità di installazione, suddivisa e monolitica.
+la 3.5.7. L'ultima instabile (~arch) è la 3.5.8. Portage offre entrambe le
+opportunità di installazione, suddivisa e monolitica. La versione 4.0.0 entrerà
+a breve nell'albero di portage in stato "hardmasked".
 </p>
 
 <ul>
@@ -491,5 +492,4 @@
 </body>
 </section>
 </chapter>
-
-</guide>
\ No newline at end of file
+</guide>



-- 
gentoo-commits@lists.gentoo.org mailing list

[gentoo-commits] gentoo commit in xml/htdocs/doc/it: kde-split-ebuilds.xml

[Davide Cendron (scen)]

scen        08/05/01 13:15:59

  Modified:             kde-split-ebuilds.xml
  Log:
  Version 2, revision 1.16 of EN CVS

Revision  Changes    Path
1.11                 xml/htdocs/doc/it/kde-split-ebuilds.xml

file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/it/kde-split-ebuilds.xml?rev=1.11&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/it/kde-split-ebuilds.xml?rev=1.11&content-type=text/plain
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/it/kde-split-ebuilds.xml?r1=1.10&r2=1.11

Index: kde-split-ebuilds.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/doc/it/kde-split-ebuilds.xml,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- kde-split-ebuilds.xml	17 Jan 2008 23:44:36 -0000	1.10
+++ kde-split-ebuilds.xml	1 May 2008 13:15:59 -0000	1.11
@@ -1,8 +1,8 @@
 <?xml version='1.0' encoding='UTF-8'?>
 <!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/it/kde-split-ebuilds.xml,v 1.10 2008/01/17 23:44:36 scen Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/it/kde-split-ebuilds.xml,v 1.11 2008/05/01 13:15:59 scen Exp $ -->
 
-<guide link="/doc/it/kde-split-ebuilds.xml" lang="it">
+<guide redirect="/proj/it/desktop/kde/kde-split-ebuilds.xml" lang="it">
 <title>Guida agli Ebuild "split" (suddivisi) di KDE</title>
 
 <author title="Autore">
@@ -31,462 +31,17 @@
 <!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
 <license/>
 
-<version>1.11</version>
-<date>2008-01-16</date>
+<version>2</version>
+<date>2008-04-26</date>
 
 <chapter>
-<title>Gli Ebuild 'suddivisi' di KDE</title>
+<title>Documento spostato</title>
 <section>
-<title>Di cosa si tratta?</title>
 <body>
 
 <p>
-Fino a Gennaio 2005 gli unici ebuild di KDE disponibili in Portage erano quelli
-'monolitici'. Questo significa che c'erano solo 15 ebuild (<c>kdebase</c>,
-<c>kdenetwork</c>, ...) 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.
-</p>
-
-<p>
-I nuovi ebuild 'split' (ndT. di seguito definiti 'suddivisi') (per
-<c>konqueror</c>, <c>kmail</c>, ...) 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.
-</p>
-
-<p>
-Gli ebuild monolitici di KDE sono ancora disponibili per la versione 3.5 di KDE
-e possono interagire in maniera trasparente con quelli suddivisi. Tuttavia
-quest'ultimi sono il nuovo standard e dopo KDE 4.0 quelli monolitici non
-saranno più disponibili.
-</p>
-
-<p>
-Infine, si segnala che esistono gli ebuild suddivisi anche per Koffice, i quali
-mettono a disposizione <c>kword</c>, <c>kugar</c>, ecc. come pacchetti separati.
-</p>
-
-</body>
-</section>
-<section>
-<title>Installare gli ebuild suddivisi</title>
-<body>
-
-<p>
-L'ultima versione stabile di KDE disponibile alla stesura di questo documento è
-la 3.5.7. L'ultima instabile (~arch) è la 3.5.8. Portage offre entrambe le
-opportunità di installazione, suddivisa e monolitica. La versione 4.0.0 entrerà
-a breve nell'albero di portage in stato "hardmasked".
-</p>
-
-<ul>
-  <li>
-    Per installare un particolare pacchetto, per esempio kmail, è sufficiente
-    eseguire <c>emerge kmail</c>.
-  </li>
-  <li>
-    Per installare 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 ebuild suddivisi - per esempio, per avere tutte le applicazioni
-    incluse in <c>kdebase</c> - eseguire <c>emerge kdebase-meta</c> (oppure
-    <c>kdepim-meta</c>, ecc.). Per ottenere tutti gli ebuild suddivisi di KDE,
-    eseguire <c>emerge kde-meta</c>.
-  </li>
-</ul>
-
-</body>
-</section>
-<section>
-<title>Migrare dagli ebuild monolitici a quelli suddivisi</title>
-<body>
-
-<p>
-Se è installata la versione 3.3.x di KDE, è possibile installare gli ebuild
-suddivisi della versione 3.5.x senza interferire con l'installazione esistente
-mediante <c>emerge kde-meta</c>.
-</p>
-
-<p>
-Se invece è 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.
-</p>
-
-<p>
-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.
-</p>
-
-</body>
-</section>
-<section>
-<title>Vantaggi degli ebuild suddivisi</title>
-<body>
-
-<p>
-Ecco un breve elenco dei vantaggi che si ottengono passando agli ebuild
-suddivisi:
-</p>
-
-<ul>
-  <li>
-    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.
-  </li>
-  <li>
-    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.
-  </li>
-  <li>
-    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 <c>kdebase</c> o di
-    <c>kdepim</c>, per esempio.
-  </li>
-  <li>
-    È possibile organizzare al meglio l'installazione dei pacchetti. Per diversi
-    motivi:
-    <ul>
-      <li>
-        Problemi di tempo. <c>emerge kdebase kdepim kdenetwork</c> richiede
-        troppo tempo se tutto quello che occorre è <c>konqueror</c>,
-        <c>kmail</c> e <c>kopete</c>. Inoltre, in certi casi il tempo di calcolo
-        della CPU è denaro.
-      </li>
-      <li>
-        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.
-      </li>
-      <li>
-        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>
-        Si è devoti sostenitori della <uri
-        link="/main/it/philosophy.xml">Filosofia di Gentoo</uri>, 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).
-      </li>
-    </ul>
-  </li>
-  <li>
-    Infine, gli ebuild suddivisi permettono una maggiore flessibilità delle flag
-    USE durante la compilazione.
-  </li>
-</ul>
-
-</body>
-</section>
-<section>
-<title>Integrazione tra ebuild suddivisi ed ebuild monolitici</title>
-<body>
-
-<p>
-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.
-</p>
-
-<p>
-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).
-</p>
-
-<p>
-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.
-</p>
-
-</body>
-</section>
-</chapter>
-
-<chapter>
-<title>Questione di prestazioni</title>
-<section>
-<title>Perchè gli ebuild suddivisi sono lenti</title>
-<body>
-
-<p>
-In precedenza è stato <uri
-link="http://bugs.gentoo.org/show_bug.cgi?id=11123">detto</uri> 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 <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 ebuild suddivisi 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>
-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.
-</p>
-
-<p>
-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.
-</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 ebuild suddivisi</title>
-<body>
-
-<p>
-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 <c>./configure; make; make
-install</c> usato in KDE 3.x.
-</p>
-
-<p>
-KDE 4 adotterà (in base alle informazioni attuali) un sistema di compilazione
-completamente nuovo, che tra le altre cose ridurrà di molto il tempo che
-l'equivalente di <c>make -f admin/Makefile.common; ./configure</c> impiegherà.
-</p>
-
-</body>
-</section>
-</chapter>
-
-<chapter>
-<title>Domande frequenti per gli ebuild suddivisi</title>
-<section>
-<title>Perché alcuni pacchetti suddivisi non hanno ebuild delle ultime
-versioni?</title>
-<body>
-
-<p>
-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.
-</p>
-
-<p>
-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).
-</p>
-
-</body>
-</section>
-<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 <c>konqueror</c>.
-</p>
-
-<p>
-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.
-</p>
-
-<p>
-Ecco un elenco incompleto dei problemi causati da DO_NOT_COMPILE:
-</p>
-
-<ul>
-  <li>
-    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.
-  </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. È 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
-    <c>kdebase</c> e <c>kdepim</c>, per esempio.
-  </li>
-  <li>
-    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.
-  </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 si stanno caricando troppo i mantenitori KDE di Gentoo?</title>
-<body>
-
-<p>
-È 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 :-)
-</p>
-
-<p>
-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.
-</p>
-
-</body>
-</section>
-<section>
-<title>C'è l'intenzione di eliminare gli ebuild vecchio stile (quelli
-monolitici)?</title>
-<body>
-
-<p>
-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.
-</p>
-
-<p>
-Se si preferiscono gli ebuild monolitici a quelli suddivisi, si prega di <uri
-link="http://bugs.gentoo.org">far sapere</uri> il motivo ai rispettivi
-sviluppatori.
-</p>
-
-</body>
-</section>
-<section>
-<title>Ci sono troppi ebuild! Come si può trovare quello di cui si ha
-bisogno?</title>
-<body>
-
-<p>
-Prima di tutto, nel momento in cui il pacchetto che si sta cercando fa parte di
-kdebase, è ancora possibile 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 ebuild suddivisi.
-</p>
-
-<p>
-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.
-</p>
-
-<p>
-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.
-</p>
-
-</body>
-</section>
-<section>
-<title>Come si può elencare oppure eseguire l'unmerge di tutti gli ebuild
-suddivisi che derivano da un determinato pacchetto?</title>
-<body>
-
-<p>
-L'obiettivo è elencare tutti gli ebuild suddivisi di KDE che derivano, per
-esempio, dall'ebuild monolitico <c>kdebase</c>. L'implementazione più corretta
-(come <uri link="/proj/en/glep/glep-0021.html">GLEP 21</uri>) 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.
-</p>
-
-<p>
-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:
-</p>
-
-<pre caption="Esempio d'uso delle funzioni kde-functions">
-$ <i>function die() { echo $@; } </i> <comment># invocato per riportare eventuali errori</comment>
-$ <i>source /usr/portage/eclass/kde-functions.eclass</i>
-$ <i>get-parent-package konqueror</i> <comment># così non funziona: bisogna specificare il nome completo</comment>>
-Package konqueror not found in KDE_DERIVATION_MAP, please report bug <comment># l'errore viene riportato</comment>
-$ <i>get-parent-package kde-base/konqueror</i> <comment># il nome è stato indicato correttamente</comment>
-kde-base/kdebase <comment># viene riportato il risultato</comment>
-$ <i>get-child-packages kde-base/kdebase</i>
-<comment> # (segue l'elenco dei pacchetti)</comment>
-</pre>
-
-<p>
-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.
+Questo documento è stato spostato in
+<uri>/proj/it/desktop/kde/kde-split-ebuilds.xml</uri>
 </p>
 
 </body>



-- 
gentoo-commits@lists.gentoo.org mailing list

[gentoo-commits] gentoo commit in xml/htdocs/doc/it: kde-split-ebuilds.xml

[Davide Cendron (scen)]

scen        09/11/17 23:12:59

  Removed:              kde-split-ebuilds.xml
  Log:
  Remove obsolete guide