Attachment 78319 Details for Bug 120599 – [it] update translation of hb-guide-ebuild-maintaining.xml

[it] update translation of hb-guide-ebuild-maintaining.xml

hb-guide-ebuild-maintaining.xml (text/plain), 9.61 KB, created by luna80 on 2006-01-27 20:34:01 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: luna80

Created: 2006-01-27 20:34:01 UTC

Size: 9.61 KB

patch

obsolete

><?xml version='1.0' encoding='UTF-8'?>
><!DOCTYPE sections SYSTEM "/dtd/book.dtd">
>
>
>
>
>
>
><sections>
><section>
><title>Introduzione</title>
><body>
>
><p>
>Questa guida ha lo scopo di spiegare le routines di manutenzione comuni, cosÃ¬ come altre rare manutenzioni che potrebbero non essere famigliari agli sviluppatori.
></p>
>
></body>
></section>
>
><section>
><title>Aggiungere un nuovo ebuild</title>
><body>
>
><p>
>Quando aggiungi un nuovo ebuild, devi includere solo le <c>KEYWORDS</c> per le architetture in cui hai veramente testato l'ebuild, confermando che funziona come deve e che le <c>USE</c> flags sono riportate anche nel pacchetto che verrÃ  installato. Se possibile, devi dare veramente la libreria o l'applicazione dopo averla testata molto bene, siccome sarai responsabile per qualsiasi danneggiamento nella(e) tua(e) architettura(e). Test minimi come il solo controllo che l'applicazione si avvii senza errori non sono sufficienti.
></p>
>
><p>
>Se stai aggiungendo un ebuild riportato da un utente, non presuporre che l'utente ha fatto il test nelle varie architetture: spesso, <c>KEYWORDS</c> sono state clonate tra i diversi pacchetti o generate nei pacchetti sorgente dalla documentazione, il che non significa che il pacchetto funzioni davvero su questa architetture.
></p>
>
></body>
></section>
>
><section>
><title>Stabilizzare gli ebuild</title>
><body>
>
><p>
>Solo i mantenitori delle architetture per una data architettura devono marcare i
>pacchetti stabili nell'architettura. Il mantenitore del pacchetto deve sempre
>essere contattato; non fare questo solo se ci sono delle ragioni. Un eccezione a
>questo c'Ã¨ se fai parte di un team di un'architettura e marchi un pacchetto
>stabile per tale architettura. Se non fai parte di un team di architettura, devi
>consultare le linee guida ripostato sotto; se l'architettura che stai cercando
>non Ã¨ elencata allora per favore consulta il relativo capo.
>
><p>
>Non devi <e>mai</e> stabilizzare i pacchetti per le architetture che non puoi testare, al contrario devi mandare un bug al team della relativa architettura, come <mail link="sparc@gentoo.org">sparc@gentoo.org</mail> chiedendo di stabilizzare l'ebuild. Alternativamente, potresti trovare uno sviluppatore Gentoo in IRC che ti puÃ² aiutare nella tua richiesta.
></p>
>
><p>
>E' meglio non usare <mail link="arch-maintainers@gentoo.org">arch-maintainers@gentoo.org</mail>, ma piuttosto aggiungi individualmente i team dell'architettura nella lista CC del bug. In questo modo i teams possono rimuoversi dalla lista da soli una volta che hanno finito il loro lavoro, dando una chiara indicazione su quale team deve ancora stabilizzare un pacchetto.
></p>
>
></body>
></section>
>
><section>
><title>Regole per la stabilizzazione</title>
><body>
>
><p>
>SPARC: devi avere i permessi dal capo dell'architettura (al momento Weeve). Generalmente ci aspettiamo che tu sia su un alias di sparc per ragione di QA, nonostante possono essere date altre disposizioni se vuoi lavorare soltanto con un piccolo gruppo di pacchetti.
></p>
><p>
>ALPHA: i mantenitori devono contrassegnare i loro pacchetti personali ma devono
>anche informare il team Alpha se devono aiutare con i test e la
>contrassegnazione in modo che il team puÃ² tenere d'occhio i possibili errori.
></p>
><p>
>MIPS: devi avere i permessi da uno sviluppatore MIPS senior. Vista la moltitudine di hardware coinvolta, Ã¨ in genere richiesto di essere su un alias mips e avere accesso a vari sistemi MIPS.
></p>
>
></body>
></section>
>
><section>
><title>Aggiornamento degli ebuilds</title>
><body>
>
><p>
>Nuovi ebuilds devono andare raramente con keywords "<c>arch</c>" e anche se non fa niente, il pacchetto <e>deve</e> essere testato su di una architettura elencata nella variabile <c>KEYWORDS</c> del nuovo pacchetto.
></p>
>
><p>
>Eccezioni alla regola dell'"<c>arch</c>" sono la maggior causa delle fixes dei bug, o delle fixes sulla sicurezza. Se la versione precedente dell'ebuild contiente <c>KEYWORDS</c> che non puoi testare, allora devi fare il downgrade: metti tutte le keywords "<c>arch</c>" come "<c>~arch</c>". Se pensi che il pacchetto non andrÃ  su tutte le "<c>~arch</c>" allora Ã¨ meglio che lasci le cose come sono e chiedi di testare il pacchetto al team in questione: se vuoi fare questo devi compilare un bug per il team dell'architettura.
></p>
>
><p>
>Se una nuova versione introduce nuove dipendeze che non sono disponibili su alcune architetture, allora devi compilare un bug o chiedere in IRC prima di fare l'aggiornamento del pacchetto. Se necessiti veramente di fare le modifiche al pacchetto in modo urgente, per esempio, per questioni di sicurezza, allora devi cancellare tutte le <c>KEYWORDS</c> che causano problemi e mettere nel CC del bug il team dell''architettura in questione. Devi aprire un nuovo bug nell'architettura in questione se non ci sono giÃ  bug disponibili.
></p>
>
><p>
>Se non ci sono dipendenze, non rimuovere le keywords se il tuo commit fallisce su repoman - per favore tenta un <c>cvs update</c> completo e se hai ancora problemi, allora fai un commit con <c>repoman -I</c> e compila un bug nell'architettura che ha dato problemi riportando il messaggio del commit sul CVS.
></p>
>
><warn>
>Quando fai il commit, assicurati di citare tutti i bug nel ChangeLog e di fare il messaggio sul CVS. Questa mancanza potrebbe portari dei provvedimenti disciplinari.
></warn>
>
></body>
></section>
>
><section>
><title>Spostamento di ebuilds</title>
><body>
>
><p>
>Il movimento di ebuilds Ã¨ un processo di due passi:
></p>
>
><p>
>Prima, devi mettere l'ebuild nel CVS. Per fare questo, devi copiare l'ebuild nella sua nuova locazione e fare in commit cosÃ¬ come spiegato in <uri link="?part=1&amp;chap=3">Nuovo ebuild</uri>.
></p>
>
><p>
>Dopo di questo, devi cambiare tutti gli ebuilds che dipendono (<c>DEPEND</c>!!) dal vecchio ebuild in modo di farli dipendere dal nuovo. Solo dopo di ciÃ², devi rimuovere nella vecchia locazione ogni files con <c>cvs remove</c> e fare qui il commit dei cambiamenti.
></p>
>
><note>
>CVS non puÃ² distruggere le directories: semplicemente non le ricrea se sono vuote, provvedi ad usare CVS con la flag <c>-P</c>
></note>
>
><p>
>Alternativamente; puoi usare <c>epkgmove</c> che farÃ  questo per te:
></p>
>
><pre caption="Eliminazione di un pacchetto">
>epkgmove net-old/package net-new/package
></pre>
>
><p>
>Dopo lo spostamento, devi aggiungere l'ultimo file in <path>profiles/updates/</path> nel Portage Tree in questo modo:
></p>
>
><pre caption="Aggiunta di un elemento da aggiornare">
>move net-misc/fwbuilder net-firewall/fwbuilder
></pre>
>
><p>
>Questo esempio, sposta trasparentemente <path>net-misc/fwbuilder</path> <path>net-firewall/fwbuilder</path> se gli utenti lo hanno installato. In questo modo gli utenti riceveranno automaticamente gli aggiornamenti per <path>net-firewall/fwbuilder</path> quando saranno disponibili.
></p>
>
></body>
></section>
>
><section>
><title>Rimozione di ebuilds</title>
><body>
>
><p>
>Quando rimuovi un ebuild assicurati che non ci siano dipendenze corrotte dovute dalla rimozione nel Portage, in piÃ¹, il tuo messaggio sul CVS deve spiegare chiaramente perchÃ¨ l'ebuild Ã¨ stato rimosso.
></p>
>
><p>
>Se necessiti di rimuovere un ebuild, assicurati di non rimuovere accidentalmente la nuova versione o l'unico ebuild stabile per qualsiasi arichitettura. Se vuoi avere una nuova versione marcata come stabile, allora compila un bug o chiedi in IRC.
></p>
>
><p>
>Devi anche assicurarti di non causare un downgrade per qualsiasi "<c>~arch</c>" quando rimuovi un ebuild piuttosto, Ã¨ meglio prima sistemare la nuova versione marcata "<c>~arch</c>" e poi rimuovere le versioni ridondanti dell'ebuild.
></p>
>
></body>
></section>
><section>
><title>Files che creano conflitti</title>
><body>
><p>
>Quando t'imbatti in un pacchetto che tenta di installare alcuni files che sono
>giÃ  forniti da un altro pacchetto (rintracciabile tramite
><c>FEATURES=collision-protect</c> per esempio) devi sistemare questa situazione
>prima di poter fare il commit dell'ebuild o, se trovi questo problema con un
>paccehtto esistente, compila un bug per il pacchetto (vedi piÃ¹ sotto per alcune
>eccezioni). Le ragioni per i confilitti dei files sono critiche perchÃ¨ se "foo"
>fornisce il file <path>/usr/bin/example</path>, "bar" glielo sovrascrive ed
>inseguito viene fatto l'unmerge di "bar", il Portage rimuoverÃ 
><path>/usr/bin/example</path> e di conseguenza corrompere "foo".
></p>
><p>
>Il sistema migliore per ovviare al problema Ã¨ di aggiungere una dipendeza
>bloccante a entrambi i pacchetti che vogliono installare questo files, in modo
>tale da poterli installare tutti e due. A meno che non ci siano anche altre
>ragioni per le quali alcuni pacchetti ne bloccano degli altri, devi evitare
>questo piuttosto che fare una fix del pacchetto, la quale puÃ² includere uno o
>piÃ¹ di questi passaggi:
></p>
><ul>
><li>Rendere "foo" dipendente ((R)DEPEND) da "bar".</li>
><li>Rimuovere i conflitti dei files da "foo" in <c>src_install</c> o <c>pkg_preinst</c>.</li>
><li>Rimuovere i conflitti dei files in un nuovo sottopacchetto e rendere "foo" e
>"bar" entrambi dipendenti ((R)DEPEND) da questo apcchetto.</li>
><li>Cambia la locazione dove "foo" o "bar" installano i files che creano conflitti.</li>
></ul>
><p>
>In alcuni casi i files che creano conflitti non possono davvero essere sistemati
>o sono critici, al momento queste eccezioni conosciute sono il modulo delle
>manpages di Perl (che sovrascrive quello installato direttamenta da Perl) e i
>files di <c>CONFIG_PROTECT</c> (che devono ancora essere sistemati ma non sono
>critici perchÃ¨ il Portage non lo sovrascrive).
></p>
></body>
></section>
></sections>
>

Actions: View

Attachments on bug 120599: 78319