Capitolo 5. Gestione dei pacchetti

Indice

5.1. Nuovi pacchetti
5.2. Registrare i cambiamenti nel pacchetto
5.3. Testare del pacchetto
5.4. Struttura del pacchetto sorgente
5.5. Scegliere una distribuzione
5.5.1. Caso particolare: caricamenti sulle distribuzioni stable e oldstable
5.5.2. Caso particolare: caricamenti su testing/testing-proposed-updates
5.6. Caricare un pacchetto
5.6.1. Caricamento su ftp-master
5.6.2. Caricamenti differiti
5.6.3. Caricamenti di sicurezza
5.6.4. Altre code di caricamento
5.6.5. Notifica che un nuovo pacchetto è stato installato
5.7. Specificare la sezione del pacchetto, sottosezione e la priorità
5.8. Gestione dei bug
5.8.1. Monitoraggio dei bug
5.8.2. Rispondere ai bug
5.8.3. Pulizia dei bug
5.8.4. Quando i bug vengono chiusi da nuovi upload
5.8.5. Gestione di bug relativi alla sicurezza
5.8.5.1. The Security Tracker
5.8.5.2. Riservatezza
5.8.5.3. Avvisi di sicurezza
5.8.5.4. Preparazione di pacchetti per indirizzare i problemi di sicurezza
5.8.5.5. Caricamento del pacchetto corretto
5.9. Lo spostamento, la rimozione, la ridenominazione, l'adozione, e rendere orfani i pacchetti
5.9.1. Spostare i pacchetti
5.9.2. Rimozione dei pacchetti
5.9.2.1. Rimozione di pacchetti da Incoming
5.9.3. La sostituzione o la ridenominazione dei pacchetti
5.9.4. Pacchetto orfano
5.9.5. L'adozione di un pacchetto
5.9.6. Reintrodurre pacchetti
5.10. Fare port e port del proprio lavoro
5.10.1. Siate gentili con gli autori di port
5.10.2. Linee guida per i caricamenti degli autori di port
5.10.2.1. Ricompilazione o NMU dei soli binari
5.10.2.2. Quando fare un NMU del sorgente se si è un autore di port
5.10.3. Infrastrutture e automazione per il port
5.10.3.1. Mailing list e pagine web
5.10.3.2. Strumenti per gli autori di port
5.10.3.3. wanna-build
5.10.4. Quando il pacchetto non è portabile
5.10.5. Marcare i pacchetti non-free come compilabili automaticamente
5.11. Caricamenti dei Non-Maintainer (NMU)
5.11.1. Quando e come fare un NMU
5.11.2. NMU e debian/changelog
5.11.3. Utilizzare la coda DELAYED/
5.11.4. NMU dal punto di vista del maintainer
5.11.5. Source NMUs vs Binary-only NMUs (binNMUs)
5.11.6. NMU e caricamenti di QA
5.11.7. NMU e caricamenti del team
5.12. La manutenzione collaborativa
5.13. La distribuzione testing
5.13.1. Nozioni di base
5.13.2. Aggiornamenti da unstable
5.13.2.1. Obsoleti
5.13.2.2. Rimozioni da testing
5.13.2.3. Dipendenze circolari
5.13.2.4. Influenza del pacchetto in testing
5.13.2.5. Dettagli
5.13.3. Aggiornamenti diretti di testing
5.13.4. Domande frequenti
5.13.4.1. Quali sono i bug critici per il rilascio e come vengono contati?
5.13.4.2. Come potrebbe l'installazione di un pacchetto in testing rendere difettosi altri pacchetti?

Questo capitolo contiene informazioni relative alla creazione, al caricamento, al mantenimento, ed al porting dei pacchetti.

Se si desidera creare un nuovo pacchetto per la distribuzione Debian, si dovrebbe verificare prima l'elenco Work-Needing and Prospective Packages (WNPP). Il controllo dell'elenco WNPP assicura che nessuno stia già lavorando sulla pacchettizzazione del software, e che lo sforzo non sia duplicato. Si leggano le pagine web WNPP per ulteriori informazioni.

Supponendo che nessun altro stia già lavorando sul proprio futuro pacchetto, è necessario poi presentare una segnalazione di bug (Sezione 7.1, «Segnalare i bug») nei confronti dello pseudo-pacchetto wnpp descrivendo come si vuole procedere per creare un nuovo pacchetto, includendo, senza limitarsi ad essa, una descrizione del medesimo, la licenza del futuro pacchetto, e l'URL corrente da dove è possibile scaricarlo.

Si consiglia di impostare l'oggetto del bug a ITP: foo -- breve descrizione , sostituendo il nome del nuovo pacchetto in foo. La gravità della segnalazione di bug deve essere impostata su wishlist. Inviare una copia a , utilizzando l'intestazione X-Debbugs-CC (non usare CC:, perché in questo modo il soggetto del messaggio non indicherà il numero di bug). Se si stanno pacchettizzando tanti nuovi pacchetti (> 10) tale che notificare alla mailing list con messaggi separati sia troppo dirompente, si invii invece un riepilogo dopo aver depositato i bug nella lista debian-devel. Questo informerà gli altri sviluppatori sui prossimi pacchetti e consentirà una revisione della vostra descrizione e nome del pacchetto.

Inserire una voce Closes: #nnnnn nel changelog del nuovo pacchetto per la segnalare di bug da chiudere automaticamente una volta che il nuovo pacchetto è installato in archivio (si consulti Sezione 5.8.4, «Quando i bug vengono chiusi da nuovi upload»).

Se si pensa che il proprio pacchetto abbia bisogno di alcune spiegazioni per gli amministratori della coda NEW dei pacchetti, includerle nel proprio changelog, inviare a una risposta alla email ricevuta come maintainer dopo il proprio caricamento, o rispondere alla email di rifiuto in caso si stia già effettuando nuovamente il caricamento.

Nel chiudere i bug di sicurezza includete i numeri CVE come Closes: #nnnnn. Questo è utile al il team di sicurezza per monitorare le vulnerabilità. Se un caricamento è fatto per risolvere il bug prima che l'ID della segnalazione fosse noto, è buona norma aggiornare la voce storica del changelog con il successivo caricamento. Anche in questo caso, Includere tutti i puntatori alle informazioni di fondo nella voce originale del changelog.

Ci sono una serie di motivi per cui chiediamo ai maintainer di dichiarare le loro intenzioni:

  • Aiuta il maintainer (potenzialmente nuovo) ad attingere all'esperienza di persone sulla lista, e permette loro di sapere se qualcun altro sta già lavorando su di esso.

  • Esso consente ad altre persone di pensare se lavorare sul pacchetto sapendo che c'è già un volontario, così gli sforzi possono essere condivisi.

  • Consente al resto dei maintainer di sapere di più sul pacchetto rispetto alla riga di descrizione e alla solita voce del changelog «Initial release» che viene inviata alla .

  • È utile per le persone che vivono fuori unstable (e che formano la nostra prima linea di tester). Dovremmo incoraggiare queste persone.

  • Gli annunci danno ai maintainer e ad altre parti interessate una migliore sensazione di ciò che sta accadendo, e cosa c'è di nuovo, nel progetto.

Consultare http://ftp-master.debian.org/REJECT-FAQ.html sui comuni motivi di rifiuto per un nuovo pacchetto.

Le modifiche apportate al pacchetto devono essere registrate nel debian/changelog. Questi cambiamenti dovrebbero fornire una descrizione concisa di ciò che è stato modificato, del perché (se è in dubbio), e annotare se qualche bug è stato chiuso. Devono anche registrare quando il pacchetto è stato completato. Questo file verrà installato in /usr/share/doc/package/changelog.Debian.gz, o /usr/share/doc/package/changelog.gz per i pacchetti nativi.

Il debian/changelog si adegua ad una certa struttura, con una serie di campi differenti. Un campo di nota, la distribuzione, è descritto in Sezione 5.5, «Scegliere una distribuzione». Maggiori informazioni sulla struttura di questo file si trovano nella sezione della Debian Policy intitolata debian/changelog.

Le voci del changelog possono essere usate per chiudere automaticamente i bug Debian quando il pacchetto viene installato nell'archivio. Si consulti Sezione 5.8.4, «Quando i bug vengono chiusi da nuovi upload».

È convenzione che la voce del changelog di un pacchetto che contiene una nuova versione originale del software è la seguente:

 * New upstream release.

Ci sono strumenti che consentono di creare voci e di finalizzare il changelog per la stampa - si consulti Sezione A.6.1, «devscripts» e Sezione A.6.5, «dpkg-dev-el».

Si consulti anche Sezione 6.3, «Buone pratiche per il debian/changelog».

Prima di caricare il proprio pacchetto, si dovrebbe fare dei test di base su di esso. Come minimo, si dovrebbe provare le seguenti attività (è necessario avere una versione precedente dello stesso pacchetto Debian in giro):

Ci sono due tipi di pacchetto sorgente Debian:

  • i cosiddetti pacchetti nativi, dove non c'è distinzione tra i sorgenti originali e le patch applicate per Debian

  • i (più comuni) pacchetti dove c'è un file di archivio dei sorgenti originali accompagnato da un altro file che contiene le modifiche apportate da Debian

Per i pacchetti nativi, il pacchetto sorgente include un file di controllo del codice sorgente Debian (.dsc) e l'archivio dei sorgenti (.tar.{gz,bz2,xz}). Un pacchetto sorgente di un pacchetto non nativo include un file Debian di controllo sorgenti, l'archivio dei sorgenti originali (.orig.tar.{gz,bz2,xz}) e le modifiche Debian (.diff.gz per il formato sorgente «1.0» o .debian.tar.{gz,bz2,xz} per il formato sorgente «3.0 (quilt)»).

Con il formato dei sorgenti «1.0», se un pacchetto è nativo o non è stato determinato da dpkg-source al momento della compilazione. Al giorno d'oggi, si raccomanda di essere espliciti sul formato sorgente desiderato mettendo entrambi «3.0 (quilt)» o «3.0 (nativo)» in debian/source/format. Il resto di questa sezione riguarda solo i pacchetti non-nativi.

La prima volta che viene caricata una versione che corrisponde ad una particolare versione originale, il file tar dei sorgenti originali deve essere caricato e incluso nel .changes. In seguito, questo stesso file tar deve essere utilizzato per costruire i nuovi file diff e .dsc, e non avrà bisogno di essere nuovamente caricato.

Per impostazione predefinita, dpkg-genchanges e dpkg-buildpackage includerà il file tar dei sorgenti originali, se e solo se l'attuale voce del changelog ha una versione originale diversa dalla voce precedente. Questo comportamento può essere modificato utilizzando -sa per includere sempre o -sd per lasciarlo sempre fuori.

Se nessun sorgente originale è incluso nel caricamento, il file tar dei sorgenti originali utilizzato da dpkg-source quando fu costruito il file .dsc e diff da caricare deve essere del tutto identico a quello già presente in archivio.

Notare che, in pacchetti non nativi, i permessi per i file che non sono presenti nel *.orig.tar.{gz,bz2,xz} non saranno conservati, così come diff non memorizza i permessi dei file nella patch. Tuttavia, quando si usa il formato sorgente «3.0 (quilt)», i permessi dei file all'interno della cartella debian sono conservati dal momento che sono memorizzati in un archivio tar.

Ogni caricamento deve specificare a quale distribuzione il pacchetto è destinato. Il processo di compilazione del pacchetto estrae questa informazione dalla prima riga del debian/changelog e la inserisce nel campo Distribution del file .changes.

