path: root/italian/devel/testing.wml

#use wml::debian::template title="La distribuzione Debian <q>testing</q>" BARETITLE=true
#include "$(ENGLISHDIR)/releases/info"
#use wml::debian::translation-check translation="8900568ad5473cc15ea75f71f489b4f2b7ae659e" maintainer="Luca Monducci"

<p>Per informazioni di base sulla distribuzione testing, destinate al semplice utente,
si vedano le <a href="$(DOC)/manuals/debian-faq/ftparchives#testing">FAQ Debian</a>.</p>

<p>È importante richiamare l'attenzione sia dei normali utenti che degli sviluppatori
sul fatto che gli aggiornamenti di sicurezza per testing <strong>non sono gestiti dal
gruppo di sicurezza</strong>. Per maggiori informazioni si vedano le
<a href="../security/faq#testing">FAQ del gruppo di sicurezza</a>.</p>

<p>Questa pagina tratta essenzialmente gli aspetti di <q>testing</q> importanti
per gli sviluppatori Debian.</p>

<h2>Come funziona <q>testing</q></h2>

<p>La distribuzione <q>testing</q> è una distribuzione generata automaticamente
a partire dalla distribuzione <q>unstable</q> da una serie di script che
tentano di integrare pacchetti che siano privi di bug critici per il rilascio
e in modo da assicurare che le dipendenze degli altri pacchetti in testing
siano sempre soddisfatte.</p>

<p>Un (una particolare versione di un) pacchetto verrà spostato in testing
quando soddisfa tutte le seguenti condizioni:</p>

<ol>
  <li>Deve essere stato in unstable per 10, 5 o 2 giorni, in funzione
  dell'urgenza dell'upload;</li>

  <li>Deve essere stato compilato e deve essere aggiornato su tutte le
  architetture su cui sia stato compilato in unstable;</li>

  <li>Non deve avere bug release-critical applicabili alla
  versione attualmente in <q>testing</q> (si veda sotto per
  <a href="#faq">maggiori informazioni</a>);</li>

  <li>Tutte le sue dipendenze devono <em>o</em> essere soddisfatte dai
  pacchetti già in <q>testing</q> <em>o</em> essere soddisfatte dall'insieme
  di pacchetti che verranno installati nel contempo;</li>

  <li>L'operazione di installazione del pacchetto in <q>testing</q> non dovr&agrave;
  danneggiare alcun pacchetto già in <q>testing</q>. (Si veda sotto per
  <a href="#faq">maggiori informazioni</a>.)</li>
</ol>

<p>Un pacchetto che soddisfi le prime tre condizioni scritte sopra è un
<q>Valido Candidato</q>.</p>

<p>Lo script di aggiornamento mostra quando ciascun pacchetto può essere
mosso da <q>unstable</q> a <q>testing</q>. L'output è doppio:</p>

<ul>
  <li><a href="https://release.debian.org/britney/update_excuses.html">Update excuses</a>
      [<a href="https://release.debian.org/britney/update_excuses.html.gz">compresso con gzip</a>]:
      l'elenco di tutte le versioni del pacchetto candidato e lo stato di base della
      sua propagazione in <q>testing</q>; in genere più corta e leggibile rispetto a
  </li>
  <li><a href="https://release.debian.org/britney/update_output.txt">Update output</a>
      [<a href="https://release.debian.org/britney/update_output.txt.gz">compresso con gzip</a>]:
      l'output completo, piuttosto grezzo, degli script di <q>testing</q>
      mentre operano sui pacchetti candidati
  </li>
</ul>

<h2><a name="faq">Domande/Risposte frequenti</a></h2>

# Note to translators: these two first items are almost the same as
# https://www.debian.org/doc/manuals/developers-reference/pkgs.html#faq

<h3><q>Quali sono i bug critici per il rilascio e come vengono contati?</q></h3>

<p>Tutti i bug con un alto livello di gravità vengono catalogati come
<em><a href="https://bugs.debian.org/release-critical/">release-critical</a></em>;
attualmente sono i bug <strong>critical</strong>, <strong>grave</strong> e
<strong>serious</strong>.</p>

<p>Si presume che tali bug incidano sulle possibilità che il pacchetto
venga incluso nel rilascio stabile di Debian: in generale, se un pacchetto
ha dei bug critici per il rilascio aperti, non andrà in <q>testing</q>, e di
conseguenza non sarà rilasciato in <q>stable</q>.</p>

<p>Il conteggio dei bug in <q>testing</q> è considerato essere il
conteggio dei bug critici per il rilascio che sono marcati come
applicabili alle combinazioni <tt>pacchetto/versione</tt> disponibili
in <q>testing</q> di ciascuna architettura.</p>

