La distribuzione Debian testing

Per informazioni di base sulla distribuzione testing, destinate al semplice utente, si vedano le FAQ Debian.

È importante richiamare l'attenzione sia dei normali utenti che degli sviluppatori sul fatto che gli aggiornamenti di sicurezza per testing non sono gestiti dal gruppo di sicurezza. Per maggiori informazioni si vedano le FAQ del gruppo di sicurezza.

Questa pagina tratta essenzialmente gli aspetti di testing importanti per gli sviluppatori Debian.

Come funziona testing

La distribuzione testing è una distribuzione generata automaticamente a partire dalla distribuzione unstable 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.

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

  1. Deve essere stato in unstable per 10, 5 o 2 giorni, in funzione dell'urgenza dell'upload;
  2. Deve essere stato compilato e deve essere aggiornato su tutte le architetture su cui sia stato compilato in unstable;
  3. Non deve avere bug release-critical applicabili alla versione attualmente in testing (si veda sotto per maggiori informazioni);
  4. Tutte le sue dipendenze devono o essere soddisfatte dai pacchetti già in testing o essere soddisfatte dall'insieme di pacchetti che verranno installati nel contempo;
  5. L'operazione di installazione del pacchetto in testing non dovrà danneggiare alcun pacchetto già in testing. (Si veda sotto per maggiori informazioni.)

Un pacchetto che soddisfi le prime tre condizioni scritte sopra è un Valido Candidato.

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

Domande/Risposte frequenti

Quali sono i bug critici per il rilascio e come vengono contati?

Tutti i bug con un alto livello di gravità vengono catalogati come release-critical; attualmente sono i bug critical, grave e serious.

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 testing, e di conseguenza non sarà rilasciato in stable.

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

Come può l'installazione di un pacchetto in testing danneggiare il funzionamento di altri pacchetti?

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 acmefoo è installato in testing, insieme con i suoi pacchetti binari acme-foo-bin, acme-bar-bin, libacme-foo1 e libacme-foo-dev, la versione precedente viene rimossa.

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

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 ==, <= o << delle dipendenze versioned, ovvero dipendenze per determinate versioni.

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 testing danneggia tutti i pacchetti che ne dipendono in testing, è 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.

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

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

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

Ricordarsi delle dipendenze del proprio pacchetto. Supponiamo che il proprio pacchetto dipenda da libtool, o libltdlX, il pacchetto non entrerà in testing sino a quando la versione corretta di libtool non sia pronta ad entrarci insieme.

Insomma, ciò non avverrà sino a quando l'installazione di libtool danneggiarà ciò che è già in testing. In altre parole, sino a quando tutti gli altri pacchetti che dipendono da libltdlY (dove Y è 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 testing.

Qui può venir utile l'output testuale [compresso con gzip:]: esso offre informazioni (sebbene molto concise) su quali pacchetti vengono danneggiati quando un valido candidato è aggiunto in testing (vedere la Developer's Reference per maggiori dettagli).

Perché è spesso difficile inserire pacchetti Architecture: all in testing?

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

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

Un pacchetto è bloccato perché è non aggiornato su qualche architettura. Cosa devo fare?

Controllare lo stato del proprio pacchetto sul log del database di costruzione. Se il pacchetto non viene costruito, sarà segnato come failed; analizzare i log di costruzione e correggere tutti i problemi presenti nei sorgenti del pacchetto.

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

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 in attesa di costruzione.

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 coninvolto se tale indirizzo è fornito sulla pagina web del port oppure alla mailing list del port.

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 ftp.debian.org; come forma di cortesia è buona norma inviare un avviso anche alla lista relativa al port.

Ci sono eccezioni? acmefoo è stato inserito in testing anche se non soddisfa tutti i criteri richiesti.

I responsabili del rilascio possono trasgredire le regole in due modi:

Si può avere un esempio reale, non banale?

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

Tuttavia, tutti i moduli di Apache dipendono da apache-common (>= qualcosa), apache-common (<< qualcosa), 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é testing sia aggiornata.

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

Tuttavia, in seguito gli script useranno una logica differente (qualche volta suggerita da un intervento manuale): essi ignoreranno il fatto che apache-common 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 funzionerà. In seguito proveranno casualmente tutti i pacchetti libapache-foo e vedranno che in effetti funzionano.

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 update_output.txt sulle righe recur:.

Per esempio:

         recur: [foo bar] baz

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

Il file update_output.txt è completamente illeggibile!

Questa non è una domanda. ;-)

Facciamo un esempio:

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

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

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

La riga skipped: cln (0) (150+4) 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 (0) è irrilevante, può essere tranquillamente ignorato.

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

Jules Bean ha inizialmente raccolto le domande/risposte frequenti.

Informazioni aggiuntive

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

Potreste essere interessati a leggere una vecchia email di spiegazione. 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.

Il codice di testing è disponibile su ftp-master.

Anthony Towns è l'autore dell'implementazione di testing.