I pacchetti sono generalmente caricati in unstable. I caricamenti in unstable o experimental dovrebbero utilizzare questi nomi nelle voci del changelog; caricamenti per altre suite dovrebbero utlizzare il nome della suite, in modo da evitare ambiguità.

In realtà, ci sono altre due possibili distribuzioni: stable-security e testing-security, ma si legga Sezione 5.8.5, «Gestione di bug relativi alla sicurezza» per ulteriori informazioni su queste ultime.

Non è possibile caricare un pacchetto in più distribuzioni contemporaneamente.

Uploading to stable means that the package will be transferred to the proposed-updates-new queue for review by the stable release managers, and if approved will be installed in the stable-proposed-updates directory of the Debian archive. From there, it will be included in stable with the next point release.

Per assicurarsi che il caricamento sarà accettato, si dovrebbe discutere le modifiche con il team del rilascio stabile prima di caricare. Per questo, segnalare un bug relativo allo pseudo-pacchetto release.debian.org utilizzando reportbug, includendo la patch che si desidera applicare alla versione del pacchetto attualmente in stable. Si sia sempre prolissi e dettagliati nelle voci del changelog per i file caricati sulla distribuzione stable.

Particolare attenzione dovrebbe essere posta durante il caricamento in stable. In sostanza, un pacchetto deve essere caricato solo per stable se si verifica una delle seguenti circostanze:

  • un problema di funzionalità davvero critica

  • il pacchetto diventa non installabile

  • una architettura rilasciata necessita del pacchetto

In passato, caricamenti in stable sono stati utilizzati per risolvere anche problemi di sicurezza. Tuttavia, questa pratica è sconsigliata, dato che i caricamenti utilizzati per la sicurezza di Debian vengono copiati automaticamente nell'appropriato archivio proposed-updates quando l'avviso viene rilasciato. Per informazioni dettagliate sulla gestione dei problemi di sicurezza si consulti Sezione 5.8.5, «Gestione di bug relativi alla sicurezza». Se i team di sicurezza ritengono che il problema sia troppo benevolo per essere risolto attraverso una DSA, i gestori del rilascio stable di solito sono disposti a includere comunque la correzione in un normale caricamento su stable.

Cambiare qualsiasi altra cosa nel pacchetto che non sia importante è sconsigliato, perché anche correzioni banali possono successivamente causare errori.

I pacchetti caricati su stable necessitano di essere compilati su sistemi che eseguono stable, in modo che le loro dipendenze siano limitate alle librerie (ed altri pacchetti) disponibili in stable; per esempio, un pacchetto caricato in stable che dipende da un pacchetto di libreria che esiste solo in unstable sarà respinto. Apportare modifiche alle dipendenze di altri pacchetti (modificando i file Provides o shlibs), eventualmente rendendo quegli altri pacchetti non installabili, è decisamente sconsigliato.

caricamenti su distribuzioni oldstable sono possibili a patto che non siano state archiviate. Valgono le stesse regole per stable.