<h3><q>Come può l'installazione di un pacchetto in <q>testing</q> danneggiare
il funzionamento di altri pacchetti?</q></h3>

<p>La struttura degli archivi della distribuzione è organizzata in modo da
poter contenere solamente una versione di un pacchetto; un pacchetto è
identificato dal suo nome. Così, quando il pacchetto sorgente <tt>acmefoo</tt>
è installato in <q>testing</q>, insieme con i suoi pacchetti binari
<tt>acme-foo-bin</tt>, <tt>acme-bar-bin</tt>, <tt>libacme-foo1</tt> e
<tt>libacme-foo-dev</tt>, la versione precedente viene rimossa.</p>

<p>Può accadere che la precedente versione fornisse un pacchetto binario con
un vecchio soname di una libreria, tipo <tt>libacme-foo0</tt>. Rimuovendo il
vecchio <tt>acmefoo</tt> verrebbe rimosso anche <tt>libacme-foo0</tt>,
danneggiando qualsiasi pacchetto che dovesse dipendere da esso.</p>

<p>Evidentemente, questo comportamento riguarda principalmente i pacchetti che
forniscono insiemi di pacchetti binari in versioni differenti (e principalmente
le librerie). Tuttavia, riguarda anche i pacchetti per i quali sono state
dichiarate con ==, &lt;= o &lt;&lt; delle dipendenze <q>versioned</q>, ovvero
dipendenze per determinate versioni.</p>

<p>Quando l'insieme dei pacchetti binari forniti da un pacchetto sorgente è
modificato in questo modo, tutti i pacchetti che dipendevano dai precedenti
binari dovranno essere aggiornati per dipendere dai nuovi binari. Poiché
installare tali pacchetti sorgente in <q>testing</q> danneggia tutti i
pacchetti che ne dipendono in <q>testing</q>, è necessario procedere con
attenzione: tutti i pacchetti dipendenti devono essere aggiornati e resi
disponibili ad essere installati senza essere danneggiati e, quando tutto
è pronto, di regola è richiesto un intervento manuale del responsabile del
rilascio o di un assistente.</p>

<p>In caso di problemi con gruppi complessi di pacchetti come questi,
prendere contatto con debian-devel o debian-release per richiedere aiuto.</p>

<h3><q>Continuo a non capire! Gli script di <q>testing</q> dicono che
questo pacchetto è un valido candidato, ma continua a non entrare in
<q>testing</q>.</q></h3>

<p>Ciò accade quando per qualche ragione, diretta o indiretta, l'installazione
del pacchetto impedirà a qualche altro pacchetto di essere installato.</p>

<p>Ricordarsi delle dipendenze del proprio pacchetto. Supponiamo che il
proprio pacchetto dipenda da libtool, o libltdl<var>X</var>, il pacchetto
non entrerà in <q>testing</q> sino a quando la versione corretta di libtool
non sia pronta ad entrarci insieme.</p>

<p>Insomma, ciò non avverrà sino a quando l'installazione di libtool
danneggerà ciò che è già in <q>testing</q>. In altre parole, sino a quando
tutti gli altri pacchetti che dipendono da libltdl<var>Y</var> (dove
<var>Y</var> è la precedente versione) non saranno stati ricompilati, e
tutti i bug critici per il rilascio non saranno stati corretti, nessuno
di questi pacchetti entrerà in <q>testing</q>.</p>

<p>Qui può venir utile <a 
href="https://release.debian.org/britney/update_output.txt">l'output
testuale</a> [<a
href="https://release.debian.org/britney/update_output.txt.gz">compresso
con gzip</a>]: esso offre informazioni (sebbene molto concise) su
quali pacchetti vengono danneggiati quando un valido candidato è aggiunto in
<q>testing</q> (vedere la <a
href="$(DOC)/manuals/developers-reference/pkgs.html#details">Developer's
Reference per maggiori dettagli</a>).</p>

<h3><q>Perché è spesso difficile inserire pacchetti <kbd>Architecture:
all</kbd> in <q>testing</q>?</q></h3>

<p>Per installare un pacchetto <kbd>Architecture: all</kbd>, deve essere
possibile soddisfare le sue dipendenze su <strong>tutte</strong> le
architetture. Se dipende da alcuni pacchetti che possono essere compilati solo
su un insieme limitato di architetture Debian, allora non sarà incluso.</p>

