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. Notifications
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. Package Salvaging
5.12.1. When a package is eligible for package salvaging
5.12.2. How to salvage a package
5.13. La manutenzione collaborativa
5.14. La distribuzione testing
5.14.1. Nozioni di base
5.14.2. Aggiornamenti da unstable
5.14.2.1. Obsoleti
5.14.2.2. Rimozioni da testing
5.14.2.3. Dipendenze circolari
5.14.2.4. Influenza del pacchetto in testing
5.14.2.5. Dettagli
5.14.3. Aggiornamenti diretti di testing
5.14.4. Domande frequenti
5.14.4.1. Quali sono i bug critici per il rilascio e come vengono contati?
5.14.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.

The first time a version is uploaded that corresponds to a particular upstream version, the original source tar file must be uploaded and included in the .changes file. Subsequently, this very same tar file should be used to build the new diffs and .dsc files, and will not need to be re-uploaded.

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.

Please notice that, in non-native packages, permissions on files that are not present in the *.orig.tar.{gz,bz2,xz} will not be preserved, as diff does not store file permissions in the patch. However, when using source format “3.0 (quilt)”, permissions of files inside the debian directory are preserved since they are stored in a tar archive.

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.

To ensure that your upload will be accepted, you should discuss the changes with the stable release team before you upload. For that, file a bug against the release.debian.org pseudo-package using reportbug, including the patch you want to apply to the package version currently in stable. The patch should be a source debdiff (see Sezione A.2.2, «debdiff») against the current version in stable. The changelog entry should be against the stable distribution (e.g. `buster') and should be detailed, including Closes statements for bugs that are fixed by the upload.

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 the past, uploads to stable were used to address security problems as well. However, this practice is deprecated, as uploads used for Debian security advisories (DSAs) are automatically copied to the appropriate proposed-updates archive when the advisory is released. See Sezione 5.8.5, «Gestione di bug relativi alla sicurezza» for detailed information on handling security problems. If the security team deems the problem to be too benign to be fixed through a DSA, the stable release managers are usually willing to include your fix nonetheless in a regular upload to 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.

To upload a package, you should upload the files (including the signed changes and dsc file) with anonymous ftp to ftp.upload.debian.org in the directory /pub/UploadQueue/. To get the files processed there, they need to be signed with a key in the Debian Developers keyring or the Debian Maintainers keyring (see 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 maintainer dell'archivio Debian sono responsabili per la gestione dei caricamenti dei pacchetti. Per la maggior parte, i caricamenti sono gestiti automaticamente su base giornaliera dagli strumenti di manutenzione, dak process-upload. In particolare, aggiornamenti di pacchetti esistenti nella distribuzione unstable sono gestiti automaticamente. In altri casi, in particolare per i nuovi pacchetti, il posizionamento del pacchetto caricato nella distribuzione viene gestita manualmente. Quando i caricamenti sono gestiti manualmente, la modifica all'archivio può richiedere un certo tempo. Si sia pazienti.

In ogni caso, si riceverà una email di notifica per indicare che il pacchetto è stato aggiunto all'archivio, inoltre indica quali bug saranno chiusi dal caricamento. Esaminare attentamente questa notifica, controllando se qualche bug che si intendeva chiudere è stato tralasciato.

La notifica di installazione include anche informazioni sulla sezione nella quale il pacchetto è stato inserito. Se vi è una disparità, riceverai una email separata di notifica che te lo comunicherà. Si continui a leggere di seguito.

Si noti che se si carica tramite le code, il software demone delle code invierà anche una notifica via email.

Also note that new uploads are announced on the IRC channel #debian-devel-changes. If your upload fails silently, it could be that your package is improperly signed, in which case you can find more explanations on ssh.upload.debian.org:/srv/upload.debian.org/queued/run/log.

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.

When responding to bugs, make sure that any discussion you have about bugs is sent to the original submitter of the bug, the bug itself and (if you are not the maintainer of the package) the maintainer. Sending an email to will send the mail to the maintainer of the package and record your email with the bug log. If you don't remember the submitter email address, you can use to also contact the submitter of the bug. The latter address also records the email with the bug log, so if you are the maintainer of the package in question, it is enough to send the reply to . Otherwise you should include so that you also reach the package maintainer.

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. Once a corrected package is available in the archive, the bug should be closed indicating the version in which it was fixed. This can be done automatically; read 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

We prefer the closes: #XXX syntax, as it is the most concise entry and the easiest to integrate with the text of the changelog. Unless specified differently by the -v-switch to dpkg-buildpackage, only the bugs closed in the most recent changelog entry are closed (basically, exactly the bugs mentioned in the changelog-part in the .changes file are closed).

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.

When an update is made to the stable release, care must be taken to avoid changing system behavior or introducing new bugs. In order to do this, make as few changes as possible to fix the bug. Users and administrators rely on the exact behavior of a release once it is made, so any change that is made might break someone's system. This is especially true of libraries: make sure you never change the API (Application Program Interface) or ABI (Application Binary Interface), no matter how small the change.

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»).

Do NOT upload a package to the security upload queue (on *.security.upload.debian.org) without prior authorization from the security team. If the package does not exactly meet the team's requirements, it will cause many problems and delays in dealing with the unwanted upload.

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.

Once you have created and tested the new package and it has been approved by the security team, it needs to be uploaded so that it can be installed in the archives. For security uploads, the place to upload to is ftp://ftp.security.upload.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.

Uploads that are waiting for acceptance or verification are only accessible by the security team. This is necessary since there might be fixes for security problems that cannot be disclosed yet.

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à».

If for some reason you want to completely remove a package (say, if it is an old compatibility library which is no longer required), you need to file a bug against ftp.debian.org asking that the package be removed; as with all bugs, this bug should normally have normal severity. The bug title should be in the form RM: package [architecture list] -- reason, where package is the package to be removed and reason is a short summary of the reason for the removal request. [architecture list] is optional and only needed if the removal request only applies to some architectures, not all. Note that the reportbug will create a title conforming to these rules when you use it to report a bug against the ftp.debian.org pseudo-package.

If you want to remove a package you maintain, you should note this in the bug title by prepending ROM (Request Of Maintainer). There are several other standard acronyms used in the reasoning for a package removal; see https://ftp-master.debian.org/removals.html for a complete list. That page also provides a convenient overview of pending removal requests.

Note that removals can only be done for the unstable, experimental and stable distributions. Packages are not removed from testing directly. Rather, they will be removed automatically after the package has been removed from unstable and no package in testing depends on it. (Removals from testing are possible though by filing a removal bug report against the release.debian.org pseudo-package. See Sezione 5.14.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.

It is not OK to simply take over a package without assent of the current maintainer — that would be package hijacking. You can, of course, contact the current maintainer and ask them for permission to take over the package.

However, when a package has been neglected by the maintainer, you might be able to take over package maintainership by following the package salvaging process as described in Sezione 5.12, «Package Salvaging». If you have reason to believe a maintainer is no longer active at all, see Sezione 7.4, «Rapportarsi con maintainer non attivi e/o non raggiungibili».

Complaints about maintainers should be brought up on the developers' mailing list. If the discussion doesn't end with a positive conclusion, and the issue is of a technical nature, consider bringing it to the attention of the technical committee (see the technical committee web page for more information).

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.

Package removals from unstable also trigger marking the package as removed in the security tracker. Debian members should mark removed issues as unfixed in the security tracker repository and all others should contact the security team to report reintroduced packages.

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.

Porting is the act of building Debian packages for architectures that are different from the original architecture of the package maintainer's binary package. It is a unique and essential activity. In fact, porters do most of the actual compiling of Debian packages. For instance, when a maintainer uploads a (portable) source package with binaries for the i386 architecture, it will be built for each of the other architectures, amounting to 10 more builds.

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.

The first and most important thing is to respond quickly to bugs or issues raised by porters. Please treat porters with courtesy, as if they were in fact co-maintainers of your package (which, in a way, they are). Please be tolerant of succinct or even unclear bug reports; do your best to hunt down whatever the problem is.

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. Make sure that your Build-Depends and Build-Depends-Indep settings in debian/control are set properly. The best way to validate this is to use the debootstrap package to create an unstable chroot environment (see Sezione A.4.2, «debootstrap»). Within that chrooted environment, install the build-essential package and any package dependencies mentioned in Build-Depends and/or Build-Depends-Indep. Finally, try building your package within that chrooted environment. These steps can be automated by the use of the pbuilder program, which is provided by the package of the same name (see 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. Make sure you don't rely on locally installed or hacked configurations or programs. For instance, you should never be calling programs in /usr/local/bin or the like. Try not to rely on programs being set up in a special way. Try building your package on another machine, even if it's the same architecture.

  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.

The wanna-build system is used as a distributed, client-server build distribution system. It is usually used in conjunction with build daemons running the buildd program. Build daemons are ``slave'' hosts, which contact the central wanna-build system to receive a list of packages that need to be built.

wanna-build is not yet available as a package; however, all Debian porting efforts are using it for automated package building. The tool used to do the actual package builds, sbuild, is available as a package; see its description in Sezione A.4.4, «sbuild». Please note that the packaged version is not the same as the one used on build daemons, but it is close enough to reproduce problems.

Most of the data produced by wanna-build that is generally useful to porters is available on the web at https://buildd.debian.org/. This data includes nightly updated statistics, queueing information and logs for build attempts.

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:

Please note that it is insufficient to only add your package to Packages-arch-specific without making it fail to build on unsupported architectures: A porter or any other person trying to build your package might accidentally upload it without noticing it doesn't work. If in the past some binary packages were uploaded on unsupported architectures, request their removal by filing a bug against 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.

While preparing the patch, you had better be aware of any package-specific practices that the maintainer might be using. Taking them into account reduces the burden of integrating your changes into the normal package workflow and thus increases the chances that integration will happen. A good place to look for possible package-specific practices is 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.

Just like any other (source) upload, NMUs must add an entry to debian/changelog, telling what has changed with this upload. The first line of this entry must explicitly mention that this upload is an NMU, e.g.:

 * 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).

NMUs are uploads of packages by somebody other than their assigned maintainer. There is another type of upload where the uploaded package is not yours: QA uploads. QA uploads are uploads of orphaned packages.

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.

Instead of doing a QA upload, you can also consider adopting the package by making yourself the maintainer. You don't need permission from anybody to adopt an orphaned package; you can just set yourself as maintainer and upload the new version (see Sezione 5.9.5, «L'adozione di un pacchetto»).

Sometimes you are fixing and/or updating a package because you are member of a packaging team (which uses a mailing list as Maintainer or Uploader; see Sezione 5.13, «La manutenzione collaborativa») but you don't want to add yourself to Uploaders because you do not plan to contribute regularly to this specific package. If it conforms with your team's policy, you can perform a normal upload without being listed directly as Maintainer or Uploader. In that case, you should start your changelog entry with the following line:

 * Team upload.

Package salvaging is the process by which one attempts to save a package that, while not officially orphaned, appears poorly maintained or completely unmaintained. This is a weaker and faster procedure than orphaning a package officially through the powers of the MIA team. Salvaging a package is not meant to replace MIA handling, and differs in that it does not imply anything about the overall activity of a maintainer. Instead, it handles a package maintainership transition for a single package only, leaving any other package or Debian membership or upload rights (when applicable) untouched.

Note that the process is only intended for actively taking over maintainership. Do not start a package salvaging process when you do not intend to maintain the package for a prolonged time. If you only want to fix certain things, but not take over the package, you must use the NMU process, even if the package would be eligible for salvaging. The NMU process is explained in Sezione 5.11, «Caricamenti dei Non-Maintainer (NMU)».

Another important thing to remember: It is not acceptable to hijack others' packages. If followed, this salvaging process will help you to ensure that your endeavour is not a hijack but a (legal) salvaging procedure, and you can counter any allegations of hijacking with a reference to this process. Thanks to this process, new contributors should no longer be afraid to take over packages that have been neglected or entirely forgotten.

The process is split into two phases: In the first phase you determine whether the package in question is eligible for the salvaging process. Only when the eligibility has been determined you may enter the second phase, the actual package salvaging.

For additional information, rationales and FAQs on package salvaging, please visit the Salvaging Packages page on the Debian wiki.

If and only if a package has been determined to be eligible for package salvaging, any prospective maintainer may start the following package salvaging procedure.

  1. Open a bug with the severity "important" against the package in question, expressing the intent to take over maintainership of the package. For this, the title of the bug should start with ITS: package-name[5]. You may alternatively offer to only take co-maintenance of the package. When you file the bug, you must inform all maintainers, uploaders and if applicable the packaging team explicitly by adding them to X-Debbugs-CC. Additionally, if the maintainer(s) seem(s) to be generally inactive, please inform the MIA team by adding mia@qa.debian.org to X-Debbugs-CC as well. As well as the explicit expression of the intent to salvage, please also take the time to document your assessment of the eligibility in the bug report, for example by listing the criteria you've applied and adding some data to make it easier for others to assess the situation.

  2. In this step you need to wait in case any objections to the salvaging are raised; the maintainer, any current uploader or any member of the associated packaging team of the package in question may object publicly in response to the bug you've filed within 21 days, and this terminates the salvaging process.

    The current maintainers may also agree to your intent to salvage by filing a (signed) public response to the the bug. They might propose that you become a co-maintainer instead of the sole maintainer. On team maintained packages, a member of the associated team can accept your salvaging proposal by sending out a signed agreement notice to the ITS bug, alternatively inviting you to become a new co-maintainer of the package. The team may require you to keep the package under the team's umbrella, but then may ask or invite you to join the team. In any of these cases where you have received the OK to proceed, you can upload the new package immediately as the new (co-)maintainer, without the need to utilise the DELAYED queue as described in the next step.

  3. After the 21 days delay, if no answer has been sent to the bug from the maintainer, one of the uploaders or team, you may upload the new release of the package into the DELAYED queue with a minimum delay of seven days. You should close the salvage bug in the changelog and you must also send an nmudiff to the bug ensuring that copies are sent to the maintainer and any uploaders (including teams) of the package by CC'ing them in the mail to the BTS.

    During the waiting time of the DELAYED queue, the maintainer can accept the salvaging, do an upload themselves or (ask to) cancel the upload. The latter two of these will also stop the salvaging process, but the maintainer must reply to the salvaging bug with more information about their action.

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. Put the mailing list address in the Maintainer field. In the Uploaders field, put the team members who care for the package. In this case, you must make sure the mailing list accepts bug reports without any human interaction (like moderation for non-subscribers).

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.

Some further dependency analysis is shown on https://release.debian.org/migration/ — but be warned: this page also shows build dependencies that are not considered by 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.

Keep in mind that packages uploaded there are not automatically processed; they have to go through the hands of the release manager. So you'd better have a good reason to upload there. In order to know what a good reason is in the release managers' eyes, you should read the instructions that they regularly give on .

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+deb10u1.

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.

However, the old version may have provided a binary package with an old soname of a library, such as libacme-foo0. Removing the old acmefoo will remove libacme-foo0, which will break any packages that depend on it.

Evidently, this mainly affects packages that provide changing sets of binary packages in different versions (in turn, mainly libraries). However, it will also affect packages upon which versioned dependencies have been declared of the ==, <=, or << varieties.

When the set of binary packages provided by a source package changes in this way, all the packages that depended on the old binaries will have to be updated to depend on the new binaries instead. Because installing such a source package into testing breaks all the packages that depended on it in testing, some care has to be taken now: all the depending packages must be updated and ready to be installed themselves so that they won't be broken, and, once everything is ready, manual intervention by the release manager or an assistant is normally required.

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.

[5] ITS is shorthand for "Intend to Salvage"