Per caricare un pacchetto, è necessario caricare i file (incluse le modifiche firmate e i file .dsc) con ftp anonimo su ftp.upload.debian.org nella cartella /pub/UploadQueue/. Per ottenere che i file vengano processati, devono essere firmati con una chiave del portachiavi dei Developer Debian o dei Debian Maintainer (si veda https://wiki.debian.org/DebianMaintainer).

Notare che è necessario trasferire il file delle modifiche alla fine. In caso contrario, il caricamento potrebbe essere respinto in quanto il software di mantenimento analizzerà il file delle modifiche e noterà che non tutti i file sono stati caricati.

È inoltre possibile trovare i pacchetti Debian dupload o dput utili quando si caricano i pacchetti. Questi comodi programmi aiutano ad automatizzare il processo di caricamento dei pacchetti in Debian.

Per la rimozione di pacchetti, si consulti ftp://ftp.upload.debian.org/pub/UploadQueue/README e il pacchetto Debian dcut.

A volte è utile caricare immediatamente un pacchetto, ma si desidera che quest'ultimo arrivi nell'archivio solo dopo qualche giorno. Ad esempio, quando si prepara un Non-Maintainer Upload, si potrebbe desiderare di dare al maintainer qualche giorno per reagire.

Un caricamento nella cartella differita fa mantenere il pacchetto nella coda caricamenti differiti. Quando il tempo di attesa specificato è terminato, il pacchetto viene spostato nella cartella regolare incoming per l'elaborazione. Questo viene fatto attraverso il caricamento di ftp.upload.debian.org nella cartella di caricamento DELAYED/X-day (X tra 0 e 15). 0-day viene caricato più volte al giorno in ftp.upload.debian.org.

Con dput, è possibile utilizzare il parametro --delayed DELAY per mettere il pacchetto in una delle code.

Vi è una coda di caricamento alternativa in Europa a ftp://ftp.eu.upload.debian.org/pub/UploadQueue/. Funziona allo stesso modo come ftp.upload.debian.org, ma dovrebbe essere più veloce per gli sviluppatori europei.

I pacchetti possono anche essere caricati via ssh al ssh.upload.debian.org; i file devono essere messi in /srv/upload.debian.org/UploadQueue. Questa coda non supporta caricamenti differiti.

I campi Section e Priority del file debian/control in realtà non specificano dove il file verrà inserito nell'archivio, né la sua priorità. Al fine di mantenere l'integrità complessiva dell'archivio, sono i maintainer dell'archivio che hanno il controllo su questi campi. I valori del file debian/control sono in realtà solo suggerimenti.

I maintainer dell'archivio mantengono traccia delle sezioni e delle priorità canoniche per i pacchetti presenti nel file override. Se c'è una disparità tra il file override e campi del pacchetto come indicato in debian/control, allora si riceverà una email che sottolinerà la divergenza nel momento in cui il pacchetto viene installato nell'archivio. È possibile correggere il filedebian/control per il successivo caricamento, oppure si potrebbe desiderare di fare un cambiamento nel file di override.

Per modificare la sezione attuale nella quale il pacchetto è stato inserito, è necessario prima assicurarsi che il debian/control nel pacchetto sia preciso. Successivamente, si crei un bug su ftp.debian.org chiedendo che la sezione o la priorità per il pacchetto siano modificati dalla vecchia sezione o priorità a quella nuova. Si utilizzi un Subject del tipo override: Package1: sezione/priorità, [...], PACKAGEX: sezione/priorità, e includere la motivazione per la modifica nel corpo della segnalazione del bug.

Per ulteriori informazioni sugli file di override, si consulti dpkg-scanpackages(1) e https://www.debian.org/Bugs/Developer#maintincorrect.

Si noti che il campo Section descrive sia la sezione che la sottosezione, che sono descritti nella Sezione 4.6.1, «Sezioni». Se la sezione è la principale, dovrebbe essere omessa. L'elenco delle sottosezioni ammissibili può essere trovato in https://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections.

Ogni sviluppatore deve essere capace di lavorare con il Debian bug tracking system. Questo implica la conoscenza di come creare propriamente le segnalazioni di bug (si consulti Sezione 7.1, «Segnalare i bug»), di come modificarli e riordinarli, e di come processarli e chiuderli.

Le caratteristiche del sistema di tracciamento dei bug sono descritte nella documentazione BTS per gli sviluppatori. Questo include la chiusura bug, l'invio di messaggi di riepilogo, l'assegnazione dei livelli di gravità e tag, il marcare i bug come inoltrati, e altre questioni.

Operazioni quali la riassegnazione di bug ad altri pacchetti, fondendo le segnalazioni di bug separate sullo stesso problema, o la riapertura di bug quando sono chiusi prematuramente, vengono gestite utilizzando il cosiddetto server di controllo di posta elettronica. Tutti i comandi disponibili su questo server sono descritti nella documentazione del server di controllo BTS .

Se si vuole essere un buon maintainer, si dovrebbe verificare periodicamente il Debian bug tracking system (BTS) per i propri pacchetti. Il BTS contiene tutti i bug aperti per i propri pacchetti. È possibile controllarli sfogliando questa pagina: http://bugs.debian.org/yourlogin@debian.org.

I maintainer interagiscono con le BTS attraverso indirizzi di posta elettronica a bugs.debian.org. La documentazione sui comandi disponibili può essere trovata su , oppure, se è stato installato il pacchetto doc-debian, è possibile guardare i file locali /usr/share/doc/debian/bug-*.

Alcuni trovano utile avere rapporti periodici sul bug aperti. È possibile aggiungere un processo di cron come segue, se si vuole ottenere una email settimanale che illustra tutti i bug aperti per i propri pacchetti:

# ask for weekly reports of bugs in my packages
0 17 * * fri   echo "index maint address" | mail request@bugs.debian.org

Sostituite address con il proprio indirizzo ufficiale di maintainer Debian.

Quando si risponde ad un bug, fare in modo che ogni discussione che si ha sui bug venga inviata sia al mittente originario del bug, e per il bug stesso (ad esempio, ). Se si sta scrivendo un nuovo messaggio e non si ricorda l'indirizzo di posta elettronica del mittente, è possibile utilizzare l'email per contattare il mittente e per registrare la propria posta dentro il log del bug (il che significa che non è necessario inviare una copia della email a ).

Se si ottiene un bug che cita FTBFS, questo significa non si riesce a compilare dai sorgenti. Gli autori dei port utilizzano spesso questo acronimo.

Una volta che si è affrontata una segnalazione di bug (e.g. correggendolo), lo si contrassegni come done (lo si chiuda) con l'invio di un messaggio di spiegazione a . Se si sta correggendo un bug modificando e caricando il pacchetto, è possibile automatizzare la chiusura del bug come descritto in Sezione 5.8.4, «Quando i bug vengono chiusi da nuovi upload».

Mai si dovrebbe chiudere un bug tramite il comando del bug server close inviato a . Se lo fate, il mittente originale non riceverà alcuna informazione sul perché il bug è stato chiuso.

Come maintainer del pacchetto, spesso si trovano bug in altri pacchetti o si hanno bug segnalati sui propri pacchetti ma che in realtà sono bug di altri pacchetti. Le caratteristiche del sistema di tracciamento dei bug sono descritte nella documentazione BTS per gli sviluppatori Debian. Operazioni come la riassegnazione, l'unione e segnalazioni di bug, l'etichettatura sono descritte nella BTS control server documentation. Questa sezione contiene alcune linee guida per la gestione dei propri bug, sulla base dell'esperienza collettiva degli sviluppatori Debian.

Segnalare bug per problemi che si trovano in altri pacchetti è uno dei doveri civici di maintainer, si consulti Sezione 7.1, «Segnalare i bug» per i dettagli. Tuttavia, la gestione dei bug nei propri pacchetti è ancora più importante.

Ecco un elenco di passaggi che si possono seguire per gestire una segnalazione di errore:

  1. Decidere se la segnalazione corrisponde ad un vero e proprio bug o meno. A volte gli utenti invocano un programma nel modo sbagliato perché non hanno letto la documentazione. Se la diagnosi è questa, basta chiudere il bug con informazioni sufficienti per consentire agli utenti di correggere il loro problema (dare indicazioni sulla buona documentazione e così via). Se la stessa segnalazione viene presentata più e più volte ci si potrebbe chiedere se la documentazione sia sufficiente o se il programma non rilevi il suo cattivo uso al fine di fornire un messaggio di errore. Questo è un problema che può aver bisogno di essere risolto con l'autore originale.

    Se il mittente del bug non è d'accordo con la vostra decisione di chiuderlo, può riaprirlo fino a quando non si trovi un accordo su come gestirlo. Se non si trova, si consiglia di contrassegnare il bug wontfix, per far sapere che il bug esiste ma che non sarà corretto. Se questa situazione è inaccettabile, il maintainer (o il mittente) può richiedere una decisione del comitato tecnico riassegnando il bug a tech-ctte (si può usare il comando clone del BTS se si desidera tenerlo riportato sul pacchetto). Prima di procedere, leggere le recommended procedure.

  2. Se il bug è reale ma è causato da un altro pacchetto, basta riassegnare il bug al pacchetto giusto. Se non si sa a quale pacchetto dovrebbe essere riassegnato, si dovrebbe chiedere aiuto su IRC o su . Informare il maintainer del pacchetto al quale si riassegna il bug, per esempio mettendo in Cc: al messaggio che fa la riassegnazione a e spiegando le proprie motivazioni nel corpo della email. Si noti che una semplice riassegnazione non è inviata ai maintainer del pacchetto al quale viene riassegnato, quindi non avranno modo di saperlo fino a quando consulteranno la panoramica dei bug per i loro pacchetti.

    Se il bug interessa il funzionamento del proprio pacchetto, si consideri di clonare il bug e di riassegnarlo al pacchetto che realmente provoca il comportamento. In caso contrario, il bug non verrà mostrato nella lista dei bug del proprio pacchetto, inducendo gli utenti a segnalare lo stesso problema più e più volte. Si dovrebbe bloccare «il proprio» bug con il bug riassegnato, clonato per documentare la relazione.

  3. A volte è necessario anche per regolare la gravità del bug in modo che corrisponda alla propria definizione di gravità. Questo perché le persone tendono a gonfiare la gravità dei bug per assicurarsi che i loro bug siano risolti rapidamente. Alcuni bug possono anche essere lasciati con gravità wishlist quando il cambiamento richiesto è solo estetico.

  4. Se il bug è reale, ma lo stesso problema è già stato segnalato da qualcun altro, allora le due segnalazioni di bug rilevanti dovrebbero essere fuse in una sola utilizzando il comando merge del BTS. In questo modo, quando il bug viene corretto, tutti i mittenti ne saranno informati. (Si noti, tuttavia, che i messaggi di posta elettronica inviati al mittente di un solo bug non saranno automaticamente inviati al mittente dell'altra segnalazione.) Per maggiori dettagli sui tecnicismi del comando merge e simili, il comando unmerge, si consulti la documentazione del server di controllo BTS.

  5. Il mittente del bug potrebbe aver dimenticato di fornire alcune informazioni, nel qual caso si deve chiedergli le informazioni necessarie. A tal proposito è possibile marcare il bug con il tag moreinfo. Inoltre se non è possibile riprodurre il bug, lo si etichetta come unreproducible. Chiunque può riprodurre il bug è allora invitato a fornire ulteriori informazioni su come riprodurlo. Dopo pochi mesi, se queste informazioni non sono state inviate da nessuno, il bug può essere chiuso.

  6. Se il bug è legato alla pacchettizzazione, basta risolvere il problema. Se non si è in grado di risolverlo da soli, allora si contrassegni il bug come help. Si può anche chiedere aiuto su o . Se è un problema che riguarda il software originale, è necessario inoltrarlo all'autore originale. L'inoltro di un bug non è sufficiente, è necessario controllare ad ogni rilascio se il bug è stato risolto o meno. Se lo è, basta chiuderlo, altrimenti si deve ricordarlo all'autore. Se si hanno le competenze necessarie si può preparare una patch che corregge il bug e inviarla all'autore allo stesso tempo. Assicurarsi di inviare la patch al BTS e di contrassegnare il bug come patch.

  7. Se è stato sistemato un errore nella copia locale, o se una correzione è stata committata nel repository VCS, è possibile identificare il bug come pending, per far sapere che il bug è stato corretto e che sarà chiuso con il prossimo caricamento (si aggiunga closes: nel changelog). Questo è particolarmente utile se si è in diversi sviluppatori che lavorano sullo stesso pacchetto.

  8. Una volta che un pacchetto corretto è disponibile in archivio, il bug dovrebbe essere chiuso indicando la versione in cui è stato corretto. Questo può essere fatto automaticamente, si consulti Sezione 5.8.4, «Quando i bug vengono chiusi da nuovi upload».

Cosi come bug e problemi sono corretti nei propri pacchetti, è responsabilità del maintainer del pacchetto chiudere questi bug. Tuttavia, non è necessario chiudere un bug fino a quando il pacchetto che corregge il bug è stato accettato nell'archivio Debian. Pertanto, una volta che si ottiene la notifica che il proprio pacchetto aggiornato è stato installato nell'archivio, si può e si deve chiudere il bug nel BTS. Inoltre, il bug dovrebbe essere chiuso con la versione corretta.

Tuttavia, è possibile evitare di dover chiudere manualmente i bug dopo il caricamento - basta elencare i bug corretti nel proprio file debian/changelog, seguendo una certa sintassi, e il software di manutenzione chiuderà il bug. Per esempio:

acme-cannon (3.1415) unstable; urgency=low

 * Frobbed with options (closes: Bug#98339)
 * Added safety to prevent operator dismemberment, closes: bug#98765,
  bug#98713, #98714.
 * Added man page. Closes: #98725.

Tecnicamente parlando, la seguente espressione regolare Perl descrive come i changelog che chiudono dei bug sono identificati:

  /closes:\s*(?:bug)?\#\s*\d+(?:,\s*(?:bug)?\#\s*\d+)*/ig

Noi preferiamo la sintassi closes: #XXX, in quanto è la voce più concisa e più facile da integrare con il testo del changelog. Se non diversamente specificato dal parametro -v- didpkg-buildpackage, solo i bug risolti nella più recente voce del changelog vengono chiusi (in pratica, esattamente i bug menzionati nella parte del changelog nel file .changes vengono chiusi).

Storicamente, i caricamenti individuati come non-maintainer upload (NMU) sono stati contrassegnati come fixed invece di essere chiusi, ma questa pratica è stata cessata con l'avvento del versionamento. Lo stesso vale per il tag fixed-in-experimental.

Se capita di sbagliare un numero di bug o dimenticare un bug nel changelog, non esitare ad annullare qualsiasi danno causato dall'errore. Per riaprire bug erroneamente chiusi, inviare un comando reopen XXX all'indirizzo del sistema di controllo dei bug, . Per chiudere ogni restante bug che è stato corretto dal proprio caricamento, inviare il file .changes per email a , dove XXX è il numero di bug, e mettere Version: YYY e una riga vuota come prime due righe del corpo della email, dove YYY è la prima versione nella quale è stato corretto il bug.

Tenete a mente che non è obbligatorio chiudere i bug utilizzando il changelog come descritto sopra. Se si vuole semplicemente chiudere bug che non hanno nulla a che vedere con un caricamento che si è fatto, lo si faccia inviando tramite email una spiegazione a . Non chiudete bug nella voce del changelog di una versione se le modifiche in quella versione del pacchetto non hanno alcuna attinenza con il bug.

Per informazioni generali su come scrivere i propri contenuti di changelog, si consulti Sezione 6.3, «Buone pratiche per il debian/changelog».

A causa della loro natura sensibile, i bug relativi alla sicurezza devono essere maneggiati con cura. Esiste Debian Security Team per coordinare questa attività, tenendo traccia dei problemi di sicurezza in sospeso, aiutando i maintainer con problemi di sicurezza o sistemandoli loro stessi, inviando avvisi di sicurezza, e mantenendo security.debian.org.

Quando si viene a conoscenza di un bug relativo alla sicurezza in un pacchetto Debian, anche se non si è il maintainer, si raccolga informazioni pertinenti in merito al problema, e si contatti immediatamente il team di sicurezza, preferibilmente presentando il ticket nella propria Request Tracker. Si consulti . In alternativa si può mandare una email . NON FARE L'UPLOAD di pacchetti per stable senza contattare il team. Le informazioni utili comprendono, per esempio:

  • Se il bug è già di dominio pubblico.

  • Quali versioni del pacchetto sono note per essere interessate dal bug. Si controlli ogni versione che è presente in un rilascio supportato di Debian, così come testing e unstable.

  • La natura della correzione, se qualcuna è disponibile (patch sono particolarmente utili)

  • Any fixed packages that you have prepared yourself (send the resulting debdiff or alternatively only the .diff.gz and .dsc files and read Sezione 5.8.5.4, «Preparazione di pacchetti per indirizzare i problemi di sicurezza» first)

  • Qualsiasi tipo di assistenza si è in grado di fornire per aiutare con i test (exploit, test di regressione, etc.)

  • Tutte le informazioni necessarie per la consulenza (si consulti Sezione 5.8.5.3, «Avvisi di sicurezza»)

Come maintainer del pacchetto, si ha la responsabilità di mantenerlo, anche nella versione stabile. Si è nella posizione migliore per valutare le patch e testare i pacchetti aggiornati, quindi consultare le sezioni di seguito su come preparare i pacchetti per il Security Team.

Il team di sicurezza mantiene una banca dati centrale, il Debian Security Tracker. Questa contiene tutte le informazioni pubbliche che sono note sui problemi di sicurezza: quali pacchetti e versioni sono interessate o corrette, e quindi se stable, testing e/o unstable sono vulnerabili. Informazioni che sono ancora confidenziali non vengono aggiunte al tracker.

È possibile cercare per un problema specifico, ma anche sul nome del pacchetto. Cercare il proprio pacchetto per vedere quali problemi sono ancora aperti. Se è possibile, fornire ulteriori informazioni su questi problemi, o di aiutare ad indirizzarli nel proprio pacchetto. Le istruzioni si trovano sulle pagine web del tracker.

A differenza di molte altre attività all'interno di Debian, le informazioni su problemi di sicurezza devono talvolta essere mantenute private per un certo tempo. Questo consente ai distributori di software di coordinare la loro divulgazione al fine di ridurre al minimo l'esposizione dei loro utenti. Se questo è il caso dipende dalla natura del problema e dalla correzione corrispondente, e se è già di dominio pubblico.

Ci sono diversi modi con cui gli sviluppatori possono venire a conoscenza di problemi di sicurezza:

  • è stato notato su un forum pubblico (mailing list, sito web, etc.)

  • qualcuno deposita una segnalazione di bug

  • qualcuno li informa via email privata

Nei primi due casi, l'informazione è pubblica ed è importante avere una correzione il più presto possibile. Nell'ultimo caso, tuttavia, potrebbe non essere una informazione pubblica. In questo caso ci sono alcune possibili opzioni per affrontare il problema:

  • Se l'esposizione di sicurezza è minore, talvolta non è necessario mantenere il problema un segreto e una correzione devrebbe essere fatta e rilasciata.

  • Se il problema è grave, è preferibile condividere le informazioni con altri fornitori e coordinare un rilascio. Il team di sicurezza si mantiene in contatto con le varie organizzazioni e gli individui e può prendersi cura di questo.

In tutti i casi, se la persona che segnala il problema chiede di non divulgarlo, tali richieste devono essere onorate, con l'ovvia eccezione di informare il team di sicurezza in modo che una soluzione possa essere prodotta per un rilascio stabile di Debian. Quando si inviano informazioni riservate al team di sicurezza, ci si assicuri di indicare questo fatto.

Si tenga presente che se è necessaria la segretezza non si può caricare una correzione in unstable (o in qualsiasi altro luogo, come un repository pubblico VCS). Non è sufficiente offuscare i dettagli della modifica, dato che il codice stesso è pubblico, e può (e sarà) esaminato dal pubblico in generale.

Ci sono due motivi per il rilascio di informazioni anche se è richiesto il segreto: il problema è conosciuto da un po', o il problema o l'exploit è diventato pubblico.

Il team di sicurezza ha un PGP-key per abilitare la comunicazione crittografata su questioni delicate. Si consulti la Security Team FAQ per i dettagli.

Gli avvisi di sicurezza vengono rilasciati solo per la corrente, rilasciata distribuzione stabile, e non per testing o unstable. Quando viene rilasciata, gli avvisi vengono inviati alla mailing list e pubblicate sulla pagina web di sicurezza. Gli avvisi di sicurezza sono scritti e pubblicati dal team di sicurezza. Ma di certo non ci restano male se un maintainer è in grado di fornirgli alcune delle informazioni, o scrivere una parte del testo. Le informazioni che devono essere presenti in un avviso comprendono:

  • Una descrizione del problema e il suo campo di applicazione, tra cui:

    • Il tipo di problema (l'escalation dei privilegi, denial of service, etc.)

    • Quali privilegi possono essere acquisiti, e da chi (se alcuni)

    • Come può essere sfruttata

    • Se è sfruttabile da remoto o in locale

    • Come è stato risolto il problema

    Queste informazioni consentono agli utenti di valutare la minaccia per i loro sistemi.

  • Numeri di versione dei pacchetti coinvolti

  • Numeri di versione dei pacchetti corretti

  • Informazioni su dove ottenere i pacchetti aggiornati (di solito dall'archivio di sicurezza di Debian)

  • I riferimenti agli avvisi originali, identificatori CVE, e ogni altra informazione utile nel documentare la vulnerabilità

Un modo con cui si può aiutare il team di sicurezza nei suoi compiti è quello di fornirgli pacchetti corretti adatti per un avviso di sicurezza per il rilascio stabile di Debian.

Nel momento in cui viene eseguito un aggiornamento alla versione stable, deve essere adottata molta cura per evitare di modificare il comportamento del sistema o di introdurre nuovi bug. Per fare questo, si faccia il minor numero di modifiche possibili per risolvere il bug. Gli utenti e gli amministratori si affidano all'esatto comportamento di un rilascio una volta che viene fatto, quindi qualsiasi modifica apportata potrebbe rompere il sistema di qualcuno. Questo è particolarmente vero per le biblioteche: assicurarsi di non modificare l'API o ABI, non importa quanto piccolo sia la modifica.

Ciò significa che il passaggio a una nuova versione originale non è una buona soluzione. Invece, le rilevanti modifiche devono essere adattate alla versione presente nella attuale rilascio stabile di Debian. In generale, i maintainer originali sono disposti ad aiutare se necessario. In caso contrario, il team di sicurezza di Debian può essere in grado di aiutare.

In alcuni casi, non è possibile adattare una correzione di sicurezza, per esempio quando grandi quantità di codice sorgente dovrebbero essere modificate o riscritte. Se questo accade, può essere necessario passare ad una nuova versione. Tuttavia, questo è fatto solo in situazioni estreme, e ci si deve sempre coordinare che con il team della sicurezza.

A questo si collega un'altra importante linea guida: verificare sempre le modifiche. Se si dispone di un exploit, provare e vedere se davvero ha avuto successo sul pacchetto senza patch e fallisce sul pacchetto corretto. Provare altre, anche normali azioni, dato che a volte una correzione di sicurezza può rompere in modi sottili caratteristiche apparentemente non correlate.

NON includere eventuali modifiche nel proprio pacchetto che non sono direttamente collegate alla correzione della vulnerabilità. Queste avranno bisogno solo di essere annullate, e questo richiede tempo. Se ci sono altri bug nel pacchetto che si desidera correggere, si faccia un caricamento su proposed-updates nel solito modo, dopo che l'avviso di sicurezza viene pubblicato. Il meccanismo di aggiornamento della sicurezza non è un mezzo per introdurre modifiche al pacchetto che altrimenti verrebbero respinte per il rilascio stabile, quindi per favore non si tenti di farlo.

Si verifichino e testino le modifiche per quanto possibile. Si controllino ripetutamente le differenze rispetto alla versione precedente (interdiff dal pacchetto patchutils e debdiff da devscripts sono strumenti utili per questo, si consulti Sezione A.2.2, «debdiff»).

Assicurarsi di verificare i seguenti elementi:

  • Individuare la giusta distribuzione nel proprio debian/changelog. Per stable questa è stable-security e per testing questa è testing-security, e per la precedente versione stable, questa è oldstable-security. Non si punti a distribution-proposed-updates o stable!

  • Il caricamento deve avere urgency=high.

  • Si creino voci descrittive e significative nel changelog. Altri faranno affidamento su di loro per determinare se un particolare bug è stato risolto. Si aggiungano istruzioni closes: per eventuali bug di Debian pubblicati. Sempre includete un riferimento esterno, preferibilmente un identificatore CVE , in modo che ci possa essere un riferimento incrociato. Tuttavia, se un identificatore CVE non è ancora stato assegnato, non attenderlo ma continuare il processo. L'identificatore può essere referenziato più tardi.

  • Assicurarsi che il version number sia corretto. Esso deve essere maggiore del pacchetto corrente, ma minore delle versioni del pacchetto in distribuzioni successive. In caso di dubbio, provare con dpkg - compare-versions. Fare attenzione a non riutilizzare un numero di versione che è già stato utilizzato per un caricamento precedente, o uno che è in conflitto con un binNMU. La convenzione è quella di aggiungere +codename 1, ad esempio, 1:2.4.3-4+lenny1, ovviamente aumentando di 1 ad ogni aggiornamento successivo.

  • A meno che il sorgente originale sia stato prima caricato su security.debian.org (grazie ad un aggiornamento di sicurezza precedente), costruite il file da caricare con tutto il codice originale (dpkg-buildpackage -sa). Se vi è stato un precedente caricamento su security.debian.org con la stessa versione dell'originale, si può caricare senza sorgenti originali (dpkg-buildpackage -sd).

  • Assicurarsi di utilizzare esattamente lo stesso*.orig.tar.{gz,bz2,xz} come usato nell'archivio normale, altrimenti non è possibile spostare la correzione di sicurezza negli archivi principali dopo.

  • Si compili il pacchetto su un sistema pulito, che ha installati solo i pacchetti della distribuzione per la quale si sta costruendo. Se non si dispone di un tale sistema, è possibile utilizzare una macchina di debian.org (si consulti Sezione 4.4, «Le macchine Debian») oppure si configuri un chroot (si consulti Sezione A.4.3, «pbuilder» e Sezione A.4.2, «debootstrap»).

NON caricare un pacchetto nella coda di caricamento di sicurezza (oldstable-security, stable-security, etc.) senza la preventiva autorizzazione da parte del team di sicurezza. Se il pacchetto non soddisfa le esigenze del team, causerà molti problemi e ritardi nel trattare con il caricamento indesiderato.

NON caricare la correzione su proposed-updates, senza coordinarsi con il team di sicurezza. I pacchetti da security.debian.org saranno copiati nella cartella proposed-updates automaticamente. Se un pacchetto con lo stesso numero di versione o uno più alto è già installato nell'archivio, l'aggiornamento per la sicurezza sarà rifiutato dal sistema di archiviazione. In questo modo, la distribuzione stabile non avrà un aggiornamento di sicurezza per questo pacchetto.

Dopo aver creato e testato il nuovo pacchetto ed è stato approvato dal team di sicurezza, occorre caricarlo in modo che possa essere installato negli archivi. Per aggiornamenti di sicurezza, il posto giusto per farlo è ftp://security-master.debian.org/pub/SecurityUploadQueue/.

Una volta che un caricamento nella coda di sicurezza è stato accettato, il pacchetto viene automaticamente compilato per tutte le architetture e conservato per la verifica da parte del team di sicurezza.

I caricamenti che sono in attesa di accettazione o di verifica sono accessibili solo da parte del team di sicurezza. Ciò è necessario in quanto ci potrebbero essere correzioni per i problemi di sicurezza che non possono essere ancora rivelati.

Se un membro del team di sicurezza accetta un pacchetto, verrà installato su security.debian.org, così come proposto per la corretta distribution-proposed-updates in ftp-master.debian.org.

Alcune operazioni di manipolazione di archivi non sono automatizzate nel processo di caricamento di Debian. Queste procedure devono essere seguite manualmente dai maintainer. Questo capitolo fornisce le linee guida su cosa fare in questi casi.

A volte un pacchetto cambierà la sua sezione. Per esempio, un pacchetto dalla sezione non-free potrebbe essere GPLizzato in una versione successiva, nel qual caso il pacchetto dovrebbe essere spostato in «main» o «contrib».[3]

Se è necessario modificare la sezione per uno dei propri pacchetti, si modifichino le informazioni di controllo del pacchetto per far posizionare il pacchetto nella sezione desiderata, e caricare nuovamente il pacchetto (si consulti il Debian Policy Manual per i dettagli). È necessario assicurarsi di includere il .orig.tar.{gz,bz2,xz} nel proprio caricamento (anche se non si sta caricando una nuova versione), oppure non comparirà nella nuova sezione insieme al resto del pacchetto. Se la nuova sezione è valida, verrà spostata automaticamente. Se non lo è, allora si contatti gli ftpmasters per capire cosa è successo.

Se, d'altra parte, è necessario modificare la subsection di uno dei pacchetti (per esempio, «devel», «admin»), la procedura è leggermente diversa. Correggete la subsection come si trova nel file di controllo del pacchetto, e caricatelo nuovamente. Inoltre, è necessario per avere il file di override aggiornato, come descritto in Sezione 5.7, «Specificare la sezione del pacchetto, sottosezione e la priorità».

Se per qualche motivo si desidera rimuovere completamente un pacchetto (ad esempio, se si tratta di una vecchia libreria di compatibilità che non è più richiesta), è necessario presentare un bug su ftp.debian.org chiedendo che il pacchetto sia rimosso; come tutti i bug, questo bug dovrebbe di norma avere gravità normal. Il titolo della segnalazione del bug dovrebbe essere della forma RM: package[architecture list]--reason, dove package è il pacchetto da rimuovere e reason è una breve sintesi del motivo per la richiesta di rimozione. [architecture list] è facoltativo e necessario solo se la richiesta di rimozione vale solo per alcune architetture, non tutte. Si noti che il reportbug creerà un titolo conforme a queste regole quando lo si utilizza per segnalare un bug per lo psudo-pacchetto ftp.debian.org.

Se si vuole rimuovere un pacchetto che si mantiene, lo si dovrebbe evidenziare nel titolo del bug anteponendo ROM (Request Of Maintainer). Ci sono diversi altri acronimi standard utilizzati nel motivare una rimozione di un pacchetto, si consulti per un elenco completo. Quella pagina fornisce anche una comoda visione generale delle richieste di rimozione in sospeso.

Si noti che le rimozioni possono essere fatte solo per la distribuzione unstable, experimental and stable. I pacchetti non vengono rimossi da testing direttamente. Piuttosto, essi saranno rimossi automaticamente dopo che il pacchetto è stato rimosso da unstable e nessun pacchetto in testing dipenda da esso. (Rimozioni da testing sono possibili presentando una segnalazione di bug di rimozione su release.debian.org. Si consulti la sezione Sezione 5.13.2.2, «Rimozioni da testing».)

C'è una sola eccezione quando una richiesta di rimozione esplicita non è necessaria: se un pacchetto (sorgente o binario) non è più compilato dal sorgente, verrà rimosso in modo semiautomatico. Per un pacchetto binario, questo significa che se non vi è più alcun pacchetto sorgente che produce questo pacchetto binario; se il pacchetto binario non è più prodotto per alcune architetture, una richiesta di rimozione è ancora necessaria. Per un pacchetto sorgente, questo significa che tutti i pacchetti binari che a lui si riferiscono devono riferirsi ad un altro pacchetto sorgente.

Nella vostra richiesta di rimozione, è necessario dettagliare le ragioni che giustificano la richiesta. Questo per evitare rimozioni indesiderate e per tenere traccia del perché un pacchetto è stato rimosso. Ad esempio, è possibile specificare il nome del pacchetto che sostituisce quello che deve essere rimosso.

Di solito si chiede solo per la rimozione di un pacchetto che si sta mentenendo. Se si desidera rimuovere un altro pacchetto, è necessario ottenere l'approvazione del suo maintainer. Se il pacchetto resta orfano e quindi non ha un maintainer, si deve prima discutere la richiesta di rimozione su . Se c'è un consenso sul fatto che il pacchetto debba essere rimosso, è necessario riassegnare e rinominare la segnalazione del bug O: presentato sul pacchetto wnpp invece di presentare un nuovo bug come richiesta di rimozione.

Ulteriori informazioni relative a questi ed altri argomenti correlati alla rimozione di un pacchetto possono essere trovate in http://wiki.debian.org/ftpmaster_Removals e https://qa.debian.org/howto-remove.html.

In caso di dubbio concernente il fatto che un pacchetto sia usa e getta, si mandi una email a chiedendo pareri. Interessante è anche il programma apt-cache dal pacchetto apt. Quando invocato come apt-cache showpkg package, il programma mostrerà i dettagli per package, incluse le dipendenze revocate. Altri programmi utili sono apt-cache rdepends, apt-rdepends, build-rdeps (nel pacchetto devscripts) e grep-dctrl. La rimozione di pacchetti orfani è discussa su .

Una volta che il pacchetto è stato rimosso, i bug del pacchetto devono essere gestiti. Essi dovrebbero essere riassegnati ad un altro pacchetto nel caso in cui il codice vero e proprio si sia evoluto in un altro pacchetto (ad esempio libfoo12 è stato rimosso perché libfoo13 lo sostituisce) o chiuso, se il software semplicemente non fa più parte di Debian. Quando si chiude il bug, per evitare di segnare i bug corretti in versioni di pacchetti di rilasci precedenti di Debian, dovrebbero essere contrassegnati come corretti nella versione <most-recent-version-ever-in-Debian>+rm.

Quando i maintainer originali a causa di uno dei propri pacchetti hanno scelto di rinominare il loro software (o si è commesso un errore nel nominare il proprio pacchetto), si dovrebbe seguire un processo in due fasi per rinominarlo. Nella prima fase, modificare il file debian/control affinché rifletta il nuovo nome e per sostituire, prevedete e risolvete eventuali conflitti con il nome del pacchetto obsoleto (si consulti Debian Policy Manual per i dettagli). Si tenga presente che si deve solo aggiungere una relazione Provides se tutti i pacchetti dipendenti dall'obsoleto nome del pacchetto continuano a funzionare dopo la ridenominazione. Una volta caricato il pacchetto e il pacchetto è spostato nell'archivio, si apra un bug nei confronti di ftp.debian.org chiedendo di rimuovere il pacchetto con il nome obsoleto (si veda Sezione 5.9.2, «Rimozione dei pacchetti»). Non si dimentichi allo stesso tempo di riassegnare correttamente i bug del pacchetto.

Altre volte, si può fare un errore nella compilazione del proprio pacchetto e si vuole sostituirlo. L'unico modo per farlo è aumentare il numero di versione e caricarlo. La vecchia versione scadrà nel modo consueto. Si noti che questo vale per ogni parte del proprio pacchetto, compresi i sorgenti: se si desidera sostituire l'archivio dei sorgenti originali del proprio pacchetto, è necessario caricarlo con una versione diversa. Un modo semplice è quello di sostituire foo_1.00.orig.tar.gz con foo_1.00+0.orig.tar.gz o foo_1.00.orig.tar.bz2. Questa restrizione dà ad ogni file sul sito FTP un nome unico, che contribuisce a garantire la coerenza tra i mirror.

Se non è più possibile mantenere un pacchetto, è necessario informare gli altri, e controllare che il pacchetto sia contrassegnato come orfano. È necessario impostare il maintainer del pacchetto a Debian QA Group <packages@qa.debian.org> e inviare una segnalazione di bug per lo pseudo pacchetto wnpp. La segnalazione deve essere intitolata O: package --breve descrizione che indica che il pacchetto è ormai orfano. La gravità del bug dovrebbe essere impostata su normal, se il pacchetto ha una priorità di livello standard o superiore, deve essere impostato su important. Se si ritiene necessario, inviare una copia a , mettendo l'indirizzo nell'intestazione X-Debbugs-CC: del messaggio (no, non usare CC:, perché in questo modo l'oggetto del messaggio non indicherà il numero di bug).

Se proprio si ha intenzione di abbandonare il pacchetto, ma è possibile mantenerlo temporaneamente, allora si dovrebbe invece presentare un bug su wnpp ed inserire come titolo RFA: package -- breve descrizione. RFA è l'acronimo di Request For Adoption.

Maggiori informazioni si possono trovare nelle pagine web di WNPP.

Un elenco di pacchetti che necessitano di un nuovo maintainer è disponibile nella Work-Needing and Prospective Packages list(WNPP). Se si desidera prendere in consegna la manutenzione di uno qualsiasi dei pacchetti elencati nella WNPP, si prega di dare un'occhiata alla pagina di cui sopra per informazioni e procedure.

Non è appropriato rilevare semplicemente un pacchetto che si immagina sia trascurato: ciò sarebbe un furto di un pacchetto. È possibile, ovviamente, contattare il maintainer attuale e chiedere se si può prendere in consegna il pacchetto. Se si ha motivo di credere che un maintainer abbia abbandonato il lavoro senza avvisare (AWOL), si consulti Sezione 7.4, «Rapportarsi con maintainer non attivi e/o non raggiungibili».

In generale, non si può prendere in consegna il pacchetto senza il consenso dell'attuale maintainer. Anche se si è ignorati, ciò non è ancora un motivo sufficiente per adottare un pacchetto. Le segnalazioni riguardanti i maintainer devono essere fatte sulla mailing list degli sviluppatori. Se la discussione non termina con una conclusione positiva, e la questione è di natura tecnica, si consideri di portarla all'attenzione del comitato tecnico (si consulti per maggiori informazioni la pagina web del comitato tecnico).

Se si rileva un vecchio pacchetto, probabilmente si vuole essere elencati come maintainer ufficiale del pacchetto nel sistema di tracciamento dei bug. Questo avverrà automaticamente una volta che si carica una nuova versione con un campo Maintainer aggiornato, anche se può richiedere alcune ore dopo che il caricamento sia stato fatto. Se non si prevede di caricare una nuova versione per un po', è possibile utilizzare Sezione 4.10, «L'archivio Debian» per ottenere le segnalazioni di bug. Tuttavia, ci si assicuri che il vecchio maintainer non abbia alcun problema con il fatto che in quel periodo continuerà a ricevere le segnalazioni dei bug.

I pacchetti sono spesso rimossi a causa di bug critici, manutentori assenti, troppo pochi utenti o di scarsa qualità in generale. Mentre il processo di reintroduzione è simile al processo di pacchettizzazione iniziale, è possibile evitare alcune insidie facendo prima qualche ricerca storica.

Si dovrebbe verificare il motivo per cui il pacchetto è stato rimosso, in primo luogo. Queste informazioni si possono trovare nella voce rimozione nella sezione news della pagina PTS per il pacchetto o sfogliando il registro dirimossi. Il bug rimozione vi dirà il motivo per cui il pacchetto è stato rimosso e darà qualche indicazione di ciò che è necessario correggere al fine di reintrodurre il pacchetto. Può indicare che il modo migliore di procedere è quello di passare a qualche altro pezzo di software, invece di reintrodurre il pacchetto.

Può essere opportuno contattare gli ex manutentori per scoprire se si sta lavorando per reintrodurre il pacchetto, interessati a co-mantenimento del pacchetto o interessati a sponsorizzare il pacchetto, se necessario.

Si dovrebbe fare tutto ciò di necessario prima di introdurre nuovi pacchetti (Sezione 5.1, «Nuovi pacchetti»).

Si dovrebbe basare il proprio lavoro sull'ultimo pacchetto disponibile. Questo potrebbe essere l'ultima versione da unstable, che sarà ancora presente nella archivio snapshot.

Il sistema di controllo della versione utilizzata dal manutentore precedente potrebbe modifiche utili, quindi potrebbe essere una buona idea dare un'occhiata lì. Controllare se il file controllo del pacchetto precedente conteneva intestazioni di collegamento al sistema di controllo della versione per il pacchetto e se esiste ancora.

La rimozione di pacchetti da unstable (not testing, stable or oldstable) fa scattare la chiusura di tutti i bug relativi al pacchetto . Si dovrebbe guardare attraverso tutti i bug chiusi (compresi bug archiviati) ed estrarre e riaprire qualunque sia stato chiuso in una versione che termina in +rm e applicare nuovamente. Qualunque che non si applichi deve essere contrassegnato come risolto nella versione corretta se si è a conoscenza.

Debian supporta un numero sempre crescente di architetture. Anche se non si è un autore di port, e si utilizza una sola architettura, è parte del dovere di un maintainer essere a conoscenza dei problemi di portabilità. Pertanto, anche se non si è un porter, si consiglia di leggere la maggior parte di questo capitolo.

Fare un port significa creare pacchetti Debian per architetture diverse dall'architettura originale del pacchetto binario del maintainer. È un'attività unica ed essenziale. In realtà, gli autori di port effettuano la maggior parte della compilazione dei pacchetti Debian. Per esempio, quando un maintainer carica un pacchetto di sorgenti (portabili) con i binari per l'architettura i386, sarà compilato per ciascuna delle altre architetture, pari ad altre 11 compilazioni.

Gli autori di port hanno un compito difficile e unico, poiché sono necessari per affrontare una grande mole di pacchetti. Idealmente, ogni pacchetto sorgente dovrebbe potersi compilare così come è. Purtroppo, spesso questo non è vero. Questa sezione contiene un elenco di «cose da tenere d'occhio» spesso committitate dai maintainer Debian: problemi comuni che spesso ostacolano gli autori di port, e rendono il loro lavoro inutilmente difficile.

La prima e la più importante cosa è quella di rispondere rapidamente a bug o problemi sollevati dagli autori di port. Trattare gli autori di port con cortesia, come se fossero nei fatti co-maintainer del pacchetto (cosa che, in un certo senso, sono). Si sia tolleranti nei confronti di segnalazioni di bug scarne o addirittura non chiare; fare del prorpio meglio per dare la caccia a qualsiasi problema.

Di gran lunga, la maggior parte dei problemi incontrati dagli autori di port sono causati da bug di pacchettizzazione dei pacchetti sorgente. Ecco una lista di cose che dovreste controllare o di cui dovreste essere a conoscenza.

  1. Si verifichi che le impostazioni di Build-Depends e Build-Depends-Indip in debian/control siano impostate correttamente. Il modo migliore per verificarlo è usare il pacchetto debootstrap per creare un ambiente chroot unstable (si consulti Sezione A.4.2, «debootstrap»). All'interno di tale ambiente chroot, si installi il pacchetto build-essential e tutte le dipendenze dei pacchetti citate in Build-Depends o inBuild-Depends-Indep. Infine, si provi a compilare il pacchetto all'interno di tale ambiente chroot. Queste operazioni possono essere automatizzate con l'uso del programma pbuilder che è fornito dal pacchetto omonimo (si consulti Sezione A.4.3, «pbuilder»).

    Se non è possibile impostare una corretta chroot, dpkg-depcheck può essere di aiuto (si consulti Sezione A.6.6, «dpkg-depcheck»).

    Si consulti il Debian Policy Manual per le istruzioni su come impostare le dipendenze di compilazione.

  2. Non si imposti l'architettura a un valore diverso da all o any a meno che non si voglia veramente farlo. In troppi casi, i maintainer non seguono le istruzioni del Debian Policy Manual. Impostare l'architettura ad una sola (come ad esempio i386 o amd64) è di solito non corretto.

  3. Assicurarsi che il proprio pacchetto dei sorgenti sia corretto. Si invochi dpkg-source -x pacchetto.dsc per assicurarsi che il pacchetto dei sorgenti si spacchetti correttamente. Poi, lì dentro, si provi a compilare il pacchetto da zero con dpkg-buildpackage.

  4. Assicuratevi di non distribuire il pacchetto sorgente con il debian/files o debian/substvars. Essi devono essere rimossi dal target clean di debian/rules.

  5. Assicuratevi di non basarvi su configurazioni o programmi installati localmente o modificati. Per esempio, non si dovrebbe mai invocare programmi presenti in /usr/local/bin o simili. Si cerchi di non fare affidamento su programmi configurati in modo particolare. Si provi a compilare il proprio pacchetto su un'altra macchina, anche se è la stessa architettura.

  6. Non dipendere dal fatto che il pacchetto che si sta compilando sia già installato (un sotto-caso del problema di cui sopra). Ci sono, naturalmente, eccezioni a questa regola, ma si sia consapevoli che qualsiasi caso come questo necessita di bootstrap manuale e dagli strumenti per compilazione automatica dei pacchetti.

  7. Non fate affidamento su una particolare versione del compilatore, se possibile. In caso contrario, assicurarsi che le dipendenze di compilazione rispecchino le restrizioni, anche se probabilmente si andrà incontro a guai, poiché diverse architetture a volte si standardizzano su compilatori diversi.

  8. Assicurarsi che il proprio debian/rules contenga target separati per binary-arch e binary-indep, come richiede il Debian Policy Manual. Assicurarsi che entrambi i target lavorino indipendentemente, cioè, che sia possibile chiamare il target senza aver prima chiamato l'altro. Per verificarlo, provate ad eseguire dpkg-buildpackage -B.

Se il pacchetto si compila senza modifiche per l'architettura per la quale si sta facendo il port, si è fortunati e il proprio compito è semplice. Questa sezione si applica a questo caso, descrive come compilare e caricare il pacchetto binario in modo che sia correttamente installato nell'archivio. Se c'è bisogno di creare una patch per il pacchetto in modo da farlo compilare per le altre architetture, si sta effettivamente facendo un NMU di un sorgente, dunque si consultino le Sezione 5.11.1, «Quando e come fare un NMU».

Per un caricamento effettuato da un autore di port, nessuna modifica deve essere stata fatta al sorgente. Non è necesssario toccare alcun file nel pacchetto sorgente. Questo include debian/changelog.

Il modo per richiamare dpkg-buildpackage è come dpkg-buildpackage -B -mporter-mail. Naturalmente, si indichi in porter-mail la propria email. Questo farà una compilazione binaria delle sole parti del pacchetto dipendenti dall'architettura, utilizzando il target binary-arch in debian/rules.

Se si sta lavorando su una macchina Debian per fare il port e si ha bisogno di firmare il proprio caricamento localmente per la sua accettazione nell'archivio, è possibile eseguire debsign sul proprio file .changes per averlo comodamente firmato, oppure si utilizzi la modalità di firma remota dpkg-sig.

A volte il primo caricamento di un autore di port è problematico perché l'ambiente in cui il pacchetto è stato compilato non era abbastanza buono (librerie datate o obsolete, un compilatore non buono, etc.). Allora si può solo aver necessità di ricompilarlo in un ambiente aggiornato. Tuttavia, è necessario incrementare il numero della versione, in questo caso, in modo che il vecchio non buono pacchetto possa essere sostituito nell'archivio Debian (dak si rifiuta di installare nuovi pacchetti, se non hanno un numero di versione maggiore di quella attualmente disponibile).

Si deve fare in modo che il proprio NMU di soli binari non renda il pacchetto non installabile. Questo potrebbe accadere quando un pacchetto sorgente genera pacchetti dipendenti e non dall'architettura che possiedono inter-dipendenze generate utilizzando la variabile di sostituzione di dpkg $(Source-Version).

Nonostante la modifica necessaria del changelog, questi sono chiamati NMU di soli binari: non è necessario in questo caso far sì che tutte le altre architetture si considerino non aggiornate o con necessità di ricompilazione.

Tali ricompilazioni richiedono un particolare numero di versione «magico», in modo che gli strumenti di manutenzione dell'archivio riconoscano che, anche se vi è una nuova versione di Debian, non vi è alcun aggiornamento di sorgenti corrispondente. Se si sbaglia, i manutentori dell'archivio respingeranno il proprio caricamento (per mancanza del corrispondente codice sorgente).

Il «magico» per un NMU con sola ricompilazione viene attivato utilizzando un suffisso aggiunto al numero di versione del pacchetto, seguendo la forma bnumero. Per esempio, se l'ultima versione sulla quale si sta ricompilando era la versione 2.9-3, l'NMU solo binario dovrebbe avere la versione 2.9-3+b1. Se l'ultima versione era 3.4+b1 (cioè un pacchetto nativo con un precedente NMU con ricompilazione), il proprio NMU solo binario dovrebbe avere un numero di versione 3.4+b2.[4]

In modo simile ai caricamenti iniziali dell'autore del port, il modo corretto di invocare dpkg-buildpackage è dpkg-buildpackage -B per compilare solo le parti del pacchetto dipendenti dell'architettura.

Gli autori di port generalmente nel fare un NMU del sorgente seguono le linee guida presenti in Sezione 5.11, «Caricamenti dei Non-Maintainer (NMU)», proprio come i non-porter. Tuttavia, ci si aspetta che il ciclo di attesa per un NMU del sorgente di un autore di port sia minore di quello per chi non è autore di port, poiché i gli autori di port devono gestire una grande quantità di pacchetti. Di nuovo, la situazione varia a seconda della distribuzione sulla quale si stanno effettuando i caricamenti. Essa varia anche se l'architettura è candidata ad essere inclusa nel prossimo rilascio stabile; i gestori dei rilasci decidono e annunciano quali architetture sono candidate.

Se si è un autore di port che fa un NMU per unstable, le linee guida di cui sopra per la portabilità dovrebbero essere seguite, con due varianti. In primo luogo, il periodo di attesa accettabile, il tempo tra quando il bug è presentato al BTS e quando è considerato valido per fare un NMU, è di sette giorni per gli autori di port che lavorano sulla distribuzione unstable. Questo periodo può essere abbreviato se il problema è critico e crea difficoltà sul lavoro di creazione dei port, a discrezione del gruppo di lavoro sui port. (Ricordate, niente di tutto ciò è Policy, ma solo linee guida stabilite di comune accordo.) Per caricamenti su stable o su testing, coordinarsi prima con l'appropriato team di rilascio.

In secondo luogo, gli autori di port che fanno NMU di sorgenti dovrebbero assicurarsi che il bug presentato al BTS dovrebbe essere di gravità serious o superiore. Questo assicura che un singolo pacchetto sorgente possa essere usato per compilare ogni architettura supportata da Debian al momento del rilascio. È molto importante avere una versione del pacchetto binario e di quello del sorgente per tutte le architetture al fine di conformarsi con molte licenze.

Gli autori dei port dovrebbero cercare di evitare le patch che semplicemente aggirano i bug nella versione attuale dell'ambiente di compilazione, kernel, oppure libc. A volte tali stratagemmi non possono essere evitati. Se è necessario aggirare bug del compilatore e simili, assicurarsi di #ifdef il proprio lavoro correttamente; inoltre, documentare le modifiche fatte per aggirare i bug in modo che la gente sappia di rimuoverli una volta che i problemi esterni siano stati corretti.

Gli autori di port possono anche avere un luogo non ufficiale dove possono mettere i risultati del loro lavoro durante il periodo di attesa. Questo aiuta gli altri che utilizzano il port ad avere il vantaggio del lavoro del suo autore, anche durante il periodo di attesa. Naturalmente, tali luoghi non hanno alcuna benedizione o status ufficiale, quindi stare attenti.

C'è un'infrastruttura e diversi strumenti per aiutare ad automatizzare il port dei pacchetti. Questa sezione contiene una breve panoramica di questi strumenti di automazione e di port; si consulti la documentazione dei pacchetti o i riferimenti per informazioni complete.

Le pagine Web che contengono lo stato di ogni porto sono disponibili all'indirizzo https://www.debian.org/ports/.

Ogni port di Debian ha una mailing list. L'elenco delle mailing list dedicate ai port può essere trovato su https://lists.debian.org/ports.html. Questi elenchi vengono utilizzati per coordinare gli autori di port, e per collegare gli utenti di un dato port con gli autori.

Il sistema wanna-build viene utilizzato come sistema client-server distribuito per la distribuzione di compilazioni. Di solito è usato in combinazione con demoni per la compilazione che eseguono il programma buildd. I demoni per la compilazione sono host «slave» che contattano il sistema centrale wanna-build per ricevere una lista di pacchetti che hanno bisogno di essere compilati.

wanna-build non è ancora disponibile come pacchetto; tuttavia, tutti gli sforzi per creare port di Debian lo utilizzano per la compilazione automatizzata dei pacchetti. Lo strumento utilizzato per fare l'effettiva compilazione dei pacchetti, sbuild è disponibile come un pacchetto, si consulti la sua descrizione in Sezione A.4.4, «sbuild». Si noti che la versione pacchettizzata non è la stessa di quella utilizzata dai demoni di compilazioni, ma è abbastanza vicina per riprodurne i problemi.

La maggior parte dei dati prodotti da wanna-build che sono generalmente utili per gli autori di port è disponibile sul web all'indirizzo https://buildd.debian.org/. Questi dati includono le statistiche aggiornate ogni notte, informazioni sulle code e i log dei tentativi di compilazione.

Siamo molto orgogliosi di questo sistema, dal momento che ha tanti usi possibili. Gruppi di sviluppo indipendenti possono utilizzare il sistema per diverse sotto-versioni di Debian, che possono o non possono essere di interesse generale (per esempio, una versione di Debian compilata con il bound-checking di gcc). Essa consentirà inoltre a Debian di ricompilare intere distribuzioni rapidamente.

Il team di wanna-build, responsabile dei buildd, può essere raggiunto all'indirizzo debian-wb-team@lists.debian.org. Per determinare chi contattare (team di wanna-build, team del rilascio) e come (posta, BTS), si faccia riferimento a https://lists.debian.org/debian-project/2009/03/msg00096.html.

Quando si richiedono dei binNMUs o dei give-backs (un nuovo tentativo dopo una compilazione fallita), utilizzare il formato descritto in https://release.debian.org/wanna-build.txt.

Alcuni pacchetti hanno ancora problemi con la compilazione o con il funzionamento su alcune delle architetture supportate da Debian, ed è del tutto impossibile farne il port, o non entro un ragionevole lasso di tempo. Un esempio è un pacchetto che è SVGA-specifico (disponibile solo per i386 e amd64), o che utilizzi altre caratteristiche specifiche dell'hardware non supportate su tutte le architetture.

Al fine di evitare che pacchetti danneggiati vengano caricati nell'archivio, e sprecare tempo dei buildd, è necessario fare un paio di cose:

Si noti che non è sufficiente aggiungere solo il pacchetto in Packages-arch-specific, senza far fallire la compilazione sulle architetture non supportate: un autore di port o una qualsiasi altra persona che cerca di compilare il pacchetto potrebbe accidentalmente caricarlo senza notare che non funziona. Se in passato alcuni pacchetti binari sono stati caricati su architetture non supportate, si richieda la loro rimozione segnalando un bug su ftp.debian.org.

Ogni pacchetto ha uno o più maintainer. Normalmente, queste sono le persone che ci lavorano e caricano nuove versioni del pacchetto. In alcune situazioni è utile che anche altri sviluppatori possano caricare una nuova versione, per esempio se vogliono risolvere un bug in un pacchetto che non mantengono, quando il maintainer ha bisogno di aiuto per rispondere alle segnalazioni. Tali aggiornamenti sono chiamati Non-Maintainer Upload (NMU).

Prima di fare un NMU, si considerino le seguenti domande:

  • Il proprio NMU davvero corregge i bug? Risolvere problemi superficiali o cambiare lo stile di pacchettizzazione è scoraggiato in una NMU.

  • Si è concesso abbastanza tempo al maintainer? Quando è stato segnalato il bug su BTS? Essere occupato per una settimana o due non è insolito. Il bug è così grave che deve essere risolto in questo momento, o può aspettare ancora qualche giorno?

  • Quanto si è sicuri delle modifiche? Si ricordi il giuramento di Ippocrate: «Prima di tutto, non nuocere.» È meglio lasciare un pacchetto con un bug grave aperto che applicare una patch non funzionante, o una che nasconde il bug invece di risolverlo. Se non si è sicuri al 100% di quello che si è fatto, potrebbe essere una buona idea chiedere il parere di altri. Si ricordi che se si rompe qualcosa nel proprio NMU, molte persone saranno molto scontente al riguardo.

  • Come si e sicuri sulle modifiche? Si ricorda il giuramento di Ippocrate: "Soprattutto, non nuocere". E' meglio lasciare un pacchetto con un grave bug aperto che applicare una patch non funzionante, o uno che nasconde il bug invece di risolverlo. Se non si è sicuri al 100% di quello che si è fatto, potrebbe essere una buona idea chiedere il parere di altri. Ricordate che se si rompe qualcosa nel proprio NMU, molte persone saranno molto infelici di questo.

  • Have you clearly expressed your intention to NMU, at least in the BTS? If that didn't generate any feedback, it might also be a good idea to try to contact the maintainer by other means (email to the maintainer addresses or private email, IRC).

  • Se il maintainer è in genere attivo e reattivo, si è provato a contattarlo? Generalmente, dovrebbe essere considerato preferibile che i maintainer si prendano cura di un problema essi stessi e che abbiano la possibilità di rivedere e correggere la patch, in quanto sono più consapevoli dei potenziali problemi che un autore di NMU potrebbe non considerare. Spesso è un miglior uso del tempo di tutti se al maintainer viene data la possibilità di caricare una propria soluzione.

Nel fare un NMU, è necessario assicurarsi che la propria intenzione di un NMU sia chiara. Quindi, è necessario inviare una patch al BTS con le differenze tra il pacchetto attuale e il proprio NMU. Lo script nmudiff nel pacchetto devscripts potrebbe essere utile.

Mentre si prepara la patch, si dovrebbero conoscere bene tutte le pratiche specifiche del pacchetto che il maintainer potrebbe utilizzare. Tenerne conto riduce l'onere di integrare i propri cambiamenti nel normale flusso di lavoro del pacchetto e quindi aumenta la probabilità che l'integrazione avvenga. Un buon posto dove cercare per possibili pratiche specifiche sul pacchetto è debian/README.source.

A meno che non si disponga di un ottimo motivo per non farlo, è necessario quindi dare un po' di tempo al maintainer per reagire (per esempio, caricandolo nella coda DELAYED). Ecco alcuni valori consigliati da usare nei casi differiti:

  • Caricamento che risolve solo bug critici per il rilascio più vecchi di 7 giorni, senza alcuna attività del maintainer sul bug per 7 giorni e nessuna indicazione che si stia lavorando ad una soluzione: 0 giorni

  • Caricamento che risolve solo bug critici per il rilascio più vecchi di 7 giorni: 2 giorni

  • Caricamento che risolve solo bug critici per il rilascio e per bug importanti: 5 giorni

  • Altri NMU: 10 giorni

Tali ritardi sono solo degli esempi. In alcuni casi, come ad esempio caricamenti di correzioni di problemi di sicurezza o di correzioni di bug banali che bloccano una transizione, è auspicabile che il pacchetto corretto raggiunga prima unstable.

A volte, i gestori dei rilasci decidono di permettere NMU con ritardi più brevi per un sottoinsieme di bug (ad esempio bug critici per il rilascio più vecchi di 7 giorni). Inoltre, alcuni maintainer si inseriscono nell'elenco Low Threshold NMU, e accettano che questi NMU vengano caricati senza ritardo. Ma anche in questi casi, è sempre una buona idea concedere al maintainer un paio di giorni per reagire prima di fare il caricamento, soprattutto se la patch non era prima disponibile nel BTS, o se si sa che il maintainer è generalmente attivo.

Dopo aver caricato un NMU, si è responsabili per i possibili problemi che si potrebbe avere introdotto. È necessario tenere d'occhio il pacchetto (iscriversi al pacchetto sul PTS è un buon modo per raggiungere questo obiettivo).

Questa non è una licenza per eseguire NMU in modo sconsiderato. Se si effettua un NMU quando è chiaro che i maintainer sono attivi e avrebbero preso in considerazione una patch tempestivamente, oppure se si ignorano le raccomandazioni di questo documento, il caricamento potrebbe essere causa di conflitto con il maintainer. Si dovrebbe sempre essere pronti a difendere la saggezza di ogni NMU che si fa sulla base dei suoi meriti.

Proprio come qualsiasi altro caricamento (di sorgenti), gli NMU deveno aggiungere una voce a debian/changelog, descrivendo cosa è cambiato con questo caricamento. La prima riga di questa voce deve esplicitamente menzionare che questo caricamento è un NMU, ad esempio:

 * Non-maintainer upload.

Il modo di assegnare versioni agli NMU è differente per i pacchetti nativi e per i non-nativi.

Se il pacchetto è un pacchetto nativo (senza una revisione Debian nel numero di versione), la versione deve essere la versione dell'ultimo caricamento del maintainer, più +nmuX, dove X è un contatore a partire 1. Se anche l'ultimo caricamento è stato un NMU, il contatore dovrebbe essere aumentato. Ad esempio, se la versione corrente è 1.5, allora un NMU avrebbe la versione 1.5+nmu1.

Se il pacchetto non è un pacchetto nativo, si dovrebbe aggiungere un numero di versione secondario alla parte di revisione Debian del numero di versione (la parte dopo l'ultimo trattino). Questo numero aggiuntivo deve iniziare da 1. Ad esempio, se la versione corrente è 1.5-2, poi un NMU otterrebbe la versione 1.5-2.1. Se nell'NMU viene pacchettizzata una nuova versione a monte, la revisione Debian viene impostata a 0, per esempio 1.6-0.1.

In entrambi i casi, se anche l'ultimo caricamento è stato un NMU, il contatore dovrebbe essere aumentato. Ad esempio, se la versione corrente è 1.5+nmu3 (un pacchetto nativo che ha già subito un NMU), l'NMU avrebbe versione 1.5+nmu4.

Uno speciale schema per i nomi di versione del codice è necessario per evitare di danneggiare il lavoro del maintainer, in quanto utilizzare un numero intero per la revisione Debian potenzialmente potrebbe entrare in conflitto con un caricamento del maintainer già in preparazione al momento di un NMU, o anche con uno presente nella coda NEW dell'ftp. Ha anche il vantaggio di rendere visivamente chiaro che un pacchetto nell'archivio non è stato fatto dal maintainer ufficiale.

Se si carica un pacchetto su testing o stable, a volte è necessario fare il «fork» dell'albero dei numeri di versione. Questo è il caso dei caricamenti di sicurezza, ad esempio. Per questo dovrebbe essere usata una versione della forma +debXYuZ, dove X e Y sono i numeri di versione principale e minore, e Z è un contatore che parte da 1. Quando il numero di rilascio non è ancora noto (spesso è il caso per testing, all'inizio dei cicli di rilascio), deve essere utilizzato il più basso numero di versione che è più alto dell'ultimo numero di rilascio stabile. Per esempio, mentre Lenny (Debian 5.0) è stabile, un NMU di sicurezza a stable per un pacchetto alla versione 1.5-3 avrebbe versione 1.5-3+deb50u1, mentre un NMU di sicurezza per Squeeze avrebbe versione 1.5-3+deb60u1. Dopo l'uscita di Squeeze, i caricamenti di sicurezza per la distribuzione testing saranno avranno versione +deb61uZ, fino a quando non è noto se tale versione sarà Debian 6.1 o Debian 7.0 (se si avvera quest'ultimo caso i caricamenti avranno versione come +deb70uZ).

Il dover attendere una risposta dopo che si è richiesto il permesso per un NMU è inefficiente, perché costa all'autore dell'NMU un cambio di contesto per ritornare sul problema. La coda DELAYED (si consulti Sezione 5.6.2, «Caricamenti differiti») consente allo sviluppatore che fa l'NMU di svolgere al tempo stesso tutti i compiti necessari. Per esempio, invece di dire al maintainer che si caricherà il pacchetto aggiornato tra 7 giorni, si dovrebbe caricare il pacchetto in DELAYED/7 e dire al maintainer che ha 7 giorni di tempo per reagire. Durante questo tempo, il maintainer può chiedere di ritardare il caricamento di un po', o annullarlo.

La coda DELAYED non deve essere utilizzata per mettere ulteriore pressione sul maintainer. In particolare, è importante che ci si renda disponibili ad annullare o ritardare il caricamento prima della scadenza del ritardo in quanto il maintainer non lo può annullare da solo.

Se si fa un NMU DELAYED e il maintainer aggiorna il pacchetto prima della scadenza del ritardo, il caricamento sarà respinto perché una nuova versione è già disponibile nell'archivio. Idealmente, il maintainer avrà cura di includere in questa versione le modifiche proposte (o almeno una soluzione per i problemi che affrontano).

Gli NMU sono caricamneti di pacchetti effettuati da qualcun altro che non è il maintainer assegnato. Vi è un altro tipo di caricamento in cui il pacchetto caricato non è vostro: caricamenti di QA. Questi ultimi sono aggiornamenti di pacchetti orfani.

I caricamenti di QA sono molto simili a normali caricamenti del maintainer: possono correggere qualsiasi cosa, anche problemi minori; la numerazione delle versioni è normale, e non vi è alcuna necessità di utilizzare un caricamento differito. La differenza è che non si viene elencati come il Maintainer o Uploader per il pacchetto. Inoltre, la voce del changelog del caricamento di QA ha una speciale prima riga:

 * QA upload.

Se si vuole fare un NMU, e sembra che il maintainer non sia attivo, è consigliabile controllare se il pacchetto sia orfano (questa informazione viene visualizzata sulla pagina Package Tracking System del pacchetto). Quando si fa il primo caricamento di QA ad un pacchetto orfano, il maintainer deve essere impostato su Debian QA Group <packages@qa.debian.org>. I pacchetti orfani che non avevano ancora un caricamento QA hanno ancora indicato il loro vecchio maintainer. C'è un elenco di questi ultimi in https://qa.debian.org/orphaned.html.

Invece di fare un caricamento QA, si può anche prendere in considerazione l'adozione del pacchetto diventando il maintainer. Non è necessario il permesso di nessuno per adottare un pacchetto orfano, basta impostare se stessi come maintainer e caricare la nuova versione (si consulti Sezione 5.9.5, «L'adozione di un pacchetto»).

A volte si sta correggendo o aggiornando un pacchetto perché si è membri di una gruppo di pacchettizzazione (che si avvale di una mailing list come Maintainer o Uploader, si consulti Sezione 5.12, «La manutenzione collaborativa»), ma non si desidera aggiungere se stessi agli Uploader, perché non si prevede di contribuire regolarmente a questo pacchetto specifico. Se è conforme con la politica del team, è possibile eseguire un caricamento normale senza figurare direttamente come Maintainer o Uploader. In tal caso, si dovrebbe iniziare la propria voce del changelog con la seguente riga:

 * Team upload.

Manutenzione collaborativa è un termine che descrive la condivisione dei compiti di manutenzione dei pacchetti Debian tra più persone. Questa collaborazione è quasi sempre una buona idea, dato che in genere si traduce in una maggiore qualità e in tempi più rapidi per la soluzione di bug. Si raccomanda vivamente che i pacchetti con priorità standard o che sono parte dell'insieme base abbiano dei co-maintainer.

In generale vi è un maintainer primario e uno o più co-maintainer. Il maintainer primario è la persona il cui nome è inserito nel campo Maintainer del file debian/control. Co-maintainer sono tutti gli altri maintainer, di solito elencati nel campo Uploaders del file debian/control.

Nella sua forma più semplice, il processo di aggiunta di un nuovo co-maintainer è abbastanza facile:

Un'altra forma di manutenzione collaborativa è la manutenzione in un team, che è raccomandata se si mantengono diversi pacchetti con lo stesso gruppo di sviluppatori. In tal caso, i campi Maintainer e Uploaders di ogni pacchetto devono essere gestiti con attenzione. Si consiglia di scegliere tra i seguenti due schemi:

  1. Inserire il membro del team che è il principale responsabile per il pacchetto nel campo Maintainer. Nel campo Uploaders, inserire l'indirizzo della mailing list, ed i membri del team che si interessano al pacchetto.

  2. Inserire l'indirizzo della mailing list nel campo Maintainer. Nel campo Uploaders, inserire i membri del team che si interessano al pacchetto. In questo caso, è necessario assicurarsi che la mailing list accetti le segnalazioni di bug senza alcuna interazione umana (come la moderazione per i non iscritti).

In ogni caso, è una cattiva idea mettere automaticamente tutti i membri del team nel campo Uploaders. Ciò ingombra l'elenco dei Developer's Package Overview (si consulti Sezione 4.11, «Panoramica dei pacchetti per sviluppatori») con pacchetti di cui di fatto uno non si occupa veramente, e crea un falso senso di buona manutenzione. Per lo stesso motivo, i membri del team non devono di aggiungere se stessi nel campo Uploaders solo perché stanno caricando il pacchetto una sola volta, possono fare un «caricamento di Team» (si consulti Sezione 5.11.7, «NMU e caricamenti del team»). Al contrario, è una cattiva idea tenere un pacchetto con il solo indirizzo della mailing list come Maintainer e senza nessuno Uploaders.

Gli script che aggiornano la distribuzione testing vengono eseguiti due volte al giorno, subito dopo l'installazione dei pacchetti aggiornati; questi script si chiamano britney. Essi generano i file Packages per la distribuzione testing, ma lo fanno in modo intelligente; cercano di evitare qualsiasi incoerenza e di utilizzare solo i pacchetti senza bug.

L'inclusione di un pacchetto da unstable è subordinata alle seguenti:

Per sapere se un pacchetto è in fase di passaggio a testing o meno, si consulti il prodotto dello script di testing nella pagina web della distribuzione testing, oppure si utilizzi il programma grep-excuses, che è nel pacchetto devscripts. Questa utility può essere facilmente utilizzata in un crontab(5) per tenersi informati sull'avanzamento dei propri pacchetti in testing.

Il file update_excuses non sempre dà il motivo preciso per cui il pacchetto è stato rifiutato; potrebbe essere necessario trovarlo da soli, cercando ciò che sarebbe stato reso difettoso dall'inclusione. La pagina web di testing dà qualche informazione in più sulle problematiche comuni che possono causare questi problemi.

A volte, alcuni pacchetti non entrano mai in testing, perché l'insieme di interrelazioni è troppo complicato e non può essere risolto dagli script. Si veda sotto per i dettagli.

Qualche ulteriore analisi delle dipendenze viene visualizzata su http://release.debian.org/migration/, ma attenzione, questa pagina mostra anche le dipendenze per la compilazione che non sono considerate da britney.

Se si è interessati a maggiori dettagli, cosi è come funziona britney:

I pacchetti sono osservati per determinare se essi sono validi candidati. Da questo derivano le motivazioni per gli aggiornamenti. Le ragioni più comuni per cui un pacchetto non viene considerato essere troppo giovane, mancanza di bug RC, e obsoleto su alcune architetture. Per questa parte di britney, i gestori dei rilasci posseggono martelli di varie dimensioni, chiamati suggerimenti (si consulti sotto), per forzare britney a considerare un pacchetto.

Ora arriva la parte più complessa: britney tenta di aggiornare testing con i candidati validi. Per questo, britney cerca di aggiungere ogni candidato valido per la distribuzione testing. Se il numero di pacchetti non installabili in testing non aumenta, il pacchetto viene accettato. Da quel momento in poi, il pacchetto viene considerato parte di testing, in modo che tutti i test di installabilità successivi includeranno questo pacchetto. Suggerimenti da parte del team di rilascio vengono elaborati prima o dopo questo ciclo principale, a seconda del tipo esatto.

Se si vuole avere maggiori dettagli, è possibile cercare su http://ftp-master.debian.org/testing/update_output/.

I suggerimenti sono disponibili tramite http://ftp-master.debian.org/testing/hints/, dove è possibile trovare anche la descrizione. Con i suggerimenti, il team di rilascio di Debian può bloccare o sbloccare i pacchetti, spingere o forzare pacchetti in testing, rimuovere pacchetti da testing, approvare caricamenti al testing-proposed-updates o sovrascrivere l'urgenza.

La distribuzione testing è alimentata con i pacchetti da unstable in base alle regole sopra esposte. Tuttavia, in alcuni casi, è necessario caricare i pacchetti compilati solo per testing. Per questo, è meglio fare il caricamento in testing-proposed-updates.

Si tenga a mente che i pacchetti che sono inviati lì non vengono elaborati automaticamente, devono passare attraverso le mani del gestore del rilascio. Quindi è meglio avere un buon motivo per caricarli lì. Per sapere qual è un buon motivo agli occhi del gestore del rilascio, si consiglia di leggere le indicazioni che sono fornite regolarmente su .

Si consiglia di non fare il caricamento su testing-proposed-updates quando è possibile aggiornare i pacchetti attraverso unstable. Se non è possibile (ad esempio perché si dispone di una versione di sviluppo più recente in unstable), è possibile utilizzare questo strumento, ma si consiglia di chiedere prima l'autorizzazione al gestore del rilascio. Anche se un pacchetto è congelato, sono possibili aggiornamenti tramite unstable, se il caricamento tramite unstable non aggiunge nuove dipendenze.

I numeri della versione sono solitamente individuati concatenando +debXuY, dove X è il numero maggiore della release Debian e Y è un contatore che inizia da 1. e.s.1:2.4.3-4+deb8u1.

Assicurarsi di non essersi dimenticata nessuna di queste cose nel proprio caricamento:

  • Assicurarsi che il proprio pacchetto abbia davvero bisogno di passare attraverso testing-proposed-updates, e non possa passare attraverso unstable;

  • Assicurarsi di includere solo la quantità minima di modifiche;

  • Assicurarsi di aver incluso una spiegazione adeguata nel changelog;

  • Assicurarsi di aver scritto testing o testing-proposed-updates come distribuzione di destinazione;

  • Assicurarsi di aver compilato e testato il proprio pacchetto in testing, non in unstable;

  • Assicurarsi che il numero di versione sia più alto rispetto alla versione in testing e in testing-proposed-updates, e inferiore a quello in unstable;

  • Dopo aver effettuato il caricamento e dopo che la compilazione è riuscita su tutte le piattaforme, si contatti il team di rilascio su chiedendogli di approvare il caricamento.

La struttura degli archivi di distribuzione è tale che possono contenere solo una versione di un pacchetto; un pacchetto è definito 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.

Tuttavia, la vecchia versione potrebbe aver fornito un pacchetto binario con un vecchio nome di una libreria che è in uso, come libacme-foo0. La rimozione del vecchio acmefoo rimuoverà libacme-foo0, che renderà difettosi tutti i pacchetti che dipendono da essa.

Evidentemente, questo riguarda principalmente i pacchetti che forniscono insiemi diversi di pacchetti binari in versioni differenti (principalmente le librerie). Tuttavia, ne saranno affetti anche i pacchetti verso i quali sono state dichiarate dipendenze con numero di versione (versionate) del tipo ==, <=, or <<

Quando l'insieme di pacchetti binari forniti da un pacchetto sorgente è modificato in questo modo, tutti i pacchetti che dipendevano dai precedenti binari devono essere aggiornati in modo da dipendere dai nuovi. Poiché l'installazione di un pacchetto sorgente in testing rende difettosi tutti i pacchetti che ne dipendono in testing, in tale momento deve essere posta una certa attenzione: tutti i pacchetti dipendenti devono essere aggiornati e pronti per essere installati in modo da non risultare difettosi, e, una volta che tutto è pronto, è normalmente richiesto un intervento manuale del gestore del rilascio o di un assistente.

Se si hanno problemi con gruppi complessi di pacchetti come questo, si contatti o per un aiuto.



[3] Si consulti il Debian Policy Manual per le linee guida su quale sezione appartiene un pacchetto.

[4] In passato, tali NMU utilizzarono il numero di terzo livello della parte della revisione di Debian per indicare solo la loro ricompilazione; tuttavia, questa sintassi era ambigua con i pacchetti nativi e non ha permesso una corretta ordinazione delle sole ricompilazioni NMU, NMU sorgente, e NMU di sicurezza sullo stesso package, ed è stata abbandonata in favore di questa nuova sintassi.