<p>Tuttavia, per ora, <q>testing</q> ignorerà l'installabilità o meno dei
pacchetti <kbd>Architecture: all</kbd> su architetture non-i386. (<q>È un
hack inqualificabile e non sono affatto soddisfatto di averlo fatto, ma è
così.</q> &mdash; aj)</p>

<h3><q>Un pacchetto è bloccato perché è non aggiornato su qualche
architettura. Cosa devo fare?</q></h3>

<p>Controllare lo stato del proprio pacchetto sul
<a href="https://buildd.debian.org/build.php">log del database di costruzione</a>.
Se il pacchetto non viene costruito, sarà segnato come <em>failed</em>;
analizzare i log di costruzione e correggere tutti i problemi presenti
nei sorgenti del pacchetto.</p>

<p>Se capita di notare che qualche architettura ha costruito la nuova
versione del vostro pacchetto, ma che non appare nell'output degli script
in <q>testing</q> si deve pazientare sino a quando il responsabile del buildd
corrispondente non mette in linea i file nell'archivio Debian.</p>

<p>Se alcune architetture non hanno ancora costruito la nuova versione del
proprio pacchetto, nonostante sia in linea una versione corretta per un precedente
malfunzionamento, probabilmente la ragione è che è stato marcato in attesa di
dipendenze (Dep-Wait). Si può vedere l'elenco di questi pacchetti cosiddetti
<a href="https://buildd.debian.org/stats/">in attesa di costruzione</a>.</p>

<p>Generalmente questi problemi si risolvono da soli, ma se si aspetta da un
lungo periodo di tempo (cioè due settimane o più), inviare una segnalazione
al responsabile del buildd del port coinvolto se tale indirizzo è fornito sulla
<a href="$(HOME)/ports/">pagina web del port</a> oppure alla mailing list del
port.</p>

<p>Se un'architettura è stata esplicitamente rimossa dell'elenco delle
architetture nel file di controllo e il pacchetto è già stato costruito
anche per quell'architettura, è necessario richiedere la rimozione
dall'archivio del vecchio pacchetto binario per quell'architettura 
altrimenti non sarà possibile far entrare in testing la nuova versione.
Per richiede la rimozione dall'archivio di unstable dei pacchetti relativi
all'architettura che è stata rimossa si deve inserire un bug verso
<q>ftp.debian.org</q>; come forma di cortesia è buona norma inviare un
avviso anche alla lista relativa al port.</p>

<h3><q>Ci sono eccezioni? <tt>acmefoo</tt> è stato inserito in <q>testing</q>
anche se non soddisfa tutti i criteri richiesti.</q></h3>

<p>I responsabili del rilascio possono trasgredire le regole in due modi:</p>

<ul>
  <li>Possono decidere che le rotture delle dipendenze provocate
      dall'installazione di una nuova libreria miglioreranno la situazione
	  invece che peggiorarla e procederanno con le loro piccole flotte di
	  dipendenze.</li>
  <li>Possono anche rimuovere da <q>testing</q> manualmente i pacchetti che
      sarebbero danneggiati, così che nuovi elementi possano essere installati.</li>
</ul>

<h3><q>Si può avere un esempio reale, non banale?</q></h3>

<p>Eccone uno: quando il pacchetto sorgente <tt>apache</tt> viene installato in
<q>testing</q>, insieme con i propri pacchetti binari <tt>apache</tt>,
<tt>apache-common</tt>, <tt>apache-dev</tt> e <tt>apache-doc</tt>, la
precedente versione è disinstallata.</p>

<p>Tuttavia, tutti i moduli di Apache dipendono da <code>apache-common (&gt;=
<var>qualcosa</var>), apache-common (&lt;&lt; <var>qualcosa</var>)</code>,
così che questo cambiamento romperà tutte queste dipendenze. In conseguenza,
tutti i moduli di Apache dovranno essere ricompilati con la nuova versione di
Apache perché <q>testing</q> sia aggiornata.</p>

<p>Continuiamo nella nostra analisi: dopo che tutti i moduli sono stati
aggiornati in unstable per funzionare con un nuovo Apache, gli script di
<q>testing</q> provano <tt>apache-common</tt> e trovano che rompe le dipendenze
di tutti i moduli di Apache perché questi hanno <code>Depends: apache-common
(&lt;&lt; <var>la versione attuale</var>)</code>, e quando poi provano
<tt>libapache-<var>foo</var></tt> trovano che non si installa perché ha
<code>Depends: apache-common (&gt;=<var>la nuova versione</var>)</code>.</p>

