Indice
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:
, sostituendo il nome del nuovo
pacchetto in foo
-- breve
descrizione
foo
. La gravità della segnalazione
di bug deve essere impostata su wishlist
. Inviare una
copia a <debian-devel@lists.debian.org>
, 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:
#
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»).
nnnnn
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 <ftpmaster@debian.org>
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:
#
. 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.
nnnnn
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 <debian-devel-changes@lists.debian.org>
.
È 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/
,
o
package
/changelog.Debian.gz/usr/share/doc/
per i pacchetti nativi.
package
/changelog.gz
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):
Installare il pacchetto e assicurarsi che il software funzioni, o aggiornare il pacchetto da una versione precedente alla nuova versione, se già esiste un pacchetto Debian.
Eseguite lintian sul pacchetto. È possibile eseguire
lintian come segue: lintian -v
. Questo
controllerà il pacchetto sorgente, così come il pacchetto binario. Se non si
comprendono i risultati che lintian genera, provare ad
aggiungere il commutatore versione-pacchetto
.changes-i
, che farà produrre a
lintian una descrizione molto dettagliata del problema.
Normalmente, un pacchetto non dovrebbe essere caricato
se provoca a lintian di emettere errori (inizieranno con
E
).
Per maggiori informazioni su lintian, si consulti Sezione A.2.1, «lintian
».
Facoltativamente eseguite debdiff (si consulti Sezione A.2.2, «debdiff») per analizzare i cambiamenti da una versione precedente, se ne esiste una.
Degradare il pacchetto alla versione precedente (se esistente): questo prova
gli script di postrm
e di prerm
.
Rimuovete il pacchetto, quindi reinstallarlo.
Copiare il pacchetto sorgente in una cartella diversa e provare a
spacchettarlo ed a ricompilarlo. Questo testa se il pacchetto si basa su
file esistenti al di fuori di esso, o se si basa su permessi che sono stati
conservati sui file distribuiti all'interno del
.diff.gz
.
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. `stretch') 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
.
Consultare le informazioni nella sezione di test per i dettagli.
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
-dayX
tra 0 e 15). 0-day viene caricato più volte al
giorno in ftp.upload.debian.org
.
Con dput, è possibile utilizzare il parametro --delayed
per mettere il pacchetto in una
delle code.
DELAY
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. For details, please see Sezione 5.8.5, «Gestione di bug relativi alla sicurezza».
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.
Quando si risponde ad un bug, fare in modo che ogni discussione che si ha
sui bug venga inviata sia al mittente originario del bug, e per il bug
stesso (ad esempio,
<
). Se si sta
scrivendo un nuovo messaggio e non si ricorda l'indirizzo di posta
elettronica del mittente, è possibile utilizzare l'email
123
@bugs.debian.org><
per
contattare il mittente e per registrare la propria
posta dentro il log del bug (il che significa che non è necessario inviare
una copia della email a
123
-submitter@bugs.debian.org><
).
123
@bugs.debian.org>
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».
123
-done@bugs.debian.org>
Mai si dovrebbe chiudere un bug tramite il comando del
bug server close
inviato a <control@bugs.debian.org>
. 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:
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.
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 <debian-devel@lists.debian.org>
. 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.
packagename
@packages.debian.org>
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.
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.
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.
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.
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 <debian-devel@lists.debian.org>
o <debian-qa@lists.debian.org>
. 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
.
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.
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: #
syntax, as it is the most concise entry and the easiest to integrate with
the text of the XXX
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
all'indirizzo del sistema di
controllo dei bug, XXX
<control@bugs.debian.org>
. Per chiudere ogni restante bug che è
stato corretto dal proprio caricamento, inviare il file
.changes
per email a
<
, dove
XXX
-done@bugs.debian.org>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.
XXX
-done@bugs.debian.org>
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 <team@security.debian.org>
. 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
<debian-security-announce@lists.debian.org>
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:
, where
package
[architecture
list]
-- reason
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.13.2.2, «Rimozioni da testing».)
C'è una sola eccezione quando una richiesta di rimozione esplicita non è necessaria: se un pacchetto (sorgente o binario) non è più compilato dal sorgente, verrà rimosso in modo semiautomatico. Per un pacchetto binario, questo significa che se non vi è più alcun pacchetto sorgente che produce questo pacchetto binario; se il pacchetto binario non è più prodotto per alcune architetture, una richiesta di rimozione è ancora necessaria. Per un pacchetto sorgente, questo significa che tutti i pacchetti binari che a lui si riferiscono devono riferirsi ad un altro pacchetto sorgente.
Nella vostra richiesta di rimozione, è necessario dettagliare le ragioni che giustificano la richiesta. Questo per evitare rimozioni indesiderate e per tenere traccia del perché un pacchetto è stato rimosso. Ad esempio, è possibile specificare il nome del pacchetto che sostituisce quello che deve essere rimosso.
Di solito si chiede solo per la rimozione di un pacchetto che si sta
mentenendo. Se si desidera rimuovere un altro pacchetto, è necessario
ottenere l'approvazione del suo maintainer. Se il pacchetto resta orfano e
quindi non ha un maintainer, si deve prima discutere la richiesta di
rimozione su <debian-qa@lists.debian.org>
. 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 <debian-devel@lists.debian.org>
chiedendo pareri. Interessante è
anche il programma apt-cache dal pacchetto apt
. Quando invocato come apt-cache
showpkg
, il programma mostrerà
i dettagli per package
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 <debian-qa@lists.debian.org>
.
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
.
In passato, è stato possibile rimuovere i pacchetti da
incoming
. Tuttavia, con l'introduzione del nuovo
sistema di gestione dei caricamenti, questo non è più possibile. Invece, è
necessario caricare una nuova revisione del pacchetto con una versione
superiore rispetto a quello che si desidera sostituire. Entrambe le versioni
saranno installate in archivio, ma solo la versione più alta sarà
effettivamente disponibile in unstable
dal momento che la
versione precedente verrà immediatamente sostituita dalla più
alta. Tuttavia, se si fa una corretta analisi dei pacchetti, la necessità di
sostituire un pacchetto non dovrebbe avvenire troppo spesso comunque.
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:
che indica che il
pacchetto è ormai orfano. La gravità del bug dovrebbe essere impostata su
package
--breve descrizione
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 <debian-devel@lists.debian.org>
, mettendo l'indirizzo
nell'intestazione X-Debbugs-CC: del messaggio (no, non usare CC:, perché in
questo modo l'oggetto del messaggio non indicherà il numero di bug).
Se proprio si ha intenzione di abbandonare il pacchetto, ma è possibile
mantenerlo temporaneamente, allora si dovrebbe invece presentare un bug su
wnpp
ed inserire come titolo
RFA:
. package
-- breve
descrizione
RFA
è l'acronimo di
Request For Adoption
.
Maggiori informazioni si possono trovare nelle pagine web di WNPP.
Un elenco di pacchetti che necessitano di un nuovo maintainer è disponibile nella Work-Needing and Prospective Packages list(WNPP). Se si desidera prendere in consegna la manutenzione di uno qualsiasi dei pacchetti elencati nella WNPP, si prega di dare un'occhiata alla pagina di cui sopra per informazioni e procedure.
Non è appropriato rilevare semplicemente un pacchetto che si immagina sia trascurato: ciò sarebbe un furto di un pacchetto. È possibile, ovviamente, contattare il maintainer attuale e chiedere se si può prendere in consegna il pacchetto. Se si ha motivo di credere che un maintainer abbia abbandonato il lavoro senza avvisare (AWOL), si consulti Sezione 7.4, «Rapportarsi con maintainer non attivi e/o non raggiungibili».
In generale, non si può prendere in consegna il pacchetto senza il consenso dell'attuale maintainer. Anche se si è ignorati, ciò non è ancora un motivo sufficiente per adottare un pacchetto. Le segnalazioni riguardanti i maintainer devono essere fatte sulla mailing list degli sviluppatori. Se la discussione non termina con una conclusione positiva, e la questione è di natura tecnica, si consideri di portarla all'attenzione del comitato tecnico (si consulti per maggiori informazioni la pagina web del comitato tecnico).
Se si rileva un vecchio pacchetto, probabilmente si vuole essere elencati
come maintainer ufficiale del pacchetto nel sistema di tracciamento dei
bug. Questo avverrà automaticamente una volta che si carica una nuova
versione con un campo Maintainer
aggiornato, anche se può
richiedere alcune ore dopo che il caricamento sia stato fatto. Se non si
prevede di caricare una nuova versione per un po', è possibile utilizzare
Sezione 4.10, «L'archivio Debian» per ottenere le segnalazioni di bug. Tuttavia,
ci si assicuri che il vecchio maintainer non abbia alcun problema con il
fatto che in quel periodo continuerà a ricevere le segnalazioni dei bug.
I pacchetti sono spesso rimossi a causa di bug critici, manutentori assenti, troppo pochi utenti o di scarsa qualità in generale. Mentre il processo di reintroduzione è simile al processo di pacchettizzazione iniziale, è possibile evitare alcune insidie facendo prima qualche ricerca storica.
Si dovrebbe verificare il motivo per cui il pacchetto è stato rimosso, in primo luogo. Queste informazioni si possono trovare nella voce rimozione nella sezione news della pagina PTS per il pacchetto o sfogliando il registro dirimossi. Il bug rimozione vi dirà il motivo per cui il pacchetto è stato rimosso e darà qualche indicazione di ciò che è necessario correggere al fine di reintrodurre il pacchetto. Può indicare che il modo migliore di procedere è quello di passare a qualche altro pezzo di software, invece di reintrodurre il pacchetto.
Può essere opportuno contattare gli ex manutentori per scoprire se si sta lavorando per reintrodurre il pacchetto, interessati a co-mantenimento del pacchetto o interessati a sponsorizzare il pacchetto, se necessario.
Si dovrebbe fare tutto ciò di necessario prima di introdurre nuovi pacchetti (Sezione 5.1, «Nuovi pacchetti»).
Si dovrebbe basare il proprio lavoro sull'ultimo pacchetto
disponibile. Questo potrebbe essere l'ultima versione da
unstable
, che sarà ancora presente nella archivio snapshot.
Il sistema di controllo della versione utilizzata dal manutentore precedente
potrebbe modifiche utili, quindi potrebbe essere una buona idea dare
un'occhiata lì. Controllare se il file controllo
del
pacchetto precedente conteneva intestazioni di collegamento al sistema di
controllo della versione per il pacchetto e se esiste ancora.
La rimozione di pacchetti da unstable
(not
testing
, stable
or
oldstable
) fa scattare la chiusura di tutti i bug
relativi al pacchetto . Si dovrebbe guardare attraverso tutti i bug chiusi
(compresi bug archiviati) ed estrarre e riaprire qualunque sia stato chiuso
in una versione che termina in +rm
e applicare
nuovamente. Qualunque che non si applichi deve essere contrassegnato come
risolto nella versione corretta se si è a conoscenza.
Debian supporta un numero sempre crescente di architetture. Anche se non si è un autore di port, e si utilizza una sola architettura, è parte del dovere di un maintainer essere a conoscenza dei problemi di portabilità. Pertanto, anche se non si è un porter, si consiglia di leggere la maggior parte di questo capitolo.
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.
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.
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.
Assicurarsi che il proprio pacchetto dei sorgenti sia corretto. Si invochi
dpkg-source -x
per assicurarsi che il pacchetto dei sorgenti si spacchetti
correttamente. Poi, lì dentro, si provi a compilare il pacchetto da zero con
dpkg-buildpackage.
pacchetto
.dsc
Assicuratevi di non distribuire il pacchetto sorgente con il
debian/files
o
debian/substvars
. Essi devono essere rimossi dal target
clean
di debian/rules
.
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.
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.
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.
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
-m
. Naturalmente, si indichi
in porter-mail
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
b
. Per esempio, se
l'ultima versione sulla quale si sta ricompilando era la versione
numero
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.
Le descrizioni di diversi strumenti per il port si possono trovare su Sezione A.7, «Strumenti per i port».
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:
In primo luogo, assicurarsi che il pacchetto fallisca la compilazione su architetture che non supporta. Ci sono alcuni modi per raggiungere questo obiettivo. Il modo migliore è quello di avere una piccola suite di test che ne verifichi le funzionalità durante la compilazione, e che fallirà se non funziona. Questa è comunque una buona idea, in modo da evitare (alcuni) caricamenti difettosi in tutte le architetture, e permetterà anche al pacchetto di compilarsi appena la funzionalità richiesta viene resa disponibile.
Inoltre, se si ritiene che l'elenco delle architetture supportate sia
piuttosto costante, si dovrebbe cambiare any
in un elenco
delle architetture supportate in debian/control
. In
questo modo, anche la compilazione fallirà, e lo indicherà ad un lettore
umano senza che realmente la si tenti.
Al fine di evitare che gli strumenti di compilazione automatica cerchino dal
cercare inutilmente di compilare il pacchetto, deve essere incluso in
Packages-arch-specific
, un elenco utilizzato dallo
script wanna-build. L'attuale versione è disponibile come
https://anonscm.debian.org/cgit/mirror/packages-arch-specific.git/tree/Packages-arch-specific; consultare la parte iniziale del file per
chi contattare per le modifiche.
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
.
By default packages from the non-free
section are not
built by the autobuilder network (mostly because the license of the packages
could disapprove). To enable a package to be built, you need to perform the
following steps:
Si controlli se è legalmente consentito e tecnicamente possibile automatizzare la compilazione del pacchetto;
Si aggiunga XS-Autobuild: yes
nell'intestazione di
debian/control
;
Si invii una email a <nonfree@release.debian.org>
e si spieghi perché il
pacchetto può legittimamente e tecnicamente essere automaticamente
compilato.
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ù +nmu
,
dove X
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
+deb
,
dove XY
uZ
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).
Quando qualcuno fa un NMU per il vostro pacchetto, questo significa che vuole aiutare a mantenerlo in buona forma. Questo dà agli utenti più velocemente dei pacchetti corretti. Si può considerare di chiedere all'autore dell'NMU di diventare un co-maintainer del pacchetto. La ricezione di un NMU su un pacchetto non è una cosa negativa; ma semplicemente significa che il pacchetto è abbastanza interessante per le altre persone da spingerle a lavorare su di esso.
Per riconoscere un NMU, si includano i suoi cambiamenti e le voci del changelog nel proprio prossimo caricamento da maintainer. Se non si riconosce l'NMU non includendo le voci del changelog dell'NMU nel proprio changelog, i bug rimarranno chiusi nel BTS, ma saranno elencati come presenti nella propria versione di maintainer del pacchetto.
Il nome completo di un NMU è NMU sorgente. C'è anche un altro tipo, vale a dire la NMU solo binario, o binNMU. Un binNMU è anche un pacchetto caricato da una persona diversa dal maintainer del pacchetto. Tuttavia, è un solo un caricamento dei soli binari.
Quando una libreria (o altra dipendenza) viene aggiornata, i pacchetti che la utilizzano possono aver bisogno di essere ricompilati. Dal momento che non sono necessarie modifiche al sorgente, viene utilizzato lo stesso pacchetto sorgente.
I binNMU sono di solito attivati sui buildd da wanna-build. Viene aggiunta
una voce al debian/changelog
, che spiega perché il
caricamento è stato necessario e incrementa il numero di versione come
descritto in Sezione 5.10.2.1, «Ricompilazione o NMU dei soli binari ». Questa voce non deve essere
inclusa nel prossimo caricamento.
Buildds carica i pacchetti per le loroarchitetture negliarchivi come upload
binari. Parlando più precisamente, questi sono binNMUs. Comunque, non sono
chimamati NMU, e non sono aggiunte voci al
debian/changelog
.
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.12, «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.
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:
Set up the co-maintainer with access to the sources you build the package
from. Generally this implies you are using a network-capable version
control system, such as CVS
or
Subversion
. Alioth (see Sezione 4.12, «L'installazione FusionForge di Debian: Alioth»)
provides such tools, amongst others.
Si aggiunga il nome corretto del co-maintainer e l'indirizzo nel campo
Uploaders
nel primo paragrafo del file
debian/control
.
Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org>
Si utilizzi il PTS (Sezione 4.10, «L'archivio Debian»), i co-maintainer dovrebbero iscriversi all'appropriato pacchetto di sorgenti.
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:
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.
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
.
I pacchetti sono generalmente installati nella distribuzione
testing
dopo aver subito un periodo di prova in
unstable
.
Essi devono essere sincronizzati su tutte le architetture e non devono avere
dipendenze tali da renderli non installabili; inoltre devono generalmente
non avere bug critici per il rilascio noti nel momento dell'installazione in
testing
. In questo modo, testing
dovrebbe essere sempre vicina ad essere candidata al rilascio. Si veda sotto
per i dettagli.
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:
Il pacchetto deve essere stato disponibile in unstable
per 2, 5 o 10 giorni, a seconda dell'urgenza (alta, media o bassa). Notare
che l'urgenza è appiccicosa, il che significa che viene presa in
considerazione la massima urgenza caricata dalla precedente transizione in
testing
;
Non deve avere nuovi bug critici per il rilascio (bug RC che riguardano la
versione disponibile in unstable
, ma non intaccano la
versione in testing
);
Deve essere disponibile su tutte le architetture sulle quali è stato
precedentemente compilato in unstable
. dak ls può essere utile per verificare queste
informazioni;
Non deve rendere diffettosa alcuna dipendenza di un pacchetto che è già
disponibile in testing
;
I pacchetti da cui dipende devono essere disponibili in
testing
o devono essere accettati in
testing
nello stesso momento (e lo saranno se soddisfano
tutti i criteri necessari);
La fase del progetto. Cioè transizioni automatiche sono disattivate durante
il freeze della distribuzione
testing
.
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.
For the testing
migration script, outdated means: There
are different versions in unstable
for the release
architectures (except for the architectures in fuckedarches; fuckedarches is
a list of architectures that don't keep up (in
update_out.py
), but currently, it's empty). Outdated
has nothing whatsoever to do with the architectures this package has in
testing
.
Si consideri questo esempio:
alpha | arm | |
---|---|---|
testing | 1 | - |
unstable | 1 | 2 |
The package is out of date on alpha
in
unstable
, and will not go to
testing
. Removing the package would not help at all; the
package is still out of date on alpha
, and will not
propagate to testing
.
Tuttavia, se l'ftp-master rimuove un pacchetto in
unstable
(qui in arm
):
alpha | arm | hurd-i386 | |
---|---|---|---|
testing | 1 | 1 | - |
unstable | 2 | - | 1 |
In questo caso, il pacchetto è aggiornato su tutte le architetture di
rilascio in unstable
(e quella aggiuntiva
hurd-i386
non importa, considerato che non è
un'architettura inclusa nel rilascio).
A volte, la questione che viene sollevata è se è possibile far avanzare pacchetti che non sono ancora stati compialti su tutte le architetture: No. Sempre e comunque no. (Tranne se si mantiene glibc o giù di lì.)
A volte, un pacchetto viene rimosso per consentire ad un altro pacchetto di
entrare: questo accade solo per permettere ad un altro
pacchetto di avanzare se è pronto sotto ogni altro aspetto. Supponiamo ad
esempio che a
non può essere installato con la nuova
versione di b
; allora a
può essere
rimosso per consentire a b
di entrare.
Of course, there is another reason to remove a package from
testing
: it's just too buggy (and having a single RC-bug
is enough to be in this state).
Inoltre, se un pacchetto è stato rimosso da unstable
, e
nessun pacchetto in testing
dipende più da esso, allora
sarà automaticamente rimosso.
Una situazione che non è gestita molto bene da britney è se un pacchetto
a
dipende dalla nuova versione del pacchetto
b
, e viceversa.
Un esempio di questo è:
testing | unstable | |
---|---|---|
a | 1; depends: b=1 | 2; depends: b=2 |
b | 1; depends: a=1 | 2; depends: a=2 |
Né il pacchetto a
, né il pacchetto b
sono considerati per l'aggiornamento.
Attualmente, questo richiede qualche suggerimento manuale al team di
rilascio. contattarli con l'invio di una email a <debian-release@lists.debian.org>
se
ciò dovesse accadere ad uno dei propri pacchetti.
In generale, non c'è nulla nello stato di un pacchetto in
testing
che influenzi il passaggio della prossima
versione da unstable
a testing
, con
due eccezioni: se il numero di bug RC del pacchetto diminuisce, il pacchetto
potrebbe entrare anche se ha ancora bug RC. La seconda eccezione è se la
versione del pacchetto in testing
è fuori sincrono sulle
diverse architetture: allora ogni architettura potrebbe semplicemente
eseguire l'aggiornamento alla versione dei sorgenti del pacchetto; ma questo
può avvenire solo se il pacchetto è stato precedentemente forzato, se
l'architettura è in fuckedarches, o se non c'era nessun pacchetto binario di
quell'architettura presente in unstable
durante la
migrazione su testing
.
In sintesi questo significa: l'unica influenza che un pacchetto presente in
testing
ha su una nuova versione dello stesso pacchetto è
che la nuova versione potrebbe entrarci più facilmente.
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 <debian-devel-announce@lists.debian.org>
.
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
+deb
X
uY
,
dove X
è il numero maggiore della release Debian
e Y
è un contatore che inizia da
1
.
e.s.1:2.4.3-4+deb9u1
.
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
<debian-release@lists.debian.org>
chiedendogli di approvare il caricamento.
Tutti i bug di alcuni livelli più elevati di gravità sono di base
considerati release-critical; attualmente, questi sono i bug
critical
, grave
e
serious
.
Tali bug sono ritenuti avere un impatto sulle possibilità che il pacchetto
venga rilasciato con la distribuzione stable
di Debian:
in generale, se un pacchetto ha un bug critico per il rilascio aperto, non
sarà integrato in testing
, e di conseguenza non sarà
rilasciato in stable
.
The unstable
bug count comprises all release-critical
bugs that are marked to apply to
package
/version
combinations available in unstable
for a release
architecture. The testing
bug count is defined
analogously.
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 <debian-devel@lists.debian.org>
o <debian-release@lists.debian.org>
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.