Indice
Debian è molto più di un semplice software di confezionamento e di mantenimento di questi pacchetti. Questo capitolo contiene informazioni sui modi, modi spesso molto critici, per contribuire a Debian oltre la semplice creazione e la manutenzione dei pacchetti.
Come organizzazione di volontariato, Debian si basa sulla discrezione dei suoi membri nella scelta di ciò su cui vogliono lavorare e nello scegliere la cosa più critica sulla quale trascorre la maggior parte del proprio tempo.
Si consiglia di notificare i bug appena li si trovi nei pacchetti Debian. In realtà, gli sviluppatori Debian sono spesso la prima linea di tester. L'individuazione e la segnalazione di bug nei pacchetti di altri sviluppatori migliora la qualità di Debian.
Si leggano le istruzioni per la segnalazione di bug nel sistema di tracciamento dei bug di Debian.
Provare a presentare il bug da un account di un utente normale dove si preferisce ricevere la posta, in modo che le persone possano rintracciarvi se hanno bisogno di ulteriori informazioni sul bug. Non inviare bug come root.
È possibile utilizzare uno strumento come reportbug(1) per segnalare bug. È in grado di automatizzare e in generale facilitare il processo.
Assicurarsi che il bug non sia già stato presentato per un pacchetto. Ogni
pacchetto ha una lista di bug facilmente raggiungibile a
http://bugs.debian.org/
. Programmi di utilità come querybts(1) possono anche fornire queste informazioni (e anche
reportbug di solito invocherà querybts prima di inviare).
nomepacchetto
Cercare di indirizzare i bug nella posizione corretta. Quando per esempio il proprio bug è relativo ad un pacchetto che sovrascrive i file appartenenti ad un altro pacchetto, controllare le liste di bug per entrambi questi pacchetti in modo da evitare di presentare duplicati di segnalazioni di bug.
Per maggior credito, si può passare attraverso altri pacchetti, unificando i bug che sono riportati più di una volta, o etichettando bug «fixed» quando sono già stati risolti. Si noti che quando non si è né il mittente del bug né il maintainer del pacchetto, non si dovrebbe in realtà chiudere il bug (a meno che non si ha il permesso del maintainer).
Di tanto in tanto si consiglia di controllare lo stato di avanzamento del
bug che si è inviato. Cogliere l'occasione di chiudere quelli che non è
possibile più riprodurre. Per scoprire tutti i bug che si sono inviati, è
sufficiente visitare
http://bugs.debian.org/from:
.
proprio-indirizzo-email
Segnalare un gran numero di bug per lo stesso problema su un gran numero di
pacchetti differenti - vale a dire, più di 10 - è una pratica
sconsigliata. Prendete tutte le misure possibili per evitare del tutto di
sottoporre bug massicci. Per esempio, se il controllo per il problema può
essere automatizzato, aggiungere un nuovo controllo per lintian
in modo che venga emesso un errore o un
avviso.
Se si riportano più di 10 bug sullo stesso argomento in una sola volta, si
consiglia di inviare un messaggio a <debian-devel@lists.debian.org>
dove descrivete la
vostra intenzione prima di presentare il rapporto e di menzionarla
nell'oggetto della mail. Questo permetterà ad altri sviluppatori di
verificare che il bug sia un problema reale. Inoltre, aiuterà a prevenire
una situazione in cui molti maintainer iniziano ad occuparsi simultaneamente
dello stesso bug.
Utilizzare i programmi dd-list e se appropriato
whodepends (dal pacchetto devscripts
) per generare un elenco di tutti i
pacchetti interessati, ed includere l'output nella propria email indirizzata
a <debian-devel@lists.debian.org>
.
Si noti che quando si inviano molti bug sullo stesso argomento, si dovrebbe
inviare la segnalazione di bug a <maintonly@bugs.debian.org>
in
modo che la segnalazione non venga inoltrata alla mailing list di
distribuzione bug.
Si potrebbe voler utilizzare le usertag BTS al momento di presentare i bug per un certo numero di pacchetti. Le usertag sono simili alle normali tag come «patch» e «wishlist», ma differiscono nel senso che sono definite dall'utente e occupano uno spazio dei nomi univoco per un particolare utente. Questo consente a più insiemi di sviluppatori di «usertaggare» lo stesso bug in diversi modi senza conflitto.
Per aggiungere usertag al momento della presentazione di bug, specificare
gli pseudo-header User
e Usertags
:
To: submit@bugs.debian.org Subject:title-of-bug
Package:pkgname
[... ]
User:email-addr
Usertags:tag-name [ tag-name... ]
description-of-bug...
Si noti che i tag sono separati da spazi e non possono contenere caratteri
di sottolineatura. Se si sta caricando bug per un particolare gruppo o team
è consigliato che si imposti il User
ad una mailing list
appropriata dopo aver descritto li i propri intenti.
Per visualizzare bug etichettati con uno specifico usertag, visitare la
pagina
http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=
.
email-addr
&tag=tag-name
Anche se c'è un gruppo dedicato di persone per la Quality Assurance, le
mansioni QA non sono riservate esclusivamente a loro. È possibile
partecipare a questo sforzo, mantenendo i vostri pacchetti il più possibile
privi di bug e il più possibile lintian-clean (si consulti Sezione A.2.1, «lintian
»). Se non si riesce a farlo, allora si dovrebbe prendere
in considerazione di rendere orfani alcuni dei vostri pacchetti (si consulti
Sezione 5.9.4, «Pacchetto orfano»). In alternativa, si può chiedere l'aiuto di
altre persone al fine di recuperare il ritardo con i bug arretrati che si
hanno (si può chiedere aiuto su <debian-qa@lists.debian.org>
o
<debian-devel@lists.debian.org>
). Allo stesso tempo, si può cercare un co-maintainer
(si consulti Sezione 5.12, «La manutenzione collaborativa»).
Di volta in volta il gruppo QA organizza feste di bug squashing in modo da
sbarazzarsi di quanti più problemi possibili. Sono annunciati su
<debian-devel-announce@lists.debian.org>
e l'annuncio spiega quale area sarà al centro
della festa: di solito si concentrano sui bug critici per il rilascio, ma
può accadere che decidano di aiutare a terminare un importante aggiornamento
(come una nuova versione perl che richiede la
ricompilazione di tutti i moduli binari).
Le regole per il caricamento di non-maintainer cambiano durante le feste perché l'annuncio della festa è considerata prioritaria per NMU. Se si dispone di pacchetti che possono essere influenzati dalla festa (perché hanno rilasciato bug critici per esempio), è necessario inviare un aggiornamento per ciascun bug corrispondente per spiegare il loro stato attuale e cosa ci si apetti dalla festa. Se non si vuole un NMU, o se si è solo interessati ad una patch, o se si vuole fare da soli con il bug, spiegarlo nel BTS.
Le persone che partecipano alla festa hanno regole speciali per un NMU, possono fare un NMU senza preavviso se caricano i loro NMU su DELAYED/3-giorni almeno. Tutte le altre regole NMU si applicano come di solito; dovrebbero inviare la patch del NMU al BTS (a uno dei bug aperti fissati dal NMU, o di un nuovo bug, etichettato fisso). Dovrebbero anche rispettare particolari desideri del maintainer.
Se non ci si sente sicuri di fare un NMU, basta inviare una patch al BTS. È molto meglio di un NMU non funzionante.
Durante il corso della vita all'interno di Debian, si dovranno contattare altri maintainer per vari motivi. Si vorrà discutere di un nuovo modo di cooperare tra un insieme di pacchetti correlati, o semplicemente si vorrà ricordare a qualcuno che una nuova versione è disponibile e che se ne ha bisogno.
Cercare l'indirizzo email del maintainer del pacchetto può essere fonte di
distrazione. Fortunatamente, c'è un semplice alias di posta elettronica,
, che
fornisce un modo per inviare email al maintainer, qualunque possa essere il
loro indirizzo di posta elettronica individuale (o gli
indirizzi). Sostituite package
@packages.debian.orgpackage
con il nome di un
sorgente o un pacchetto binario.
Si potrebbe anche essere interessati a contattare le persone che sono
iscritte ad un determinato pacchetto sorgente tramite Sezione 4.10, «L'archivio Debian». È possibile farlo utilizzando l'indirizzo email
.
package
@packages.qa.debian.org
Se si nota che un pacchetto è carente di manutenzione, è necessario assicurarsi che i maintainer siano attivi e che continueranno a lavorare sui loro pacchetti. È possibile che essi non siano più attivi, ma non si sono deregistrati dal sistema, per così dire. D'altra parte, è anche possibile che abbiano solo bisogno di un promemoria.
C'è un sistema semplice (il database MIA) in cui vengono registrate
informazioni inerenti i maintainer etichettati come Missing In
Action. Quando un membro del gruppo QA contatta un maintainer inattivo o
trova ulteriori informazioni su qualcuno, questo viene registrato nel
database di MIA. Questo sistema è disponibile in
/org/qa.debian.org/MIA
sull'host
qa.debian.org
e può essere interrogato con lo strumento
mia-query. Utilizzare mia-query - help
per vedere come interrogare il database. Se si scopre che ancora alcuna
informazione è stata registrata su un maintainer inattivo, o che è possibile
aggiungere ulteriori informazioni, si
Il primo passo è quello di contattare educatamente il maintainer, ed attendere un ragionevole lasso di tempo per la risposta. È abbastanza difficile definire tempo ragionevole, ma è importante tenere in considerazione che la vita reale a volte è molto frenetica. Un modo per gestire questa situazione sarebbe quello di inviare un sollecito dopo due settimane.
Se il maintainer non risponde entro quattro settimane (un mese), si può supporre che la risposta probabilmente non arriverà. Se ciò accade, si dovrebbe indagare ulteriormente e cercare di raccogliere quante più informazioni utili possibili sul maintainer in questione. Ciò include:
Le informazioni echelon
disponibili attraverso il database LDAP degli sviluppatori, che indica
quando lo sviluppatore ha pubblicato l'ultimo post in una mailing list
Debian. (Questo include email su aggiornamenti distribuiti tramite la lista
<debian-devel-changes@lists.debian.org>
). Inoltre, ricordare di controllare nel
database se il maintainer è contrassegnato come in vacanza.
Il numero di pacchetti dei quali questo maintainer è responsabile e lo stato di quei pacchetti. In particolare, ci sono dei bug RC che sono stati aperti da tempo? Inoltre, quanti bug ci sono in generale? Un altro pezzo importante di informazioni è se i pacchetti sono stati NMUed e se sì, da chi.
C'è qualche attività del maintainer al di fuori di Debian? Ad esempio, potrebbero aver inviato qualcosa di recente a mailing list non-Debian o newsgroup.
Un po' problematici sono i pacchetti che sono stati sponsorizzatiì: il
maintainer non è uno sviluppatore Debian ufficiale. Le informazioni
echelon
non sono disponibili per le persone
sponsorizzate, per esempio, quindi è necessario trovare e contattare lo
sviluppatore Debian che ha effettivamente caricato il pacchetto. Dato che
hanno firmato il pacchetto, che sono responsabili per il caricamento in ogni
caso, e sono probabilmente intenzionati di sapere cosa è successo alla
persona che hanno sponsorizzato.
È anche consentito inviare una query a <debian-devel@lists.debian.org>
chiedendo se
qualcuno è a conoscenza del luogo in cui si trova il maintainer mancante. Si
metta in Cc: la persona in questione.
Dopo aver raccolto tutto questo, è possibile contattare <mia@qa.debian.org>
. Persone
su questo alias utilizzeranno le informazioni fornite al fine di decidere
come procedere. Per esempio, potrebbero rendere orfano uno o tutti i
pacchetti del maintainer. Se un pacchetto è stato NMUed, potrebbero
preferire di contattare la NMUer prima di rendere orfano il pacchetto; forse
la persona che ha fatto la NMU è interessato al pacchetto.
Un'ultima parola: ricordare di essere educati. Si è tutti volontari e non si può dedicare tutto il proprio tempo a Debian. Inoltre, non si è a conoscenza delle circostanze della persona che è coinvolta. Forse potrebbe essere gravemente malata o potrebbe anche essere morta: non potete sapere chi potrebbe essere dall'altra parte. Si immagini come un parente si sentirà se leggesse l'email del defunto e trovasse un messaggio molto scortese, arrabbiato e accusatorio!
D'altra parte, anche se si è volontari, si ha una responsabilità. Così si può sottolineare l'importanza di un bene più grande: se un maintainer non ha più il tempo o interesse, dovrebbe lasciar andare e dare il pacchetto a qualcuno con più tempo.
Se si è interessati a lavorare nel team MIA, si dia un'occhiata al file
README
in /org/qa.debian.org/mia
su qa.debian.org
dove i dettagli tecnici e le procedure
di MIA sono documentate e contatti <mia@qa.debian.org>
.
Il successo di Debian dipende dalla sua capacità di attrarre e trattenere nuovi e talentuosi volontari. Se si è uno sviluppatore esperto, si consiglia di partecipare al processo per coinvolgere nuovi sviluppatori. Questa sezione descrive come aiutare i nuovi potenziali sviluppatori.
Sponsorizzare un pacchetto significa caricare un pacchetto per un maintainer, che non è in grado di farlo da solo. Non è una cosa da poco, lo sponsor deve verificare il package ed assicurarsi che esso soddisfi l'elevato livello di qualità che Debian si sforza di avere.
Gli sviluppatori Debian possono sponsorizzare i pacchetti. I maintainer Debian non possono.
Il processo di sponsorizzazione di un pacchetto è:
Il maintainer prepara un pacchetto sorgente (.dsc
) e lo
mette in linea da qualche parte (come su mentors.debian.net)
o, meglio ancora, fornisce un collegamento a un repository pubblico di VCS
(si consulti Sezione 4.4.5, «I server VCS») in cui il pacchetto viene
mantenuto.
Lo sponsor scarica (o fa il checkout) del sorgente del pacchetto.
Lo sponsor esamina il pacchetto sorgente. Se trova dei problemi, informa il maintainer chiedendogli di fornire una versione corretta (il processo inizia dal punto 1).
Lo sponsor non può trovare tutti i problemi che ci sono. Compila il pacchetto, lo firma e lo carica su Debian.
Prima di addentrarci nei dettagli su come sponsorizzare un pacchetto, ci si dovrebbe chiedere se l'aggiunta del pacchetto proposto è vantaggiosa per Debian.
Non è semplice rispondere a questa domanda, può dipendere da molti fattori: il codice originale è maturo e privo di falle di sicurezza? Ci sono pacchetti pre-esistenti che possono fare lo stesso compito e come si comparano con questo nuovo pacchetto? Il nuovo pacchetto è stato richiesto dagli utenti e da quanti? Quanto sono attivi gli sviluppatori originali?
Ci si dovrebbe anche assicurare che il potenziale maintainer sarà un buon maintainer. Hanno già una certa esperienza con altri pacchetti? Se sì, stanno facendo un buon lavoro con loro (corretti alcuni bug)? Hanno familiarità con il pacchetto e con il suo linguaggio di programmazione? Hanno le competenze necessarie per questo pacchetto? In caso contrario, sono in grado di impararle?
È anche una buona idea conoscere la loro posizione rispetto a Debian: sono d'accordo con la filosofia di Debian e hanno intenzione di aderire a Debian? Considerato quanto sia facile diventare un Maintainer Debian, si potrebbe voler sponsorizzare solo le persone che hanno intenzione di aderire. In questo modo fin dall'inizio si è consapevoli che non si dovrà agire in qualità di sponsor a tempo indeterminato.
I nuovi maintainer di solito hanno alcune difficoltà nel creare pacchetti Debian - questo è abbastanza comprensibile. Faranno errori. Ecco perché sponsorizzare un nuovo pacchetto in Debian richiede una profonda conoscenza della pacchettizzazione in Debian. A volte saranno necessarie diverse iterazioni fino a quando il pacchetto sarà abbastanza buono per essere caricato in Debian. Quindi essere uno sponsor implica essere un mentore.
Non bisogna mai sponsorizzare un nuovo pacchetto senza revisionarlo. La revisione dei nuovi pacchetti realizzata da ftpmasters assicura principalmente che il software sia veramente libero. Certo, capita che inciampino sui problemi di pacchettizzazione, ma in realtà non dovrebbero. È il proprio compito garantire che il pacchetto caricato sia conforme alle Free Software Guidelines di Debian e sia di buona qualità.
La compilazione del pacchetto e il testare il software è parte della revisione, ma non è anche sufficiente. Il resto di questa sezione contiene un elenco non esaustivo dei punti da controllare nella vostra revisione. [7]
Verificare che il tarball originale fornito sia lo stesso che è stato distribuito dall'autore principale (quando i sorgenti sono stati ripacchettizzati per Debian, generare da soli la tarball modificata).
Eseguire lintian (si consulti Sezione A.2.1, «lintian
»). Troverà molti problemi comuni. Assicurarsi di
verificare che qualsiasi lintian che sovrascriva la
configurazione fatta dal maintainer sia pienamente giustificata.
Eseguire licensecheck (parte di Sezione A.6.1, «devscripts
») e verificare che
debian/copyright
sia corretto e completo. Cercare i
problemi di licenza (come i file con intestazioni del tipo “All rights
reserved”, o con una licenza non compatibile con DFSG). grep
-ri è un amico per questo compito.
Compilare il pacchetto con pbuilder (o qualsiasi
strumento simile, vedi Sezione A.4.3, «pbuilder
») per garantire che le
dipendenze di compilazione siano soddisfatte.
Correggere debian/control
: segue le buone pratiche (si
consulti Sezione 6.2, «Buone pratiche per debian/control
»)? Sono soddisfatte le
dipendenze?
Correggere debian/rules
: rispecchia le buone pratiche
(si consulti Sezione 6.1, «Buone pratiche per debian/rules
»)? Vedete alcuni possibili
miglioramenti?
Correggere gli script del maintainer (preinst
,
postinst
, prerm
,
postrm
, config
):
preinst
/postrm
funzioneranno
quando le dipendenze non sono installate? Tutti gli script sono idempotenti
(cioè si possono eseguire più volte senza conseguenze)?
Controllare ogni modifica ai file originali (sia in
.diff.gz
, o in debian/patches/
o
direttamente incluse nella tarball debian
dei file
binari). Sono giustificate? Sono adeguatamente documentate (con DEP-3 per le patch)?
Per ogni file, ci si chieda perché il file è lì e se è il modo giusto per ottenere il risultato desiderato. Il maintainer sta seguendo le best practices per la pacchettizzazione (si consulti Capitolo 6, Buone pratiche per la pacchettizzazione)?
Compilare i pacchetti, installarli e provare il software. Assicurarsi di poter rimuovere ed eliminare i pacchetti. Forse provarli con piuparts.
Se il controllo non ha evidenziato alcun problema, si può compilare il pacchetto e caricarlo su Debian. Ricordare che, anche se non si è il maintainer, in qualità di sponsor si è ancora responsabile per ciò che si carica in Debian. Ecco perché si è incoraggiati a tenere il passo con il pacchetto attraverso il Sezione 4.10, «L'archivio Debian».
Si noti che non dovrebbe essere necessario modificare il pacchetto sorgente
per inserire il proprio nome nella changelog
o nel file
di control
. Il campo Maintainer
del
file control
e del file changelog
dovrebbe elencare la persona che ha fatto la pacchettizzazione, ossia la
persona sponsorizzata. In questo modo riceveranno tutta la posta BTS.
Invece di dovrebbe istruire dpkg-buildpackage ad usare la
propria chiave per la firma. Lo si fa con l'opzione -k
:
dpkg-buildpackage -kKEY-ID
Se si usa debuild e debsign, si può
anche configurarlo in modo permanente in ~/devscripts
.:
DEBSIGN_KEYID=KEY-ID
Normalmente si presupporrà che il pacchetto sia già passato attraverso una revisione completa. Così, invece di farlo di nuovo, si analizzerà attentamente la differenza tra la versione attuale e la nuova versione preparata dal maintainer. Se non si è fatta da soli la revisione iniziale, si potrebbe anche voler dare uno sguardo più profondo nel caso in cui il revisore iniziale fosse stato sciatto.
Per essere in grado di analizzare la differenza è necessario avere entrambe le versioni. Scaricare la versione attuale del pacchetto sorgente (con apt-get source) e ricompilarlo (o scaricare gli attuali pacchetti binari con aptitude download). Scaricare il pacchetto sorgente da sponsorizzare (di solito con dget).
Leggere la nuova voce del changelog, dovrebbe dire cosa aspettarsi durante
la revisione. Il principale strumento che si utilizzerà è
debdiff (fornito con il pacchetto devscripts
), lo si può eseguire con due
pacchetti sorgente (i file .dsc
), o due file
.changes
(allora confronterà tutti i pacchetti binari
elencati nel file .changes
).
Se si confrontano i pacchetti sorgente (esclusi i file originali nel caso di una nuova versione, ad esempio filtrando l'output di debdiff con filterdiff-i '*/debian/*'), è necessario capire tutti i cambiamenti che vedrete e che devono essere adeguatamente documentati nel changelog Debian.
Se tutto va bene, compilare il pacchetto e confrontare i pacchetti binari per verificare che le modifiche sul pacchetto sorgente non abbiano conseguenze inattese (come alcuni file cancellati per errore, le dipendenze non soddisfatte, etc).
Si potrebbe controllare il Package Tracking System (si consulti Sezione 4.10, «L'archivio Debian») per verificare se il maintainer non abbia perso
qualcosa di importante. Magari ci sono aggiornamenti di traduzioni che
stanziano nel BTS e che sarebbero potute essere integrate. Forse il
pacchetto è stato NMUed e il maintainer ha dimenticato di integrare le
modifiche nel loro pacchetto dal NMU. Forse c'è un rilascio per un bug
critico che hanno lasciato non gestito e che sta bloccando la migrazione in
testing
. Se si trova qualcosa che avrebbero potuto fare
(meglio), è il momento di dirglielo in modo che per la prossima volta
possano migliorare e in modo che abbiano una migliore comprensione delle
loro responsabilità.
Se non si è trovato alcun grande problema, caricare la nuova versione. In caso contrario, chiedere al maintainer di fornire una versione corretta.
Consultare la pagina Promuovere nuovi sviluppatori sul sito web di Debian.
Consultare la Checklist per i Gestori delle Candidature sul sito web di Debian.
[7] Si possono trovare altri controlli nella wiki nella quale diversi sviluppatori condividono le proprie liste di sponsorizzazione.