<p>Tuttavia, in seguito gli script useranno una logica differente (qualche
volta suggerita da un intervento manuale): essi ignoreranno il fatto che
<tt>apache-common</tt> rompe le dipendenze, e continueranno con le cose che
funzionano; se continuerà a non funzionare dopo che noi abbiamo fatto tutto
il possibile, tanto peggio, ma forse <strong>funzionerà</strong>. In seguito
proveranno casualmente tutti i pacchetti <tt>libapache-<var>foo</var></tt>
e vedranno che in effetti funzionano.</p>

<p>Dopo che tutto è stato provato, essi controllano quanti pacchetti hanno
dipendenze rotte, verificano se è meglio o peggio rispetto alla situazione
iniziale e o accettano tutto o non ci pensano più. Lo vedrete in
<tt>update_output.txt</tt> sulle righe <q><code>recur:</code></q>.</p>

<p>Per esempio:</p>

<pre>
         recur: [<var>foo</var> <var>bar</var>] <var>baz</var>
</pre>

<p>dice grosso modo <q>ho trovato che <var>foo</var> e
<var>bar</var> migliorano la situazione, ora provo <var>baz</var> per
vedere cosa succede, anche se rompe qualche dipendenza</q>. Le righe di
<tt>update_output.txt</tt> che iniziano con <q><code>accepted</code></q> indicano
elementi che sembrano migliorati, e le linee <q><code>skipped</code></q> elementi
peggiorati.</p>

<h3><q>Il file <tt>update_output.txt</tt> è completamente illeggibile!</q></h3>

<p>Questa non è una domanda. ;-)</p>

<p>Facciamo un esempio:</p>

<pre>
 skipped: cln (0) (150+4)
     got: 167+0: a-40:a-33:h-49:i-45
     * i386: ginac-cint, libginac-dev
</pre>

<p>Questo significa che se <tt>cln</tt> entra in <q>testing</q>, <tt>ginac-cint</tt>
e <tt>libginac-dev</tt> divengono non installabili in <q>testing</q> su i386.
Da notare che le architetture sono controllate in ordine alfabetico e sono
evidenziati solo i problemi relativi alla prima architettura con problemi
&mdash; ecco perché l'architettura alfa compare così spesso.</p>

<p>La riga <q>got</q> include il numero di problemi in <q>testing</q> sulle
differenti architetture (fino alla prima architettura dove si evidenzi un
problema &mdash; vedi sopra). <q>i-45</q> significa che se <tt>cln</tt>
entrasse in <q>testing</q>, ciò comporterebbe che 45 pacchetti non sarebbero
installabili su i386. Qualche annotazione sopra e sotto <tt>cln</tt> segnala
che ci sono 43 pacchetti non installabili in <q>testing</q> su i386 al
momento.</p>

<p>La riga <q>skipped: cln (0) (150+4)</q> significa che rimangono 150
pacchetti da verificare dopo questo pacchetto fino a che questo controllo di
tutti i pacchetti sia completato, e che sono stati già trovati 4 pacchetti
che non possono essere aggiornati perché romperebbero delle dipendenze. Lo
<q>(0)</q> è irrilevante, può essere tranquillamente ignorato.</p>

<p>È da notare che vi sono parecchi controlli di tutti i pacchetti durante
una singola esecuzione dello script <q>testing</q>.</p>

<p><em>Jules Bean ha inizialmente raccolto le domande/risposte frequenti.</em></p>
# Created: Sat Dec  8 12:44:29 GMT 2001

<h2>Informazioni aggiuntive</h2>

<p>Le seguenti pagine forniscono ulteriori informazioni sullo stato attuale di
testing e sulla migrazione dei pacchetti da unstable a testing:</p>

<ul>
<li>Statistiche riguardo ai pacchetti binari non aggiornati in
<a href="https://release.debian.org/britney/testing_outdate.txt">testing</a> e
<a href="https://release.debian.org/britney/stable_outdate.txt">stable</a></li>

<li>Problemi con le dipendenze in 
<a href="https://qa.debian.org/debcheck.php?list=INDEX&amp;dist=testing">testing</a>
e <a href="https://qa.debian.org/debcheck.php?list=INDEX&amp;dist=stable">stable</a></li>
</ul>

<p>Potreste essere interessati a leggere una vecchia
<a href="https://lists.debian.org/debian-devel-0008/msg00906.html">email di spiegazione</a>.
Il suo unico difetto è di non tener conto dell'organizzazione in pool dei pacchetti,
poiché questa è stata realizzata da James Troup dopo che l'email fu scritta.</p>

<p>Il codice di testing è disponibile su
<a href="https://release.debian.org/britney/update_out_code/">ftp-master</a>.</p>

<p><em>Anthony Towns è l'autore dell'implementazione di testing.</em></p>