Guida di riferimento per lo sviluppatore Debian <author>Developer's Reference Team &email-devel-ref; <author>Adam Di Carlo, editor <author>Raphaël Hertzog <author>Christian Schwarz <author>Ian Jackson <author> <translator>Traduzione:</translator> <translator>Francesco Donadon <francesco.donadon@katamail.com></translator> <translator>Emanuele Rocca <ema@debian.org></translator> <version>ver. &version;, &date-it; <copyright> <copyrightsummary> copyright © 1998—2003 Adam Di Carlo</copyrightsummary> <copyrightsummary> copyright © 2002—2003 Raphaël Hertzog</copyrightsummary> <copyrightsummary> copyright © 1997, 1998 Christian Schwarz</copyrightsummary> Questo manuale è considerato free software; puoi redistribuirlo e/o modificarlo sotto le condizioni della GNU General Public License rilasciata dalla Free Software Foundation; versione 2 o (a tua discrezione) qualunque versione successiva. Questo manuale è distribuito nella speranza che sia utile, ma senza alcuna garanzia; senza neanche la garanzia implicita che sia commerciabile o utile per un particolare scopo. Leggi la GNU General Public License per ulteriori dettagli. Una copia della GNU General Public License è disponibile nel file &file-GPL; all'interno della distribuzione &debian-formal; o in rete su <url id="&url-gpl;" name="il sito web GNU">. Puoi anche ottenerne una copia scrivendo a &fsf-addr;. <toc detail="sect1"> <chapt id="scope">Scopo Di Questo Documento L'obiettivo di questo documento è di fornire una vista d'insieme delle procedure raccomandate e le risorse disponibili agli sviluppatori Debian.  Le procedure qui discusse includono come diventare un mantainer (<ref id="new-maintainer">); come creare nuovi pachetti (<ref id="newpackage">) e come effettuarne l'upload (<ref id="upload">); come gestire i bug reports (<ref id="bug-handling">); come muovere, rimuovere, o abbandonare pacchetti (<ref id="archive-manip">); come fare il port di pacchetti (<ref id="porting">); e come e quando rilasciare versioni temporanee di pacchetti di altri mantainers (<ref id="nmu">). Le risorse qui discusse includono le mailing list (<ref id="mailing-lists">) X.YZWe i server (<ref id="server-machines">); una discussione sulla struttura dell'archivio Debian (<ref id="archive">); spiegazione sui diversi server che accettano l'upload di pacchetti (<ref id="upload-ftp-master">); e una discussione sulle risorse che possono aiutare i mantainer a curare la qualità dei propri pacchetti. (<ref id="tools">). Dovrebbe essere chiaro che questo documento non scende nei dettagli tecnici dei pacchetti Debian e neppure su come generare detti pacchetti. Questa guida non spiega nemmeno in dettaglio gli standard a cui i pacchetti Debian devono sottostare. Tutte queste informazioni possono essere trovate nella <url id="&url-debian-policy;" name="Debian Policy">. Inoltre, questo documento non è espressione formale della politica Debian. Contiene la documentazione per il sistema Debian e i -generalmente convenuti- migliori metodi  operativi. Quindi, è ciò che è chiamato un documento ``normativo''. <chapt id="new-maintainer">Applying per diventare un maintainer <sect id="getting-started">Iniziare Hai letto tutta la documentazione, sei gone through la <url id="&url-newmaint-guide;" name="Debian New Maintainers' Guide">, hai capito a cosa serve ogni parte del pacchetto di esempio <package>hello</package> e stai per Debianizzare il tuo software preferito. Ma come diventare uno sviluppatore Debian in modo da incorporare il tuo lavoro nel Progetto? Innanzitutto, iscriviti alla lista &email-debian-devel; se non l'hai ancora fatto. Invia la parola <tt>subscribe</tt> nelSubject di una email a &email-debian-devel-req;. In caso di problemi, contatta l'amministratore delle liste a &email-listmaster;. Altre informazioni sulle mailing list disponibili possono essere trovate in <ref id="mailing-lists">. &email-debian-devel-announce; è un'altra lista essenziale per chiunque voglia seguire lo sviluppo di Debian. Dovresti iscriverti e "lurkare" (leggere senza inviare messaggi) per un pò prima di iniziare a sviluppare e dovresti post la tua intenzione di lavorare su qualcosa per evitare di duplicare gli sforzi. Un' altra buona lista cui iscriversi è &email-debian-mentors;. Vedi <ref id="mentors"> per i dettagoi. Il canale IRC <tt>#debian</tt> può anche esserre d'aiuto. Quando hai deciso come vuoi contribuire a &debian-formal;, dovresti metterti in contatto con dei maintainer Debian che lavorano su tasks simili. In questo modo puoi imparare da sviluppatori esperti. Per esempio, se sei interessato a pacchettizzare software esistente per Debian dovresti provare a trovare uno sponsor. Uno sponsor lavorerà con te sul tuo pacchetto e ne effettuerà l'upload nell'archivio Debian una volta che sarà soddisfatto del tuo lavoro di pacchetizzazione. Puoi trovare uno sponsor inviando una mail alla mailing list &email-debian-mentors;, descrivendo il tuo pacchetto and yourself (vedi <ref id="sponsoring"> per maggiori informazioni sullo sponsoring). D'altro canto, se sei interessato nel port di Debian ad architetture alternative o kernel non ancora supportati puoi iscriverti alle mailinglist relative al tuo port e chiedere da dove iniziare. Infine, se sei interessato a lavorare sulla documentazione o alla Quality Assurance (QA) puoi unirti agli sviluppatori che lavorano in questi campi ed inviare patch e miglioramenti. <sect id="registering">Registrarsi come sviluppatore Debian Prima di decidere di unirti a &debian-formal;, hai bisogno di leggere tutte le informazioni disponibili nell' <url id="&url-newmaint;" name="Angolo del nuovo manutentore">. Esso descrive esattamente la preparazione che devi seguire prima di poterti registrare per diventare uno sviluppatore Debian. Per esempio, prima di iniziare la procedura devi leggere il <url id="&url-social-contract;" name="Contratto sociale Debian">. Diventare sviluppatore significa essere d'accordo con il Contratto sociale Debian ed impegnarsi a sostenerlo; è molto importante che gli sviluppatori siano d'accordo con le idee essenziali che stanno dietro &debian-formal;. Anche il <url id="&url-gnu-manifesto;" name="Manifesto GNU"> può essere una buona lettura. Il processo per diventare sviluppatore consiste nella verifica della tua identità e delle tue intenzioni, nonchè il controllo delle tue capacità tecniche. Considerando che il numero di persone che lavorano su &debian-formal; è cresciuto a più di &number-of-maintainers; persone e che i nostri sistemi sono usati in posti molto importanti dobbiamo stare attenti a non essere compromessi. Quindi, dobbiamo verificare i nuovi manutentori prima di fornire loro degli accessi sui nostri server e di permettergli di effettuare degli upload di pacchetti. Prima di registrarti dovresti aver dimostrato che puoi fare del lavoro competente e contribuire positivamente. Puoi dimostrarlo inviando delle patch tramite il Bug Tracking System o avendo un pacchetto sponsorizzato da uno sviluppatore Debian per un pò di tempo. Inoltre ci aspettiamo che chi contribuisce sia interessato al Progetto intero e non solo al mantenere il proprio software. Se puoi aiutare gli altri manutentori inviando maggiori informazioni su un bug o magari una patch, fallo! La registrazione richiede che tu abbia familiarità con la filosofia Debian e la documentazione tecnica. Inoltre, hai bisogno di una chiave GnuPG firmata da un manutentore. Se la tua chiave GnuPG non è firmata dovresti provare ad incontrare uno sviluppatore Debian di persona per avere la sua firma sulla tua chiave. C'è una <url id="&url-gpg-coord;" name="Pagina di coordinamento per la firma delle chiavi GnuPG Key"> che dovrebbe aiutarti a trovare un manutentore vicino a te (se non riesci a trovarlo c'è un modo alternativo per passare il controllo dell'identità puoi inviare un photo ID firmato con la tua chiave GnuPG. Avere la tua chiave GnuPG firmata è il modo migliore, comunque. Vedi la <url id="&url-newmaint-id;" name="identification page"> per maggiori informazioni su queste due opzioni). Se non hai ancora una chiave OpenPGP, generane una. Ogni sviluppatore ne ha bisogno per firmare e verificare gli upload di pacchetti. Dovresti leggere la documentazione del software che stai usando visto che vi sono molte informazioni critiche dal punto di vista della sicurezza. Sono più i problemi di sicurezza dovuti ad errori umani rispetto a quelli imputabili a problemi nel software or high-powered spy techniques. Vedi <ref id="key-maint"> per maggiori informazioni sul mantenimento della tua chiave pubblica. Debian utilizza <prgn>GNU Privacy Guard</prgn> (pacchetto <package>gnupg</package>, versione 1 o superiore) come standard. Puoi comunque usare altre implementazioni di OpenPGP. Nota che OpenPGP è uno standard aperto basato sull' <url id="&url-rfc2440;" name="RFC 2440">. L'algoritmo di chiave pubblica raccomandato per lo sviluppo in Debian è il DSA (a volte chiamato ``DSS'' o ``DH/ElGamal''). Comunque possono essere usati altri tipi di chiavi. La tua chiave deve essere lunga al meno 1024 bit; non c'è motivo di usare una chiave più piccola e farlo implica un livello di sicurezza molto più basso. La tua chiave deve essere firmata almeno dai tuoi user ID; questo previene lo "user ID tampering". <prgn>gpg</prgn> lo fa automaticamente. Se la tua chiave pubblica non è su keyserver pubblici come &pgp-keyserv;, leggi la documentazione disponibile localmente in &file-keyservs;. Quel documento contiene istruzioni su come mettere la tua chiave sui keyserver pubblici. Il New Maintainer Group metterà la tua chiave pubblica sui server se non c'è già. Alcuni paesi limitano l'utilizzo di software crittografico ai propri cittadini. Questo non impedisce l'attività come manutentore di pacchetti Debian, visto che è perfettamente legale l'utilizzo di prodotti crittografico per l'autenticazione, piuttosto che per la crittazione. &debian-formal; non richiede l'uso della crittografia qua in alcun modo. Se vivi in un paese dove l'uso della crittografia è proibito anche per scopi di autenticazione sei pregato di contattarci così che possiamo trovare special arrangements. Per apply as a new maintainer, hai bisogno di un maintainer Debian che verifichi la tua application (un advocate). Dopo che hai contribuito a Debian per un pò di tempo, e vuoi apply per diventare uno sviluppatore registrato, uno sviluppatore esistente con cui hai lavorato nei mesi precedenti deve express their belief che puoi contribuire a Debian con successo. Quando hai trovato un advocate, hai la tua chiave GnuPG firmata e hai contribuito a Debian per un periodo, sei pronto ad apply. Puoi semplicemente registrarti sulla nostra<url id="&url-newmaint-apply;" name="pagina di application">. Dopo che ti sei registrato, un advocate deve confermare la tua application. Quando il tuo advocate ha completato questo passo ti verrà assegnato un Application Manager che effettuerà con te i passi del New Maintainer process. Puoi sempre controllare lo stato sull'<url id="&url-newmaint-db;" name="applications status board">. Per ulteriori dettagli, consulta <url id="&url-newmaint;" name="L'angolo del nuovo manutentore"> sul sito web Debian. Assicurati di avere familiarità coi passi necessari del the New Maintainer process prima di effettuare applying. Se sei ben preparato, puoi risparmiare molto tempo dopo. <sect id="mentors">Debian mentor e sponsor La mailing list &email-debian-mentors; è stata creata per novelli manutentori alla ricerca di aiuto sulla pacchettizzazione iniziale ed altri problemi da sviluppatore. Ogni nuovo sviluppatore è invitato ad iscriversi a questa lista (vedi <ref id="mailing-lists"> per i dettagli). Quelli che preferiscono aiuto uno-ad-uno (via email private) dovrebbero scrivere a questa lista ed uno sviluppatore esperto potrebbe offrire il suo aiuto. Inoltre, se hai dei pacchetti pronti per l'inclusione in Debian, ma stai aspettando di finire la tua new maintainer application potresti riuscire a trovare degli sponsor che effettuino l'upload dei pacchetti per te. Gli sponsor sono persone che sono manutentori Debian ufficiali e che are willing to criticize ed effettuare l'upload dei pacchetti per te. Coloro i quali cerchino uno sponsor possono richiederne uno a <url id="&url-sponsors;">. Se vuoi essere un mentor e/o uno sponsor, ulteriori informazioni sono disponibili in <ref id="newmaint">. <chapt id="developer-duties">Compiti dello sviluppatore Debian <sect id="user-maint">Aggiornare le tue informazioni in Debian Esiste un database LDAP contenente informazioni sugli sviluppatori Debian all'indirizzo <url id="&url-debian-db;">. Qui dovresti inserire le tue informazioni aggiornarle non appena cambiano. La cosa piu' importante è di assicurarsi che l'indirizzo dove la tua email debian.org viene inoltrata sia sempre aggiornato, così come l'indirizzo dove impostare la tua sottoscrizione a debian-private, se decidi di iscriverti. Per ulteriori informazioni circa il database, visitare <ref id="devel-db">. <sect id="key-maint">Mantenere la tua chiave privata Sii molto accorto con le tue chiavi private. Non metterle in nessun server pubblico o macchine multi-utente, come ad esempio i server Debian (leggi <ref id="server-machines">). Fai una copia delle tue chiavi; tienine una copia offline. Leggi la documentazione fornita insieme al software, leggi le <url id="&url-pgp-faq;" name="PGP FAQ">. Se aggiungi firme alla tua chiave pubblica, o aggiungi altre identità, puoi aggiornare il server Debian mandando la chiave al server <tt> &keyserver-host;</tt> Se hai bisogno di aggiungere una chiave completamente nuova, o di rimuoverne una vecchia, manda una e-mail a &email-debian-keyring;. Si applicano le stesse procedure di estrazione chiavi discusse in <ref id="registering">. Puoi trovare una discussione dettagliata sulla manutenzione delle chiavi Debian nella documentazione del pacchetto <package> debian-keyring</package>. <sect id="voting">Votare Anche se Debian non è realmente una democrazia, noi usiamo un procedimento democratico per eleggere i nostri leaders e per approvare risoluzioni generali. Questi procedimenti sono definiti dalla <url id="&url-constitution;" name="Costituzione Debian">. A parte l'elezione annuale del leader, le votazioni non sono sistematiche, e non sono svolte alla leggera. Ogni proposta e' prima discussa sulla mailing list &email-debian-vote; e richiede svariate approvazioni prima che il segretario del progetto dia l'inizio alla procedura di voto. Non sei obbligato a seguire le discussioni pre-voto, il segretario annuncerà le votazioni diverse volte su &email-debian-devel-announce; (tutti gli sviluppatori dovrebbero essere iscritti a tale lista). La democrazia non funziona bene se le persone non prendono parte al voto, è per questo che incoraggiamo tutti gli sviluppatori a votare. Il voto è condotto attraverso messaggi e-mail criptati e firmati con GPG. La lista di tuttte le proposte (passate e presenti) è disponibile sulla pagina di <url id="&url-vote;" name="Informazioni sulle votazioni Debian">, insieme alle informazioni su come fare, sostenere e votare proposte. <sect id="inform-vacation">Andare in vacanza È comune per gli sviluppatori avere periodi di assenza, sia che siano vacanze pianificate o semplicemente essere oberati dal lavoro. La cosa importante da capire è che gli altri sviluppatori hanno bisogno di sapere se sei in vacanza in modo che possano fare ciò che devono se accade un problema con i tuoi pacchetti o altri compiti nel progetto. Solitamente ciò significa che altri sviluppatori sono autorizzati a fare un NMU (vedi <ref id="nmu">) del tuo pacchetto se un grosso problema (bug release-critical, aggiornamenti di sicurezza, ecc.) salta fuori mentre sei via. A volte non è niente di così grave, ma è comunque appropriato far sapere agli altri se sei indisponibile. Per informare gli altri sviluppatori, ci sono due cose che dovresti fare. Per prima cosa manda una e-mail a &email-debian-private; mettendo "[VAC] " all'inizio del subject del messaggio<footnote>Questo in modo che chi non volesse leggere tali messaggi possa filtrarli facilmente.</footnote> indicando il periodo in cui non sarai raggiungibile. Puoi anche dare istruzioni speciali su cosa fare se succede un problema. L'altra cosa da fare è quella di marcarti "in vacanza" nel <qref id="devel-db">database LDAP degli sviluppatori Debian</qref> (questa informazione è accessibile soltanto dagli sviluppatori Debian). Non dimenticarti di togliere la flag "in vacanza" quando torni! <sect id="upstream-coordination">Cooperazione con gli sviluppatori upstream Una grossa parte del tuo lavoro come mantainer Debian sarà di stare in contatto con gli sviluppatori upstream. Gli utenti Debian a volte segnaleranno dei bug non specifici di Debian al nostro sistema di tracciamento dei bug. Devi inoltrare queste segnalazioni di bug agli sviluppatori upstream in modo che possano essere risolti in un futuro rilascio upstream. Anche se non è il tuo lavoro risolvere bug non specifici Debian, puoi liberamente farlo se ne sei capace. Quando lo fai, assicurati di mandare la patch anche agli sviluppatori upstream. Gli utenti e sviluppatori Debian a volte manderanno delle patch che risolvono bug upstream -- dovresti valutare e nel caso mandare tali patch agli sviluppatori upstream. Se devi modificare i sorgenti originali per far sì che il pacchetto sia conforme ai requisiti della politica Debian, dovresti proporre tali modifiche agli sviluppatori upstream in modo che quando rilasceranno una nuova versione, tu non dovrai modificarne i sorgenti. Qualunque modifica tu debba fare, cerca sempre di non separarti dai sorgenti upstream. <sect id="rc-bugs">Gestire i bug release-critical Generalmente dovresti gestire le segnalazioni di bug sui tuoi pacchetti come descritto nella sezione <ref id="bug-handling">. Nonostante ciò, esiste una speciale categoria di bug di cui devi prenderti cura -- i cosiddetti release-critical bugs (RC bugs). Tutti le segnalazioni di bug con severità critica, grave o seria hanno un impatto sulla possibilità che il pacchetto venga incluso nel prossimo rilascio stabile di Debian. Questi bug possono ritardare il rilascio e/o giustificarne la rimozione durante il periodo di "freeze". Ecco perchè questi bug devono essere chiusi prima possibile. Gli sviluppatori che fanno parte del gruppo di <url id="&url-debian-qa;" name="Assicurazione Qualità"> seguono tutti quei bug e tentano ad aiutare quando possibile. Se per qualche ragione non riesci a risolvere un bug RC in un tuo pacchetto entro 2 settimane, dovresti o chiedere aiuto mandando una e-mail al gruppo di Assicurazione Qualità (QA) &email-debian-qa; oppure spiegare le tue difficoltà e presentare un piano per risolverle mandando una e-mail alla segnalazione del bug. Altrimenti, qualcuno del gruppo QA potrebbe avere intenzione di effettuare un Non-Mantainer Upload (vedi <ref id="nmu">) dopo aver provato a contattarti (potrebbero non aspettare tanto quanto fanno di solito prima di fare il loro NMU se non vedono nessuna tua recente attività nel BTS). <sect>Ritirarsi Se scegli di abbandonare il progetto Debian, dovresti assicurarti di compiere i seguenti passaggi: <enumlist> <item> Abbandonare tutti i tuoi pacchetti, come descritto in <ref id="orphaning">. <item> Mandare una e-mail spiegando perchè lasci il progetto a &email-debian-private;. <item> Fare sapere a chi mantiene le chiavi Debian (&email-debian-keyring;)che lasci il progetto. </enumlist> <chapt id="resources">Risorse per gli sviluppatori Debian In questo capitolo troverai una road map molto concisa delle mailing list Debian, le macchine Debian che potrebbero essere disponibili per te come sviluppatore e tutte le altre risorse che sono disponibili per aiutarti nel tuo lavoro di mantainer. <sect id="mailing-lists">Mailing list Gran parte delle conversazioni tra sviluppatori (e utenti) Debian sono gestite attraverso un grande numero di mailing list che ospitiamo all'indirizzo <tt><url id="http://&lists-host;/" name="&lists-host;"></tt>. Per ulteriori informazioni su come sottoscriversi o togliersi, come postare e come non postare, dove trovare i vecchi post e come cercarli, come contattare i mantainer delle liste e vedere varie altre informazioni circa le mailing list, per favore vedi <url id="&url-debian-lists;">. Questa sezione coprirà solo gli aspetti delle mailing list che sono di particolare interesse per gli sviluppatori. <sect1 id="mailing-lists-rules">Regole di base Quando rispondi ai messaggi sulla mailing list, per favore non mandare una copia carbone (<tt>CC</tt>) al mittente originario a meno che non lo richiedano esplicitamente. Chiunque mandi un messaggio a una mailing list dovrebbe leggerla per vedere le risposte. Il cross-posting (mandare lo stesso messaggio a più liste) è sconsigliato. Come sulla rete, per favore minimizza il quoting degli articoli a cui stai rispondendo. In generale, per favore rispetta le convenzioni usuali per mandare messaggi. Per favore leggi il <url name="codice di condotta" id="&url-debian-lists;#codeofconduct"> per ulteriori informazioni. <sect1 id="core-devel-mailing-lists">Core development mailing lists  Le mailing list Debian di base che gli sviluppatori dovrebbero usare sono: <list> <item>&email-debian-devel-announce;, usata per annunciare cose importanti agli sviluppatori. Ci si aspetta che tutti gli sviluppatori siano iscritti a questa lista. </item> <item>&email-debian-devel;, usata per discussioni tecniche riguardanti lo sviluppo. </item> <item>&email-debian-policy;, dove la policy Debian viene discussa e votata. </item> <item>&email-debian-project;, usate per discutere questioni non tecniche riguardanti il progetto. </item> </list> Sono disponibili altre mailing list per una varietà di argomenti speciali, vedi <url id="http://&lists-host;/"> per una lista. <sect1 id="mailing-lists-special">Liste speciali &email-debian-private; è una mailing list speciale per discussioni private tra gli sviluppatori Debian. È intesa per essere usata per post che per qualunque ragione non dovrebbero essere apertamente pubblicati. Per questo, è una lista a basso traffico, e gli utenti sono pregati di non usare &email-debian-private; a meno che non sia assolutamente necessario. Inoltre, non inoltrare email da questa lista a nessuno. Gli archivi di questa lista non sono disponibili sul web per ovvie ragioni, ma puoi consultarli usando il tuo account di shell su <tt>lists.debian.org</tt> e guardando nella directory <file>~debian/archive/debian-private</file>. &email-debian-email; è una mailing list speciale usata per conservare la corrispondenza legata a Debian, come quando si contattano gli autori upstream circa licenze, bug, ecc. o si discute il progetto con altre persone dove potrebbe essere utile avere la discussione archiviata da qualche parte. <sect1 id="mailing-lists-new">Richiedere nuove liste relative allo sviluppo. Prima di richiedere una mailing list correlata allo sviluppo di un pacchetto (o un piccolo gruppo di pacchetti tra loro correlati), per favore considera se sia più appropriato usare un alias (via un file .forward-aliasname su master.debian.org, che si traduce in un ragionevole indirizzo <var>you-aliasname@debian.org</var>) o una mailing list autogestita su <qref id="alioth">Alioth</qref>. Se decidi che una mailing list regolare su lists.debian.org è realmente quello che vuoi, vai avanti e compila una richiesta, seguendo <url name="l'HOWTO" id="&url-debian-lists-new;">. <sect id="irc-channels">Canali IRC Diversi canali IRC sono dedicati allo sviluppo di Debian. Sono principalmente ospitati sulla rete <url id="&url-openprojects;" name="freenode"> (precedentemente nota come Open Projects Network). La voce di DNS <tt>irc.debian.org</tt>è un alias di <tt>irc.freenode.net</tt>. Il canale principale per Debian in generale è #debian. Questo è un grosso canale "general-purpose" dove gli utenti possono trovare notizie recenti nel topic e servite dai bot. #debian è per gli utenti che parlano inglese; ci sono anche #debian.de, #debian-fr, #debian-br e altri canali chiamati in modo simile per gli utenti che parlano altre lingue. Il canale principale per lo sviluppo di Debian è #debian-devel. È un canale molto attivo in quanto di solito ci sono sempre oltre 150 persone loggate. È un canale per persone che lavorano su Debian, non è un canale di supporto (esiste #debian per quello). È comunque aperto a chiunque voglia leggere (e imparare). Il suo topic è comunemente pieno di informazioni interessanti per gli sviluppatori. Siccome #debian-devel è un canale aperto, non dovresti parlare qui di questioni che sono discusse in &email-debian-private;. Esiste un altro canale per questo scopo, è chiamato #debian-private ed è protetto da una chiave. La chiave è disponibile negli archivi di debian-private in <file>master.debian.org:&file-debian-private-archive;</file>, usa sempilcemente <prgn>zgrep</prgn> cercando #debian-private in tutti i file. Ci sono altri canali addizionali dedicati ad argomenti specifici. #debian-bugs è usato per coordinare i bug squash party. #debian-boot è usato per coordinare il lavoro sui floppy di boot (ovvero l'installer). #debian-doc è usato occasionalmente per parlare circa la documentazione, come il documento che stai leggendo. Altri canali sono dedicati a un'architettura o un set di pacchetti: #debian-bsd, #debian-kde, #debian-jr, #debian-edu, #debian-sf (pacchetto SourceForge), #debian-oo (pacchetto OpenOffice) ... Esistono anche qualche canale di sviluppatori non in Inglese, per esempio #debian-devel-fr per le persone che parlano Francese interessate allo sviluppo di Debian. Esistono canali dedicati a Debian anche su altri network IRC, in particolare sul network IRC <url name="Open and free technology community (OFTC)" id="http://www.oftc.net/">. <sect id="doc-rsrcs">Documentazione Questo documento contiene molte informazioni molto utili agli sviluppatori Debian, ma non può contenere tutto. Per la maggior parte degli altri documenti interessanti è presente il link dall'<url id="&url-devel-docs;" name="Angolo degli sviluppatori">. Prenditi il tempo di consultare tutti i collegamenti, imparerai molte più cose. <sect id="server-machines">Macchine Debian Debian possiede diversi computer che fungono da server, la maggior parte dei quali hanno funzioni critiche nel pregetto Debian. La maggior parte delle macchine sono usate per attività di porting, e hanno tutte una connessione permanente a Internet. La maggior parte delle macchine sono disponibili per essere usate dagli sviluppatori, finchè si attengano alle regole imposte nella <url name="Policy di utilizzo delle macchine Debian" id="&url-dmup;">. In generale, puoi usare queste macchine a tua discrezione per scopi correlati a Debian. Per favore sii cortese con gli amministratori di sistema, e non usare tonnellate di spazio disco, banda o CPU senza aver ottenuto prima l'approvazione degli amministratori di sistema. Di solito queste macchine sono gestite da volontari. PEr favore fai attenzione a proteggere le tue password Debian e le chiavi SSH installate su macchine Debian. Evita metodi di login o di upload che mandano le password su Internet in chiaro, come telnet, FTP, POP ecc. Per favore non mettere nessun materiale non correlato a Debian sui server Debian, a meno che tu non ne abbia il permesso. La lista aggiornata delle macchine Debian è disponibile all'indirizzo <url id="&url-devel-machines;">. Quella pagina web contiene i nomi delle macchine, informazioni sui contatti, informazioni su chi può entrarci, le chiavi SSH ecc. Se hai un problema con il funzionamento di un server Debian, e pensi che gli operatori di sistema debbano esserne informati, il team degli amministratori di sistema Debian è raggiungibile a <email>debian-admin@lists.debian.org</email>. Se hai un problema con un certo servizio non correlato all'amministrazione di sistema (come pacchetti da rimuovere dall'archivio, suggerimenti per il sito web, ecc.), generalmente riporterai un bug su uno ``pseudo-pacchetto''. Vedi <ref id="submit-bug"> per informazioni su come riportare i bug. <sect1 id="servers-bugs">Il server bugs <tt>&bugs-host;</tt> è la locazione canonica del sistema di tracciamento dei bug (BTS). Se stai pianificando di fare qualche analisi statistica o di processare i bug Debian, questo sarebbe il posto per farlo. Per favore esplica le tue intenzioni su &email-debian-devel; prima di implementare qualsiasi cosa, comunque, per non duplicare inutilmente gli sforzi o sprecare del tempo. Tutti gli sviluppatori Debian hanno un account su <tt>&bugs-host;</tt>. <sect1 id="servers-ftp-master">Il server ftp-master Il server <tt>ftp-master.debian.org</tt> mantiene la canonica copia dell'archivio Debian (a parte i pacchetti non-US). Generalmente, gli upload di pacchetti vanno su questo server; vedi <ref id="upload">. I problemi con l'archivio FTP Debian devono generalmente essere riportati come bug sullo pseudo-pacchetto <package>ftp.debian.org</package> o un'email a &email-ftpmaster;, ma vedi anche le procedure in <ref id="archive-manip">. <sect1 id="servers-non-us">Il server non-US Il server non-US, <tt>non-us.debian.org</tt>, mantiene la canonica copia della parte non-US dell'archivio Debian. Se devi effettuare l'upload di un pacchetto in una delle sezioni non-US, fallo su questo server; vedi <ref id="upload-non-us">. I problemi con l'archivio dei pacchetti non-US generalmente dovrebbero essere riportati come bug sullo pseudo-pacchetto <package>nonus.debian.org</package> (nota la mancanza del trattino tra "non" e "us" nel nome dello pseudo-pacchetto — questo per compatibilità all'indietro). Ricorda di controllare se qualcun'altro abbia o meno già riportato il problema sul <url id="http://&bugs-host;/nonus.debian.org" name="sistema di tracciamento dei bug">. <sect1 id="servers-www">Il server www-master Il server web principale è <tt>www-master.debian.org</tt>. Tiene le pagine web ufficiali, la facciata di Debian per molti newbie. Se scovi un problema nel server web Debian, generalmente dovresti riportare un bug contro lo pseudo-pacchetto <package>www.debian.org</package>. Ricorda di controllare se qualcun'altro abbia o meno già riportato il problema sul <url id="http://&bugs-host;/www.debian.org" name="sistema di tracciamento dei bug">. <sect1 id="servers-people">Il server web people <tt>people.debian.org</tt> è il server usato per le pagine web personali degli sviluppatori su qualunque cosa correlata a Debian. Se hai delle informazioni su Debian che vuoi mettere a disposizione sul web, puoi farlo mettendo il materiale nella directory <file>public_html</file> sotto la tua home directory su <tt>people.debian.org</tt>, che sarà quindi disponibile all'indirizzo <tt>http://people.debian.org/~<var>your-user-id</var>/</tt>. Dovresti usare questa particolare locazione solo perchè ne verranno fatte delle copie di backup, mentre in altri host no. Di solito l'unica ragione per cui potresti voler usare un host diverso è quando hai bisogno di pubblicare materiale soggetto alle restrizioni di esportazione degli U.S.A., in qual caso puoi usare uno degli altri server situati fuori dagli Stati Uniti, come il già menzionato <tt>non-us.debian.org</tt>. Se hai qualche domanda manda un'email a &email-debian-devel;. <sect1 id="servers-cvs">Il server CVS Il nostro server CVS è situato su <tt>cvs.debian.org</tt>. Se hai bisogno di usare un server CVS che sia pubblicamente accessibile, per esempio, per aiutarti a coordinare il lavoro su un pacchetto tra molti sviluppatori diversi, puoi richiedere un'area CVS sul server. Generalmente, <tt>cvs.debian.org</tt> offre una combinazione di accesso CVS locale, accesso client-server anonimo a sola lettura e pieno accesso client-server attraverso <prgn>ssh</prgn>. Inoltre, si può accedere all'area CVS in sola lettura via web all'indirizzo <url id="&url-cvsweb;">. Per richiedere un'area CVS, manda una richiesta via email a &email-debian-admin;. Includi nella richiesta il nome dell'area CVS richiesta, l'account Debian che dovrebbe detenere la root dell'area CVS e perchè ne hai bisogno. <sect id="devel-db">Il database degli sviluppatori Il database degli sviluppatori, all'indirizzo <url id="&url-debian-db;">, è una directory LDAP per gestire gli attributi degli sviluppatori Debian. Puoi usare questa risorsa per cercare la lista degli sviluppatori Debian. Una parte di queste informazioni è accessibile attraverso il servizio finger sui server Debian, prova <prgn>finger yourlogin@db.debian.org</prgn> per vedere che cosa riporta. Gli sviluppatori possono <url name="effettuare il login nel database" id="&url-debian-db-login;"> per cambiare diverse informazioni su di loro, come: <list> <item>indirizzo di inoltro per la tua email debian.org <item>iscrizione a debian-private <item>se sei assente <item>informazioni personali come il tuo indirizzo, nazione, latitudine e longitudine del posto dove vivi per usarli nella <url name="mappa mondiale degli sviluppatori Debian" id="&url-worldmap;">, numero di telefono e di fax, nickname IRC e pagina web. <item>password e shell preferita sulle macchine del progetto Debian </list> Naturalmente, la maggior parte delle informazioni non sono accessibili al pubblico. Per ulteriori informazioni per favore leggi la documentazione online che puoi trovare all'indirizzo <url id="&url-debian-db-doc;">. Uno può anche inviare le sue chiavi SSH perchè siano usate per l'autenticazione sulle macchine ufficiali Debian, e persino aggiungere nuove voci DNS *.debian.net. Queste funzionalità sono documentate all'indirizzo <url id="&url-debian-db-mail-gw;">. <sect id="archive">L'archivio Debian La distribuzione &debian-formal; contiene un grande numero di pacchetti (<file>.deb</file>, correntemente sono circa &number-of-pkgs;) e pochi altri file aggiuntivi (come la documentazione e le immagini dei dischi di installazione). Ecco un albero di directory di esempio di un archivio Debian completo: &sample-dist-dirtree; Come puoi vedere, la directory di più alto livello contiene due directory,<file>dists/</file> e <file>pool/</file>. L'ultima è una “pool” nella quale i pacchetti ci sono veramente, e che è gestita dal database di manutenzione dell'archivio e i relativi programmi. La prima contiene le distribuzioni, stable, testing e unstable. I file <file>Packages</file> e <file>Sources</file> nelle sottodirectory delle distribuzioni possono referenziare file nella directory <file>pool/</file>. L'albero delle directory sotto ognuna delle distribuzioni è arrangiato in maniera identica agli altri. Ciò che sotto descriviamo per stable è ugualmente applicabile alle distribuzioni unstable e testing. <file>dists/stable</file> contiene tre directory, chiamate <file>main</file>, <file>contrib</file> e <file>non-free</file>. In ciascuna di queste aree c'è una directory per i pacchetti sorgente (<file>source</file>) e una directory per ogni architettura supportata (<file>binary-i386</file>, <file>binary-m68k</file>, ecc.). L'area <file>main</file> contiene delle directory addizionali che tengono le immagini disco e frammenti essenziali di documentazione richiesti per installare la distribuzione Debian su una specifica architettura (<file>disks-i386</file>, <file>disks-m68k</file>, ecc.). <sect1 id="archive-sections">Sezioni La sezione main dell'archivio Debian è quella che forma la ditribuzione &debian-formal; ufficiale. La sezione main è ufficiale perchè è pienamente conforme a tutte le linee guida. Le altre sezioni no, con gradualità diverse; perciò non fanno ufficialmente parte di &debian-formal;. Ogni pacchetto nella sezione main deve essere pienamente conforme alle <url id="&url-dfsg;" name="Linee guida Debian sul software libero"> (DFSG)e a tutti gli altri requisiti della policy come descritto nella <url id="&url-debian-policy;" name="Policy Debian">. Le DFSG sono la nostra definizione di “software libero.” controlla la policy Debian per i dettagli. I pacchetti nella sezione contrib devono conformarsi alle DFSG, ma possono non soddisfare altri requisiti. Per esempio, possono dipendere da pacchetti non-free. I pacchetti che non sono conformi alla DFSG sono posti nella sezione non-free. Questi pacchetti non sono considerati parte della distribuzione Debian, anche se diamo supporto per l'utilizzo e forniamo infrastrutture (come il nostro sistema di tracciamento dei bug e mailing list) per i pacchetti di software non-free. La <url id="&url-debian-policy;" name="Policy Debian"> contiene una definizione più esatta delle tre sezioni. La discussione soprastante è solo un'introduzione. La separazione delle tre sezioni al livello più alto dell'archivio è importante per chiunque abbia intenzione di distribuire Debian, sia attraverso server FTP su internet sia su CD-ROM: distribuendo solo le sezioni main e contrib, uno può evitare qualunque rischio di tipo legale. Alcuni pacchetti nella sezione non-free non ammettono per esempio la distibuzione commerciale. D'altra parte, un commerciante di CD-ROM  potrebbe facilmente controllare le licenze di ogni singolo pacchetto in non-free e includere tutti quelli che può nel CD-ROM. (Siccome questo varia enormemente da un commerciante all'altro, questo lavoro non può essere svolto dagli sviluppatori Debian.) Nota anche che il termine "sezione" è usato anche per riferirsi alle categorie che simplificano l'organizzazione e la consultazione dei pacchetti disponibili, p. es. admin, net, utils ecc. Una volta queste sezioni (più che altro sottosezioni) esistevano nella forma di sottodirectory nell'archivio Debian. Oggi queste esistono solo nel campo "Section" degli header dei pacchetti. <sect1>Architetture Nei primi tempi, il kernel Linux era disponibile solo per le piattaforme Intel i386 (o maggiori), e così anche Debian. Ma quando Linux divenne sempre più popolare, il kernel fu portato anche su altre architetture. Il kernel Linux 2.0 supporta Intel x86, DEC Alpha, SPARC, Motorola 680x0 (come Atari, Amiga e i Macintosh), MIPS, e PowerPC. Il kernel Linux 2.2 supporta ancora più architetture, incluse ARM e UltraSPARC. Siccome Linux supporta quelle piattaforme, Debian decise che anch'essa avrebbe dovuto farlo. Quindi, Debian sta sviluppando dei porting; in effetti, abbiamo anche in preparazione port per kernel non Linux.  A parte i386 (il nostro nome per Intel x86), ci sono m68k, alpha, powerpc, sparc, hurd-i386, arm, ia64, hppa, s390, mips, mipsel e sh al tempo di questo documento. &debian-formal; 1.3 è disponibile solo per i386. Debian 2.0 uscì per architetture i386 e m68k. Debian 2.1 supporta architetture i386, m68k, alpha, e sparc. Debian 2.2 aggiunse il supporto per architetture powerpc e arm. Debian 3.0 aggiunge il supporto a cinque nuove architetture: ia64, hppa, s390, mips and mipsel. Informazioni per sviluppatori e utenti circa specifici port sono disponibili nelle <url id="&url-debian-ports;" name="pagine web dei port Debian">. <sect1>Pacchetti Ci sono due tipi di pacchetti Debian, nominalmente pacchetti sorgenti e binari. I pacchetti sorgenti consistono di due o tre file: un file <file>.dsc</file>e o un file <file>.tar.gz</file> o sia un <file>.orig.tar.gz</file> che un file <file>.diff.gz</file>. Se un pacchetto è sviluppato specialmente per Debian e non è distribuito al di fuori di Debian, c'è solo un file <file>.tar.gz</file> che contiene i sorgenti del programma. Se un pacchetto è distribuito anche altrove, il file <file>.orig.tar.gz</file> contiene il cosiddetto codice sorgente upstream, che è il codice sorgente che è distribuito dal mantainer upstream (spesso l'autore del software). In questo caso, il <file>.diff.gz</file> contiene le modifiche effettuate dal mantainer Debian. Il file <file>.dsc</file> elenca tutti i file nel pacchetto sorgente insieme ai checksum (<prgn>md5sums</prgn>) e qualche informazione addizionale sul pacchetto (mantainer, versione, ecc.). <sect1>Distribuzioni Il sistema di directory descritto nel capitolo precedente è a sua volta contenuto nelle directory delle distribuzioni. Ogni distribuzione è in realtà contenuta nella directory <file>pool</file> al livello più alto dello stesso archivio Debian. Per riepilogare, l'archivio Debian ha una directory di root in un server FTP. Per esempio, nel sito mirror <ftpsite>ftp.us.debian.org</ftpsite>, l'archivio Debian stesso è contenuto in <ftppath>/debian</ftppath>, che è una locazione comune (un altra è <file>/pub/debian</file>). Una distribuzione comprende pacchetti Debian sorgenti e binari e i rispettivi file indice <file>Sources</file> e <file>Packages</file>, contenenti le informazioni degli header da tutti quei pacchetti. I primi sono contenuti nella directory <file>pool/</file>, mentre i secondi sono contenuti nella directory <file>dists/</file> dell'archivio (per compatibilità all'indietro). <sect2 id="sec-dists">Stable, testing e unstable Ci sono sempre distribuzioni chiamate stable (residente in <file>dists/stable</file>), una chianata testing (residente in <file>dists/testing</file>) e una chiamata unstable (residente in <file>dists/unstable</file>). Questo riflette il processo di sviluppo del progetto Debian. Lo sviluppo attivo viene fatto nella distrubuzione unstable (ecco perchè questa distribuzione viene a volte chiamata la distribuzione di sviluppo). Ogni sviluppatore Debian può aggiornare i suoi pacchetti in questa distribuzione in qualsiasi momento. Di conseguenza, i contenuti di questa distribuzione cambiano giornalmente. Siccome non viene fatto alcuno sforzo speciale per assicurarsi che tutto funzioni propriamente in questa distribuzione, a volte è letteralmente instabile. <qref id="testing">"testing"</qref> è generata automaticamente prendendo i pacchetti da unstable se questi soddisfano certi criteri. Questi criteri dovrebbero assicurare una buona qualità per i pacchetti in testing. L'aggiornamento a testing è lanciato ogni giorno dopo che i nuovi pacchetti vengano installati. Vedi <ref id="testing">. Dopo un periodo di sviluppo, una volta che il release manager lo ritiene opportuno, la distribuzione testing viene "congelata", il che significa che le regole che controllano come i pacchetti sono spostati da unstable a testing vengono ristrette. I pacchetti troppo bacati sono rimossi. Nessun cambiamento è ammesso in testing a eccezione dei fix dei bug. Dopo che è passato un po' di tempo, dipendentemente dai progressi, la distribuzione testing va in uno stato di `deep freeze', durante il quale non viene fatta alcuna modifica su di essa a eccezione di quelle necessarie per il sistema di installazione. Questo è chiamato un “ciclo di test”, e può durare fino a due settimane. Ci possono essere diversi cicli di test, finchè la distribuzione è pronta per il rilascio, come deciso dal release manager. Alla fine dell'ultimo ciclo di test, la distribuzione testing è rinominata stable, rimpiazzando la vecchia distribuzione stable, che a quel punto viene rimossa (anche se può essere sempre trovata all'indirizzo <tt>&archive-host;</tt>). Questo ciclo di sviluppo è basato sulla supposizione che la distribuzione unstable diventa stable dopo che è passata un periodo di tempo in testing. Persino una volta che una distribuzione viene considerata stabile, inevitabilmente rimangono ancora dei bug — ecco perchè la distribuzione stable viene ogni tanto aggiornata. Comunque, questi aggiornamenti sono controllati molto attentamente e devono essere introdotti nell'archivio individualmente, per ridurre il rischio di introdurre nuovi bug. Puoi trovare le aggiunte proposte per stable nella directory <file>proposed-updates</file>. Questi pacchetti in <file>proposed-updates</file> che passano l'ispezione sono periodicamente spostati  in blocco nella distribuzione stable e il suo livello di revisione viene incrementato (p.es., ‘3.0’ diventa ‘3.0r1’, ‘2.2r4’ diventa ‘2.2r5’, e così via). Nota che lo sviluppo sotto unstable continua anche durante il periodo di "freeze", siccome la distribuzione unstable rimane al suo posto in parallelo con testing. <sect2 id="testing"> <heading>Ulteriori informazioni sulla distribuzione testing</heading> Gli script che aggiornano la distribuzione testing vengono lanciati ogni giorno dopo l'installazione dei pacchetti aggiornati. Generano i file <file>Packages</file> per la distribuzione testing, ma lo fanno in modo intelligente cercando di evitare qualsiasi inconsistenza e cercando di usare solo pacchetti non bacati. L'inclusione di un paccchetto da unstable è soggetta alle seguenti condizioni: <list> <item> Il pacchetto deve essere stato disponibile in unstable per diversi giorni; il numero preciso dipende dal campo "urgency" dell'upload. È 10 giorni per urgenza bassa, 5 giorni per urgenza media e 2 giorni per urgenza elevata.  Questi periodi possono essere raddoppiati durante un freeze. <item> Deve avere meno bug release-critical rispetto alla versione disponibile in testing; <item> Deve essere disponibile per tutte le architetture per cui è stato precedentemente fatto il build. <ref id="madison"> può essere interessante per controllare quell'informazione. <item> Non deve infrangere alcuna dipendenza di un pacchetto che è già disponibile in testing; <item> I pacchetti sui quali dipende devono o essere disponibili in testing o essere accettati in testing contemporaneamente (e lo saranno se rispettano tutti i criteri necessari); </list> Per scoprire se un pacchetto stia o meno progredendo in testing vedi l'output dello script di testing sulla <url name="pagina web della distribuzione testing" id="&url-testing-maint;">, oppure usa il programma <prgn>grep-excuses</prgn> che è nel pacchetto <package>devscripts</package>. Questa utility può essere facilmente usata in un <manref name="crontab" section="5"> per tenere le persone informate sul progresso dei loro pacchetti in testing. Il file <file>update_excuses</file> non fornisce sempre la ragione precisa per la quale il pacchetto è stato rifiutato, uno può dovere trovarla per proprio conto cercando cosa potrebbe impedire l'inclusione del pacchetto. La <url id="&url-testing-maint;" name="pagina web testing"> fornisce qualche altra informazione circa i problemi comuni che possono causare guai simili. A volte qualche pacchetto non entra mai in testing perchè l'insieme delle inter-dipendenze è troppo complicato e non può essere risolto dagli script. In quel caso si deve contattare il release manager che forzerà l'inclusione dei pacchetti. In generale, per favore riferisciti alla <url name="pagina web testing" id="&url-testing-maint;"> per ulteriori informazioni. Include anche risposte a qualcuna delle domande poste più di frequente. <sect2 id="experimental">Experimental La distribuzione experimental è una distribuzione speciale. Non è una distribuzione completa nello senso in cui lo sono `stable' e `unstable'. È invece intesa ad essere un area di stasi temporanea per software altamente sperimentale dove c'è una buona possibilità che il software possa infrangere il tuo sistema, o software che è semplicemente troppo instabile persino per la distribuzione unstable (ma nonostante ciò esiste una ragione per farne un pacchetto). Gli utenti che scaricano e installano pacchetti da experimental ci si aspetta che siano stati debitamente avvisati. In breve, dalla distribuzione experimental non ci si può aspettare nulla.  Queste sono le linee di <manref name="sources.list" section="5"> per experimental: <example> deb http://ftp.<var>xy</var>.debian.org/debian/ ../project/experimental main deb-src http://ftp.<var>xy</var>.debian.org/debian/ ../project/experimental main </example> Se esiste una possibilità che il software possa fare gravi danni a un sistema, è altamente probabile che sia meglio metterlo in experimental. Per esempio, un file system compresso sperimentale dovrebbe probabilmente andare in experimental. Ogni volta che c'è una nuova versione upstream di un pacchetto che introduce nuove features ma ne infrange un gran numero di vecchie, o non si dovrebbe farne l'upload o si dovrebbe farlo in experimental. Una nuova versione beta di qualche software che usa una configurazione completamente differenrte può andare in experimental, a discrezione del mantainer. Se stai lavorando su una situazione in cui l'aggiornamento è incompatibile o complesso puoi anche usare experimental come un'area di stasi, in modo che i tester possano ottenerne un accesso rapido. Qualche software sperimentale può lo stesso andare in unstable, con qualche avviso nella descrizione, ma non è raccomandato in quanto i pacchetti da unstable ci si aspetta che si propaghino in testing e quindi in stable. Non dovresti temere di usare experimental siccome non causa alcun dolore agli ftpmaster, i pacchetti in experimental vengono rimossi automaticamente una volta che effettui l'upload del pacchetto in unstable con un numero di versione più alto. Nuovi software che probabilmente non danneggeranno il tuo sistema possono andare direttamente in unstable. Un alternativa a experimental è di usare il tuo spazio web personale su <tt>people.debian.org</tt>. <sect1 id="codenames">Nomi in codice delle release Ogni release di una distribuzione Debian ha un nome in codice: Debian 1.1 è chiamata `buzz'; Debian 1.2, `rex'; Debian 1.3, `bo'; Debian 2.0, `hamm'; Debian 2.1, `slink'; Debian 2.2, `potato'; e Debian 3.0, `woody'. C'è anche una ``pseudo-distribuzione'', chiamata `sid', che è la corrente distribuzione `unstable'; siccome i pacchetti vengono spostati da `unstable' a `testing' come si avvicinano a una condizione di stabilità, `sid' stessa non viene mai rilasciata. Così come i soliti contenuti di una distibuzione Debian, `sid' contiene pacchetti per architetture che non sono ancora ufficialmente supportate o rilasciate da Debian. Queste architetture sono pianificate a essere integrate nella distribuzione principale in qualche data futura. Siccome Debian ha un modello di sviluppo aperto (ovvero chiunque può partecipare e seguire lo sviluppo) anche le distribuzioni `unstable' e `testing' sono distribuite su internet attraverso la rete di server FTP e HTTP Debian. Quindi, se avessimo chiamato `testing' la directory che contiene la versione candidata alla release, avremmo dovuto rinominarla `stable' quando la versione fosse stata rilasciata, la qual cosa avrebbe forzato tutti i mirror FTP a riscaricarsi l'intera distribuzione (che è abbastanza grossa). D'altro canto, se avessimo chiamato sin dall'inizio le directory delle distribuzioni Debian-x.y, La gente penserebbe che la release Debian x.y è disponibile. (Ciò è successo in passato, un venditore di CD-ROM costruì un cdrom Debian 1.0 basato su una versione di sviluppo pre-1.0. Questa è la ragione per cui la prima release ufficiale Debian fu la 1.1 e non la 1.0.) Quindi, i nomi delle directory delle distribuzioni nell'archivio sono determinate dai loro nomi in codice e non dal loro stato di release (p.es. `slink'). Questi nomi rimangono sempre gli stessi durante il periodo di sviluppo e dopo il rilascio; link simbolici, che possono essere facilmente cambiati, indicano la release corrente della distribuzione stabile. Ecco perché le directory reali delle distribuzioni usano i nomi in codice, mentre link simbolici per stable, testing, e unstable puntano alle directory appropriate delle distribuzioni. <sect id="mirrors">Mirror Debian I vari archivi per i download e il sito web hanno diversi mirror disponibili in modo da non sottoporre i nostri server a carichi di lavoro troppo pesanti. In effetti, alcuni nostri server non sono pubblici — al loro posto, una prima serie di mirror si bilanciano il carico. In questo modo gli utenti accedono sempre ai mirror e si abituano ad usarli, la qual cosa permette a Debian di distribuire meglio i propri requisiti di banda su diversi server e network, e di base fa in modo che gli utenti evitino di accanirsi su una locazione primaria. Nota che la prima serie di mirror è sempre aggiornata in quanto si aggiornano al comando dei siti interni (chiamiamo questa cosa "push mirroring"). Tutte le informazioni sui mirror Debian, inclusa una lista dei server FTP/HTTP pubblici disponibili, possono essere trovate all'indirizzo <url id="&url-debian-mirrors;">. Questa utile pagina include anche informazioni e strumenti che possono esserti d'aiuto se sei interessato a impostare un mirror tuo, sia per uso interno o di pubblico accesso. Nota che i mirror sono generalmente gestiti da terze parti che sono interessate ad aiutare Debian, perciò gli sviluppatori generalmente non hanno un account su quelle macchine. <sect id="incoming-system"> <heading>Il sistema incoming Il sistema incoming è responsabile di collezionare pacchetti aggiornati e installarli nell'archivio Debian. Consiste in un insieme di directory e script che sono installati sia su <tt>&ftp-master-host;</tt> sia su <tt>&non-us-host;</tt>. I pacchetti vengono inviati in upload da tutti i mantainer in una directory chiamata <file>unchecked</file>. Questa directory viene scandita ogni 15 minuti dallo script <prgn>katie</prgn>, che verifica l'integrità dei pacchetti inviati in upload e le loro firme crittografiche. Se il pacchetto viene considerato pronto per essere installato, è spostato nella directory <file>accepted</file>. Se questo è il primo upload del pacchetto, esso viene spostato nella directory <file>new</file>, dove aspetta l'approvazione dei ftpmaster. Se il pacchetto contiene file che devono essere installati a mano viene spostato nella directory <file>byhand</file>, dove aspetta l'installazione manuale da parte dei ftpmaster. Altrimenti, se viene scovato un qualsiasi errore, il pacchetto viene rifiutato e spostato nella directory <file>reject</file>. Una volta che il pacchetto viene accettato il sistema manda una mail di conferma al mantainer, chiude tutti i bug marcati come risolti dall'upload e gli auto-builder possono cominciare a ricompilarlo. Il pacchetto è ora pubblicamente accessibile all'indirizzo <url id="&url-incoming;"> (non esiste nessun URL del genere per i pacchetti nell'archivio non-US) finchè non viene realmente installato nell'archivio Debian. Questo accade solo una volta al giorno, il pacchetto viene poi rimosso da incoming e installato nella pool con tutti gli altri pacchetti. Una volta che tutti gli altri aggiornamenti (per esempio la generazione dei nuovi file indice <file>Packages</file> e <file>Sources</file>) vengono completati, viene invocato uno script speciale per chiedere a tutti i mirror primari di aggiornarsi. Il software di manutenzione dell'archivio manderà inoltre i file <file>.changes</file> firmati con OpenPGP/GnuPG che hai inviato in upload alle mailing list appropriate. Se un pacchetto viene rilasciato con <tt>Distribution:</tt> impostato a `stable', l'annuncio è inviato a &email-debian-changes;. Invece, se il pacchetto viene rilasciato con <tt>Distribution:</tt> impostato a `unstable' oppure `experimental', l'annuncio verrà inviato a &email-debian-devel-changes;. Tutti gli sviluppatori Debian hanno accesso in scrittura alla directory <file>unchecked</file> in modo da inviare in upload i loro pacchetti, hanno anche tale accesso alla directory <file>reject</file> in modo da rimuovere i loro upload non validi o per spostare qualche file di nuovo nella directory <file>unchecked</file>. Ma tutte le altre directory sono scrivibili solo dagli ftpmaster, ecco perchè non puoi rimuovere un upload una volta che è stato accettato. <sect1 id="delayed-incoming">Incoming ritardato La directory <file>unchecked</file> ha una speciale sottodirectory <file>DELAYED</file>. Essa stessa è suddivisa in nove directory chiamate da <file>1-day</file> a <file>9-day</file>. I pacchetti che vengono inviati in upload in una di queste directory verranno spostati nella directory unchecked reale dopo il corrispondente numero di giorni. Questo viene fatto da uno script che è lanciato ogni giorno e che sposta i pacchetti tra le varie directory. Quelli che sono in "1-day" sono installati in <file>unchecked</file> mentre gli altri vengono spostati nelle directory adiacenti (per esempio, un pacchetto in <file>5-day</file> sarà spostato in <file>4-day</file>). Questa feature è particolarmente utile alle persone che stanno facendo dei non-maintainer uploads. Invece che aspettare prima di fare l'upload di un NMU, è inviato in upload appena è pronto in una di quelle directory <file>DELAYED/<var>x</var>-day</file>. Questo lascia il corrispondente numero di giorni al mantainer per reagire e fare loro stessi l'upload di un altro fix se non sono completamente soddisfatti dal NMU. In alternativa possono rimuovere il NMU. L'uso della feature delayed può essere semplificato con un poco di integrazione nel tuo strumento di upload. Per esempio, se usi <prgn>dupload</prgn> (vedi <ref id="dupload">), puoi aggiungere questo pezzetto  al tuo file di configurazione: <example> $delay = ($ENV{DELAY} || 7); $cfg{'delayed'} = { fqdn => "&ftp-master-host;", login => "iltuologindebian",  incoming => "/org/ftp.debian.org/incoming/DELAYED/$delay-day/", dinstall_runs => 1, method => "scpb" }; </example> Una volta che hai fatto tale modifica, <prgn>dupload</prgn> può essere usato per effettuare facilmente l'upload di un pacchetto in una delle directory delayed: <example>DELAY=5 dupload --to delayed <changes-file></example> <sect id="pkg-info">Informazioni sui pacchetti <sect1 id="pkg-info-web">Sul web Ciascun pacchetto ha diverse pagine web dedicate. <tt>http://&packages-host;/<var>package-name</var></tt> visualizza ogni versione del pacchetto disponibile nelle varie distribuzioni. Ogni versione si collega a una pagina che fornisce informazioni, inclusa la descrizione del pacchetto, le dipendenze e i collegamenti per il download del pacchetto. Il sistema di tracciamento dei bug tiene traccia dei bug per ogni pacchetto. Puoi vedere i bug di un certo pacchetto all' indirizzo <tt>http://&bugs-host;/<var>package-name</var></tt>. <sect1 id="madison">L'utility <prgn>madison</prgn> <prgn>madison</prgn> è un'utility a linea di comando che è disponibile su entrambi <tt>&ftp-master-host;</tt> e <tt>&non-us-host;</tt>. Usa un singolo argomento corrispondente al nome di un pacchetto. Come risultato visualizza quale versione del pacchetto è disponibile per ogni combinazione di architettura e distribuzione. Un esempio lo spiegherà meglio. <example> $ madison libdbd-mysql-perl libdbd-mysql-perl | 1.2202-4 | stable | source, alpha, arm, i386, m68k, powerpc, sparc libdbd-mysql-perl | 1.2216-2 | testing | source, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc libdbd-mysql-perl | 1.2216-2.0.1 | testing | alpha libdbd-mysql-perl | 1.2219-1 | unstable | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc </example> In questo esempio, puoi vedere che la versione in unstable è diversa da quella in testing e che c'è stato un NMU solo binario del pacchetto per l'architettura alpha. Ogni volta il pacchetto è stato ricompilato sulla maggior parte delle architetture. <sect id="pkg-tracking-system">Il sistema di tracciamento dei pacchetti Il sistema di tracciamento dei pacchetti (PTS) è uno strumento basato su e-mail atto a tenere traccia dell'attività di un pacchetto sorgente. Questo significa in realtà che puoi ricevere le stesse email che riceve il mantainer, semplicemente sottoscrivendoti al pacchetto nel PTS. Ogni email inviata attraverso il PTS viene classificata con una delle parole chiave sotto elencate. Questo ti permetterà di selezionare le email che vuoi ricevere. Di default riceverai: <taglist> <tag><tt>bts</tt> <item> Tutti i bug report e le conseguenti discussioni. <tag><tt>bts-control</tt> <item> Le notifiche email da <email>control@bugs.debian.org</email> circa i cambiamenti di stato dei bug report. <tag><tt>upload-source</tt> <item> Le notifiche email da <prgn>katie</prgn> quando un upload viene accettato. <tag><tt>katie-other</tt> <item> Altre email di avvertimento ed errore da <prgn>katie</prgn> (come una disparità di override per il campo sezione e/o priorità). <tag><tt>default</tt> <item> Qualunque email non automatica inviata al PTS da persone che volevano contattare i sottoscritti al pacchetto. Questo può essere fatto inviando una mail a <tt><var>sourcepackage</var>@&pts-host;</tt>. Per prevenire lo spam, tutti i messaggi inviati a quegli indirizzi devono contenere l'header <tt>X-PTS-Approved</tt> con un valore non vuoto. <tag><tt>summary</tt> <item> (Questa è un'espansione pianificata.) Le email regolari di riepilogo circa lo stato del pacchetto (statistiche sui bug, una vista d'insieme sul porting, il progresso in testing, ...). </taglist> Puoi anche decidere di ricevere delle informazioni addizionali: <taglist> <tag><tt>upload-binary</tt> <item> La notifica email da <prgn>katie</prgn> quando viene accettato un upload di un pacchetto binario. In altre parole, ogni volta che un demone di build o un porter effettua un upload del tuo pacchetto per un'altra architettura, puoi ricevere una email per tracciare come il tuo pacchetto venga ricompilato per tutte le architetture. <tag><tt>cvs</tt> <item> Notifiche di commit CVS, se il pacchetto ha un archivio CVS e il mantainer ha impostato l'inoltro delle notifiche di commit al PTS. <tag><tt>ddtp</tt> <item> Traduzioni di descrizioni o di template di debconf inviate al progetto di traduzione delle descrizioni Debian. </taglist> <sect1 id="pts-commands">L'interfaccia email del PTS Puoi controllare le tue sottoscrizioni al PTS mandando vari comandi a <email>pts@qa.debian.org</email>. <taglist> <tag><tt>subscribe <sourcepackage> [<email>]</tt> <item> Sottoscrive <var>email</var> alle comunicazioni relative al pacchetto sorgente <var>sourcepackage</var>. Se il secondo argomento non è presente viene usato l'indirizzo del mittente. Se <var>sourcepackage</var> non è un valido pacchetto sorgente, riceverai un avvertimento. Comunque se è un pacchetto binario valido, il PTS ti sottoscriverà al pacchetto sorgente corrispondente. <tag><tt>unsubscribe <sourcepackage> [<email>]</tt> <item> Rimuove una precedente sottoscrizione al pacchetto sorgente <var>sourcepackage</var> usando l'indirizzo email specificato oppure l'indirizzo del mittente se il secondo argomento non è specificato. <tag><tt>which [<email>]</tt> <item> Lista tutte le sottoscrizioni per il mittente o l'indirizzo email opzionalmente specificato. <tag><tt>keyword [<email>]</tt> <item> Ti dice le parole chiave che stai accettando. Per una spiegazione sulle parole chiave, <qref id="pkg-tracking-system">vedi sopra</qref>. Ecco un veloce riepilogo: <list> <item><tt>bts</tt>: mail provenienti dal sistema di tracciamento dei bug Debian <item><tt>bts-control</tt>: risposte alle mail inviate a &email-bts-control; <item><tt>summary</tt>: mail automatiche di repilogo sullo stato di un pacchetto <item><tt>cvs</tt>: notifiche di commit CVS <item><tt>ddtp</tt>: traduzioni di descrizioni e template di debconf <item><tt>upload-source</tt>: annuncio dell'avvenuta accettazione di un nuovo upload di sorgenti <item><tt>upload-binary</tt>: annuncio di un nuovo upload solo binario (porting) <item><tt>katie-other</tt>: altre mail dagli ftpmaster (disparità di override, ecc.) <item><tt>default</tt>: tutte le altre mail (quelle che non sono "automatiche") </list> <tag><tt>keyword <sourcepackage> [<email>]</tt> <item> Come il precededente ma per il dato pacchetto sorgente, siccome puoi selezionare un set di keyword differenti per ogni pacchetto sorgente. <tag><tt>keyword [<email>] {+|-|=} <lista di keyword></tt> <item> Accetta (+) o rifiuta (-) le mail classificate sotto le date parole chiave. Definisce la lista (=) delle parole chiave accettate. <tag><tt>keyword <sourcepackage> [<email>] {+|-|=} <lista di keyword></tt> <item> Come il precedente ma sovrascrive la lista delle parole chiave per il pacchetto sorgente indicato. <tag><tt>quit | thanks | --</tt> <item> Ferma l'analisi dei comandi. Tutte le linee successive sono ignorate dal bot. </taglist> <sect1 id="pts-mail-filtering">Filtrare le mail del PTS Una volta che sei sottoscritto a un pacchetto, riceverai le mail spedita a <tt><var>sourcepackage</var>@packages.qa.debian.org</tt>. Queste mail hanno appesi degli header speciali per lasciartele filtrare in una mailbox speciale (p.es. con <prgn>procmail</prgn>). Gli header aggiunti sono <tt>X-Loop</tt>, <tt>X-PTS-Package</tt>, <tt>X-PTS-Keyword</tt> e <tt>X-Unsubscribe</tt>. Ecco un esempio di header aggiunti per una notifica di upload di sorgenti del pacchetto <package>dpkg</package>: <example> X-Loop: dpkg@&pts-host; X-PTS-Package: dpkg X-PTS-Keyword: upload-source X-Unsubscribe: echo 'unsubscribe dpkg' | mail pts@qa.debian.org </example> <sect1 id="pts-cvs-commit">Inoltrare i commit CVS nel PTS Se usi un archivio CVS pubblicamente accessibile per mantenere il tuo pacchetto Debian puoi volere inoltrare le notifiche di commit al PTS in modo che chi si è sottoscritto (e i possibili co-mantainer) possano seguire da vicino l'evoluzione del pacchetto. Una volta che hai impostato l'archivio CVS per generare le notifiche di commit, devi semplicemente assicurarti che mandi una copia di queste email a <tt><var>sourcepackage</var>_cvs@&pts-host;</tt>. Solo le persone che accettano la keyword cvs riceveranno queste notifiche. <sect1 id="pts-web">L'interfaccia web del PTS Il PTS ha un'interfaccia web all'indirizzo <url id="http://&pts-host;/"> che mette insieme un grande numero di informazioni su ogni pacchetto sorgente. Mette in evidenza molti link utili (BTS, statistiche di QA, informazioni sui contatti, stato delle traduzioni DDTP, log di buildd) e raccoglie molte altre informazioni da vari posti (le ultime 30 voci di changelog, stato di testing, ...). È uno strumento molto utile se vuoi conoscere cosa sta succedendo su uno specifico pacchetto sorgente. Oltretutto c'è una form che permette di sottoscriversi facilmente al PTS via email. Puoi saltare direttamente alla pagina web di uno specifico pacchetto sorgente con un URL tipo <tt>http://&pts-host;/<var>sourcepackage</var></tt>. Questa interfaccia web è stata designata come un portale per lo sviluppo di pacchetti: puoi aggiungere contenuti personalizzati sulle pagine dei tuoi pacchetti. Puoi aggiungere "informazioni statiche" (notizie che devono essere disponibili per un tempo indefinito) e notizie nella sezione "latest news" (ultime notizie). Notizie statiche possono essere usate per indicare: <list> <item>la disponibilità di un progetto ospitato su <qref id="alioth">Alioth</qref> per co-mantenere il pacchetto <item>un link per il sito web upstream <item>un link al bug tracker upstream <item>l'esistenza di un canale IRC dedicato al software <item>qualunque altra risorsa disponibile che può essere utile per la manutenzione del pacchetto </list> Notizie classiche possono essere usate per annunciare che: <list> <item>pacchetti beta sono disponibili per il testing <item>si aspettano pacchetti finali per la prossima settimana <item>la pacchettizazione sta per essere rifatta da zero <item>sono disponibili dei backport <item>il mantainer è "in vacanza" (se vogliono pubblicare questa informazione) <item>si sta lavorando per un NMU <item>qualcosa di importante sta per essere fatto al pacchetto </list> Entrambi i tipi di news sono generati in maniera simile: devi solo mandare una email a <email>pts-static-news@qa.debian.org</email> oppure a <email>pts-news@qa.debian.org</email>. La mail dovrebbe indicare a quale pacchetto concerne mettendo il nome del pacchetto sorgente nell'header <tt>X-PTS-Package</tt> della email o in un pseudo-header <tt>Package</tt> (come nei report del BTS). Se un URL è disponibile nell'header <tt>X-PTS-Url</tt> della email o nel pseudo-header tt>Url</tt>, allora il risultato è un link a tale URL invece che una completa news. Ecco qualche esempio di mail valide usate per generare news nel PTS. Il primo aggiunge un link all'interfaccia cvsweb di debian-cd nella sezione "informazioni statiche": <example> From: Raphael Hertzog <hertzog@debian.org> To: pts-static-news@qa.debian.org Subject: Browse debian-cd CVS repository with cvsweb Package: debian-cd Url: http://cvs.debian.org/debian-cd/ </example> Il secondo è un annuncio spedito a una mailing list che è anche mandato al PTS in modo che venga pubblicato sulla pagina web PTS del pacchetto. Nota l'uso del campo BCC per evitare risposte inviate per errore al PTS. <example> From: Raphael Hertzog <hertzog@debian.org> To: debian-gtk-gnome@lists.debian.org Bcc: pts-news@qa.debian.org Subject: Galeon 2.0 backported for woody X-PTS-Package: galeon Hello gnomers! I'm glad to announce that galeon has been backported for woody. You'll find everything here: ... </example> Pensaci due volte prima di aggiungere una news al PTS perchè dopo non sarai più in grado di rimuoverla e nemmeno di modificarla. L'unica cosa che puoi fare è mandare un'altra news che renderà obsolete le informazioni contenute nella precedente. <sect id="ddpo">Vista d'insieme dei pacchetti degli sviluppatori Un portale web di QA (assicurazione qualità) è disponibile all'indirizzo <url id="&url-ddpo;"> che mostra una tabella che elenca tutti i pacchetti di un singolo sviluppatore (includendo quelli in cui è elencato come co-maintainer). La tabella ti da un buon riepilogo sui pacchetti dello sviluppatore: numero di bug per severità, lista delle versioni disponibili in ogni distribuzione, stato di testing e molto altro inclusi i link a qualunque altra informazione utile. È una buona idea quella di controllare regolarmente i tuoi stessi dati in modo da non dimenticarti di nessun bug aperto e in modo di non dimenticarti quali pacchetti sono sotto la tua responsabilità. <sect id="alioth">Debian *Forge: Alioth Alioth è un servizio Debian abbastanza nuovo, basato su una versione leggermente modificata del software GForge (un evoluzione di SourceForge). Questo software offre agli sviluppatori accesso a strumenti facili da usare come bug tracker, patch manager, project/task manager, servizi di hosting di file, mailing list, archivi CVS ecc. Tutti questi strumenti sono gestiti tramite interfaccia web. È inteso a fornire infrastrutture a progetti di software libero spalleggiati o diretti da Debian, facilitare le contribuzioni da sviluppatori esterni ai progetti iniziati da Debian e aiutare i progetti i cui obiettivi sono la promozione di Debian o dei suoi derivati. Per informazioni aggiuntive visita <url id="&url-alioth;">. <chapt id="pkgs">Gestire i pacchetti Questi capitolo contiene informazioni relativa alla creazione, upload, gestione e "porting" di pacchetti. <sect id="newpackage">Nuovi pacchetti Se vuoi creare un nuovo pacchetto per la distribuzione Debian, dovresti prima consultare la lista dei <url id="&url-wnpp;" name="Pacchetti aventi bisogno di lavoro e futuri"> (WNPP). Controllando tale lista puoi assicurarti che nessuno stia ancora lavorando per fare un pacchetto di quel software, e che non si duplichino gli sforzi. Leggi le <url id="&url-wnpp;" name="pagine web WNPP"> per ulteriori informazioni. Assumendo che nessun'altro stia già lavorando sul tuo futuro pacchetto, devi segnalare un bug (<ref id="submit-bug">) verso il pseudo-pacchetto <package>wnpp</package> descivendo la tua intenzione di creare un nuovo pacchetto includendo, ma non limitandoti a, la descrizione del pacchetto, la sua licenza e l'URL da dove può essere scaricato. Dovresti mettere come soggetto ``ITP: <var>foo</var> -- <var>short description</var>'', sostituendo il nome del nuovo paccheto a <var>foo</var>. La severità del bug dovrebbe essere impostata a wishlist. Se pensi che sia necessario, mandane una copia a &email-debian-devel; impostando l'indirizzo nell'intestazione <tt>X-Debbugs-CC:</tt> del messaggio (no, non usare <tt>CC:</tt>, perchè in quel modo l'oggetto del messaggio non riporterà il numero del bug). Per favore includi un campo <tt>Closes: bug#<var>nnnnn</var></tt> nel changelog nuovo pacchetto in modo da automaticamente chiudere il bug quando il nuovo pacchetto entrerà nell'archivio. (<ref id="upload-bugfix">). Ci sono diverse ragioni per le quali chiediamo ai mantainers di annunciare le loro inenzioni: <list compact> <item> Aiuta i (potenziali nuovi) mantainer di sfruttare l'esperienza delle persone della lista, e fa loro sapere se qualcun'altro ci sta già lavorando sopra. <item> Fa sapere ad altre persone che stanno pensando di lavorare sul pacchetto che esiste già un volontario, quindi gli sforzi possono essere ripartiti. <item> Fa sapere agli altri mantainer di più sul pacchetto alla descrizione di una sola linea e la frase ``Initial release'' del changelog che viene spedita a <tt>debian-devel-changes</tt>. <item> È di aiuto per le persone che usano unstable (e formano la nostra prima linea di tester). Dovremmo incoraggiare queste persone. <item> Gli annunci fanno sapere ai mantainter e alle altre parti interessate cosa sta succedendo e cosa c'è di nuovo all'interno del progetto. </list> <sect id="changelog-entries">Registrare i cambiamenti dei pacchetti Le modifiche che apporti al pacchetto devono essere registrate nel <file>debian/changelog</file>. Le registrazioni devono contenere una descrizione concisa di cosa è cambiato, perchè (se non è chiaro) e specificare se dei bug sono stati chiusi. Registrano anche quando il pacchetto è stato completato. Questo file verrà installato in <file>/usr/share/doc/<var>package</var>/changelog.Debian.gz</file>, o <file>/usr/share/doc/<var>package</var>/changelog.gz</file> per i pacchetti nativi. Il file <file>debian/changelog</file> è conforme a una certa struttura, con diversi campi. Un campo degno di nota, distribution, è descritto in <ref id="distribution">. Ulteriori informazioni sulla struttura di questo file possono essere trovate nella sezione della Policy Debian intitolata "<file>debian/changelog</file>". Le voci nel changelog possono essere usate per chiudere automaticamente dei bug Debian quando il pacchetto verrà installato nell'archivio. Leggi <ref id="upload-bugfix">. È una cosa convenzionale che la voce del changelog di un pacchetto che contiene una nuova versione del software sia: <example> * new upstream version </example> Esistono degli strumenti che ti permettono di creare voci e completare il <file>changelog</file> per il rilascio — leggi <ref id="devscripts"> e <ref id="dpkg-dev-el">. Leggi anche <ref id="bpp-debian-changelog">. <sect id="sanitycheck">Controllare il pacchetto Prima di effettuare l'upload di un pacchetto, dovresti effettuare dei controlli di base su di esso. Dovresti almeno provare a svolgere le seguenti attività di base (avrai bisogno di avere da qualche parte una vecchia versione dello stesso pacchetto): <list> <item> Installa il pacchetto e assicurati che il software funziona, o aggiorna il pacchetto da una vecchia versione alla tua nuova se un pacchetto Debian per esso esiste già. <item> Lancia <prgn>lintian</prgn> sul pacchetto. Puoi lanciare <prgn>lintian</prgn> come segue: <tt>lintian -v <var>package-version</var>.changes</tt>. In questo modo saranno controllati sia il pacchetto sorgente che il pacchetto binario. Se non capisci l'output generato da <prgn>lintian</prgn> prova ad aggiungere lo switch <tt>-i</tt>, che porterà <prgn>lintian</prgn> a riportare una descrizione molto prolissa del problema. Normalmente, non si dovrebbe effettuare l'upload di un pacchetto se lintian segnala degli errori (cominceranno con <tt>E</tt>). Per ulteriori informazioni su <prgn>lintian</prgn>, leggi <ref id="lintian">. <item> Opzionalmente lancia <ref id="debdiff"> per analizzare i cambiamenti dalla versione precedente, se ne esiste una. <item> Effettua un downgrade del pacchetto alla versione precedente (se esiste) — questo mette alla prova gli script <file>postrm</file> e <file>prerm</file>. <item> Rimuovi il pacchetto, poi reinstallalo. </list> <sect id="sourcelayout">Layout del pacchetto sorgente Esistono due tipi di pacchetti Debian sorgenti: <list> <item> i cosiddetti pacchetti nativi, nei quali non c'è distinzione tra i sorgenti originali e le patch applicate per Debian <item> i (più comuni) pacchetti dove esistono i sorgenti originali accompagnati da un altro file che contiene le patch applicate per Debian. </list> Per i pacchetti nativi, il pacchetto sorgente include un file Debian di controllo dei sorgenti (<tt>.dsc</tt>) e il file con i sorgenti (<tt>.tar.gz</tt>). Il pacchetto sorgente di un pacchetto non-nativo include il file Debian di controllo dei sorgenti, il file con i sorgenti originali (<tt>.orig.tar.gz</tt>) e le patch Debian (<tt>.diff.gz</tt>). Se un pacchetto è nativo oppure no viene determinato quando viene costruito da <manref name="dpkg-buildpackage" section="1">. Il resto di questa sezione si riferisce solo ai pacchetti non-nativi. La prima volta che viene effettuato l'upload di una nuova versione corrispondente a una nuova versione upstream, dovrebbe essere effettuato l'upload anche del file tar dei sorgenti originali includendolo nel file <file>.changes</file>. Conseguentemente, quello stesso file tar dovrebbe essere usato per costruire le nuove "diff" e i nuovi file <file>.dsc</file>, senza bisogno di ripeterne l'upload. Per default, <prgn>dpkg-genchanges</prgn> e <prgn>dpkg-buildpackage</prgn> includeranno i sorgenti originali se e solo se la parte realativa alla revisione Debian del numero di versione del sorgente è 0 o 1, indicante una nuova versione upstream. Questo comportamento può essere modificato usando <tt>-sa</tt> per includerlo sempre o <tt>-sd</tt> per lasciarlo sempre da parte. Se nessun sorgente originale viene incluso nell'upload, il file tar dei sorgenti originali usato da <prgn>dpkg-source</prgn> per costruire il file <file>.dsc</file> le diff per farne l'upload deve essere byte-per-byte identico a quello già presente in archivio. <sect id="distribution">Scegliere la distribuzione Ogni upload deve specificare in quale distribuzione deve essere incluso il pacchetto. Il processo di costruzione del pacchetto estrae questa informazione dalla prima linea del file <file>debian/changelog</file> e la pone nel campo <tt>Distribution</tt> del file <tt>.changes</tt>. Ci sono diversi valori possibili per questo campo: `stable', `unstable', `testing-proposed-updates' e `experimental'. Normalmente, al momento dell'upload i pacchetti sono destinati a unstable. Attualmente, ci sono altre due distribuzioni possibili: `stable-security' e `testing-security', ma per queste leggi <ref id="bug-security"> per ulteriori informazioni. Tecnicamente è possibile effettuare l'upload di un pacchetto in più distribuzioni allo stesso tempo ma di solito non ha alcun senso farlo perchè le dipendenze del pacchetto possono cambiare a seconda della distribuzione. In particolare, non ha mai senso combinare la distribuzione experimental con qualunque altra. (vedi <ref id="experimental">). <sect1 id="upload-stable"> <heading>Caso speciale: upload alla distribuzione stable Effetuare un upload alla distribuzione stable implica che il pacchetto verrà posto nella directory <file>stable-proposed-updates</file> dell'archivio Debian per essere ulteriormente testata prima che sia realmente incluso in stable. Bisognerebbe apporre maggiore attenzione quando si effettua un upload per stable. Di base, un pacchetto dovrebbe essere mandato in upload in stable solo se si verifica uno dei seguenti casi: <list> <item>un problema nella funzionalità realmente critico <item>il pacchetto diventa ininstallabile <item>manca il pacchetto in una certa architettura </list> Nel passato, si usava fare upload verso stable anche per problemi relativi alla sicurezza. Comunque, questa pratica è sconsigliata in quanto gli upload usati per gli advisory di sicurezza Debian sono automaticamente copiati nell'archivio <file>proposed-updates</file> appropriato quando l'advisory viene rilasciata. Vedi <ref id="bug-security"> per informazioni dettagliate su come gestire i problemi di sicurezza. Cambiare qualsiasi altra cosa nel pacchetto che non sia importante è sconsigliato, perchè perfino i fix piu' scontati possono in seguito causare dei bug. Pacchetti mandati in upload su stable devono essere compilati in sistemi che girano su stable, in modo che le loro dipendenze siano limitate alle librerie (e altri pacchetti) disponibili in stable; per esempio, un pacchetto di cui si sia effettuato l'upload in stable che dipende da una libreria esistente solo in unstable sarà rifiutato. Effettuare cambiamenti alle dipendenze di altri pacchetti (giocando con <tt>Provides</tt> o file shlibs), rendendo questi altri pacchetti possibilmente ininstallabili, è fortemente sconsigliato. Il "Release Team" (che può essere contattato tramite &email-debian-release;) valuterà regolarmente gli upload in stable-proposed-updates e deciderà se il tuo pacchetto può essere incluso in stable. Per favore sii chiaro (e prolisso se necessario) nelle voci nel tuo changelog per gli upload in stable, in quanto altrimenti il pacchetto non sarà considerato per l'inclusione. <sect1 id="upload-t-p-u"> <heading> Caso speciale: upload a testing-proposed-updates</heading> La distribuzione testing è composta dai pacchetti da unstable in accordo alle regole spiegate in <ref id="testing">. In ogni caso, il release manager può fermare gli script di testing quando ha intenzione di fare un "freeze" della distribuzione. In quel caso, puoi volere effettuare upload a testing-proposed-updates per fornire fix di pacchetti durante il freeze. Tieni a mente che quegli upload non sono processati automaticamente, devono passare per le mani del release manager. Dovresti quindi avere una buona ragione per effettuare upload lì. Per sapere quale sia una buona ragione negli occhi del release manager, dovresti leggere le istruzioni che regolarmente da su &email-debian-devel-announce;. Non dovresti effettuare upload su testing-proposed-updates quando puoi aggiornare i toi pacchetti attraverso unstable. Se non puoi (per esempio perchè hai una nuova versione in sviluppo in unstable), puoi usarlo ma è raccomandato chiedere prima l'autorizzazione al release manager. <sect id="upload">Effetuare un upload <sect1 id="upload-ftp-master">Inviare un upload a <tt>ftp-master</tt> Per inviare un pacchetto in upload, hai bisogno di un account personale su <ftpsite>&ftp-master-host;</ftpsite>, cosa che dovresti avere essendo un mantainer ufficiale. Se usi <prgn>scp</prgn> o <prgn>rsync</prgn> per trasferire i file, posizionali in &us-upload-dir;; se usi FTP anonimo, posizionali in &upload-queue;. Se vuoi usare la funzione descritta in <ref id="delayed-incoming">, dovrai mandare l'upload a <tt>ftp-master</tt>. È l'unico punto di upload che supporta l'immissione ritardata. Per piacere nota che dovresti trasferire il file changes per ultimo. Altrimenti, il tuo upload può essere rifiutato perchè il software di manutenzione dell'archivio scorrerà il file changes e vedrà che non tutti i file sono stati inviati in upload. Se non hai voglia di trasferire il file changes per ultimo, puoi semplicimente copiare i tuoi file in una directory temporanea in <tt>ftp-master</tt> e quindi spostarli in &us-upload-dir;. Nota: Non inviare a <tt>ftp-master</tt> upload di pacchetti crittografici che appartengono a contrib o non-free. Upload di tali software dovrebbero andare a <tt>non-us</tt> (vedi <ref id="upload-non-us">). Inoltre pachetti contenenti codice brevettato da il governo degli Stati Uniti non possono essere inviati in upload a <tt>ftp-master</tt>; dipendentemente dal caso potrebbero essere comunque inviati a <file>non-US/non-free</file> (è in non-free per caratteristiche della distribuzione e non a causa della licenza del software). Se non puoi inviarlo in upload a <tt>ftp-master</tt>, non puoi neanche farlo alle code di upload oltreoceano su <tt>chiark</tt> o <tt>erlangen</tt>. Se non sei sicuro se i controlli sulle licenze o sualla crittografia degli Stati Uniti si applicano al tuo pacchetto, manda un messaggio a &email-debian-devel; e chiedi. Puoi anche trovare utili per l'upload dei pacchetti i pacchetti Debian <ref id="dupload"> o <ref id="dput">. Questi maneggevoli programmi aiutano ad automatizzare il processo dell'upload di pacchetti in Debian. Dopo l'upload del tuo pacchetto, puoi controllare come il software di manutenzione dell'archivio lo processerà facendo girare <prgn>dinstall</prgn> sul tuo file changes: <example>dinstall -n foo.changes</example> Nota che <prgn>dput</prgn> può automaticamente fare questo per te. <sect1 id="upload-non-us">Inviare un upload a <tt>non-US</tt> Come sopra discusso, sofware a esportazione controllata non dovrebbero essere inviati a <tt>ftp-master</tt>. Al suo posto, spedisci il pacchetto a <ftpsite>non-us.debian.org</ftpsite>,ponendo i file in &non-us-upload-dir; (di nuovo, sia <ref id="dupload"> che <ref id="dput">possono fare questo per te se propriamente invocati). Di default, puoi usare gli stessi account/password che usi su <tt>ftp-master</tt>. Se per gli upload usi FTP anonimo, poni i file in &upload-queue;. Puoi controllare i tuoi upload allo stesso modo di come fai su <tt>ftp-master</tt>, con: <example>dinstall -n foo.changes</example> Nota che i cittadini o i residenti negli Stati Uniti sono soggetti a restrizioni sull'esportazione di software crittografico. Al tempo della scrittura di questo documento, i cittadini degli Stati Uniti sono autorizzati a esportare qualche software crittografico, soggetto a regole di notificazione dal Dipartimento sul Commercio degli Stati Uniti. Comunque, questa restrizione è stata posta in deroga per i software già disponibile al di fuori degli Stati Uniti. Di conseguenza, qualsiasi software crittografico che appartiene alla sezione main dell'archivio Debian e che non dipende da nessun pacchetto esterno a main (e.g., non dipende da niente in non-US/main) puo' essere inviato a <tt>ftp-master</tt> o alle sue code, sopra descritte. La policy Debian non previene upload su non-US da cittadini o residenti degli Stati Uniti, ma queste persone dovrebbero fare attenzione nel farlo. È raccomandato che gli sviluppatori intraprendano tutti i passi necessari per assicurarsi che non violino le correnti leggi degli Stati Uniti effettuando un upload su non-US, compreso consultarsi con un avvocato. Per i pacchetti in non-US/main, non-US/contrib, gli sviluppatori dovrebbero almeno seguire le <url id="&url-u.s.-export;" name="procedure specificate dal Governo degli Stati Uniti">. I mantainer di pacchetti in non-US/non-free dovrebbero in aggiunta consultare le <url id="&url-notification-of-export;" name="regole per la notificazione dulle esportazioni"> sul software non libero. Questa sezione è esclusivamente a titolo informativo e non costituisce dei consigli legali. Di nuovo, è fortemente raccomandato che i cittadini e residenti degli Stati Uniti consultino un avvocato prima di effettuare upload a non-US. <sect1>Upload via <tt>chiark</tt> Se hai una connessione di rete lenta verso <tt>ftp-master</tt>, esistono delle alternative. Una è quella di inviare file in upload a <file>Incoming</file> attraverso una coda di upload in Europa su <tt>chiark</tt>. Per dettagli collegati a <url id="&url-chiark-readme;">. Nota: Non inviare in upload pacchetti contenenti software che è a esportazione controllata dal governo degli Stati Uniti sulla coda in <tt>chiark</tt>. Siccome questa coda di upload va in <tt>ftp-master</tt>, le prescrizioni trovate in <ref id="upload-ftp-master"> si applicano anche qua.  Il programma <prgn>dupload</prgn> supporta gli upload a <tt>chiark</tt>; per favore fai riferimento alla documentazione fornita con il programma per i dettagli. <sect1>Upload via <tt>erlangen</tt> Un altra coda di upload è disponibile in Germania: semplicemente invia i file in upload via FTP anonimo a <url id="&url-upload-erlangen;">. L'upload deve essere un upload completo Debian, come lo invieresti a <file>Incoming</file> di <tt>ftp-master</tt>, ovvero dei file <file>.changes</file> insieme agli altri file menzionati nei <file>.changes</file> stessi. Il demone della coda controlla anche che il <file>.changes</file> sia correttamente firmato con GnuPG o OpenPGP da uno sviluppatore Debian, in modo che nessun file fasullo possa intrufolarsi in <tt>ftp-master</tt> attraverso questa coda. PEr favore assicurati anche che il campo <tt>Maintainer</tt> nel <file>.changes</file> contiene il tuo indirizzo e-mail. L'indirizzo lì trovato è usato per tutte le risposte, proprio come in <tt>ftp-master</tt>. Non c'è alcn bisogno di muovere i tuoi file in una directory secondaria dopo l'upload, come su <tt>chiark</tt>. E, in ogni caso, dovresti ricevere una mail di risposta dal demone della coda spiegando cosa è successo al tuo pacchetto. È sperabile che sia stato spostato in <tt>ftp-master</tt>, ma in caso di errori sarai comunque avvisato. Nota: Non inviare in upload pacchetti contenenti software che è a esportazione controllata dal governo degli Stati Uniti sulla coda in <tt>erlangen</tt>. Siccome questa coda di upload va in <tt>ftp-master</tt>, le prescrizioni trovate in <ref id="upload-ftp-master"> si applicano anche qua.  Il programma <prgn>dupload</prgn> supporta gli upload a <tt>erlangen</tt>; per favore fai riferimento alla documentazione fornita con il programma per i dettagli. <sect1>Altre code di upload Un altra coda di upload basata negli Stati Uniti è disponibile, ed è un buon backup nel caso ci siano problemi a raggiungere <tt>ftp-master</tt>. Puoi inviare file in upload, esattamente come in <tt>erlangen</tt>, a <url id="&url-upload-samosa;">. Una coda di upload è disponibile in Giappone: semplicemente invia i file in upload via FTP anonimo a <url id="&url-upload-jp;">. <sect1 id="upload-notification"> <heading>Notificazione che un nuovo pacchetto è stato installato</heading> I mantainer dell'archivio Debian sono responsabili per la gestione degli upload dei pacchetti. Per la maggior parte, gli upload sono giornalmente gestiti automaticamente dagli strumenti di manutenzione dell'archivio, <prgn>katie</prgn>. Specificatamente, gli aggiornamenti di pacchetti esistenti nella distribuzione `unstable' sono gestiti automaticamente. In altri casi, specialmente nei nuovi pacchetti, il posizionamento del pacchetto in upload nella distribuzione è gestito manualmente. Quando gli upload sono gestiti manualmente, il cambiamento all'archivio può prendere fino a un mese di tempo. Per favore sii paziente. In ogni caso, riceverai una email di notifica indicante che il pacchetto è stato aggiunto all'archivio, la quale indica anche quali bug saranno chiusi dall'upload. Per favore esamina con attenzione la notifica, controllando se qualche bug che avevi intenzione di chiudere non è scattato. La notifica di installazione ti informerà anche su in quale sezione il pacchetto è stato inserito. Se esiste disparità, riceverai una email separata per avvisarti di ciò. Continua a leggere sotto. Nota anche che se effettui upload attraverso le code, anche il software demone di coda ti manderà una notifica via email. <sect id="override-file">Specificare sezione, sottosezione e priorità del pacchetto I campi <tt>Section</tt> e <tt>Priority</tt> del file <file>debian/control</file> non specifica in realtà in che luogo il file verrà piazzato nell archivio, e nemmeno la sua priorità. Per conservare l'integrità complessiva dell'archivio, sono i mantainer dell'archivio che hanno il controllo su quei campi. I valori nel file <file>debian/control</file> sono in realtà solo suggerimenti. I mantainer dell'archivio tengono traccia delle sezioni e priorità canoniche per i pacchetti nel file override. Se esiste una disparità tra il file override e i campi indicati nel file <file>debian/control</file>, allora riceverai una email notificante la divergenza quando il pacchetto sarà installati nell'archivio. Puoi o correggere il tuo file <file>debian/control</file> per il tuo prossimo upload, oppure puoi desiderare di apportare una modifica nel file override. Per alterare la sezione reale in cui viene posto un pacchetto, devi prima assicurarti che il <file>debian/control</file> nel tuo pacchetto sia accurato. Dopodichè, manda una email a &email-override; oppure segnala un bug di <package>ftp.debian.org</package> richiedendo che la sezione o la priorità del tuo pacchetto venga modificata dalla vecchia alla nuova. Assicurati di spiegare le tue ragioni. Per ulteriori informazioni circa i file override, vedi <manref name="dpkg-scanpackages" section="8"> e <url id="&url-bts-devel;#maintincorrect">. Nota che il campo <tt>Section</tt> specifica sia la sezione che la sottosezione, descritte in <ref id="archive-sections">. Se la sezione è "main", dovrebbe essere omessa. La lista delle sottosezioni permesse può essere trovata in <url id="&url-debian-policy;ch-archive.html#s-subsections">. <sect id="bug-handling">Gestire i bug Ogni sviluppatore deve essere in grado di lavorare con il <url name="sistema di tracciamento dei bug" id="&url-bts;"> Debian. Questo include sapere come archiviare  propriamente i bug report (vedi <ref id="submit-bug">), come aggiornarli e registrarli, e come processarli e chiuderli. Le caratteristiche  del sistema di tracciamento dei bug interessanti per gli sviluppatori sono descritte nella <url id="&url-bts-devel;" name="documentazione per gli sviluppatori sul BTS">. Questo include chiudere bug, inviare messaggi di followup, assegnare severità e tag, marcare bug come inoltrati e altro. Operazioni come reassegnare bug ad altri pacchetti, unire  bug report separati che riguardano la stessa cosa, o riaprire bug quando sono stati chiusi premeturamente, sono gestite usando il cosiddetto mail server di controllo.  Tutti i comandi disponibili in questo server sono descritti nella <url id="&url-bts-control;" name="documentazione del server di controllo del BTS">.  <sect1 id="bug-monitoring">Monitorare i bug Se vuoi essere un buon mantainer, dovresti cotrollare periodicamente il <url id="&url-bts;" name="sistema di tracciamento dei bug Debian (BTS)"> per i tuoi pacchetti. Il BTS contiene tutti i bug aperti contro i tuoi pacchetti. Puoi controllarli visitando questa pagina: <tt>http://&bugs-host;/<var>latualogin</var>@debian.org</tt>. I mantainer interagiscono con il BTS attraverso l'indirizzo email <tt>&bugs-host;</tt>. La documentazione sui comandi disponibili può essere trovata su <url id="&url-bts;">, oppure, se hai installato il pacchetto <package>doc-debian</package>, puoi dare un'occhiata ai file in locale &file-bts-docs;. Qualcuno trova utile ricevere dei resoconti periodici sui bug aperti. Puoi aggiungere un cron job  come i seguenti se vuoi ricevere settimanalmente una email sottolineante  tutti i bug aperti contro i tuoi pacchetti. <example> # chiedi un resoconto settimanale sui bug nei miei pacchetti &cron-bug-report; </example> Sostituisci <var>address</var> con il tuo indirizzo come mantainer ufficiale Debian. <sect1 id="bug-answering">Rispondere ai bug Quando rispondi ai bug, assicurati che qualunque discussione tu intraprenda circa i bug sia inviata sia a chi ha originalmente inviato il bug che al bug stesso (p.es., <email>123@&bugs-host;</email>). Se stai scrivendo una nuova email e non ricordi l'indirizzo email di chi ha inviato il bug, puoi usare l'indirizzo <email>123-submitter@&bugs-host;</email> per contattarlo e memorizzare la tua email nel log del bug (ciò significa che non hai bisogno di inviare una copia della mail a <email>123@&bugs-host;</email>). Se ricevi un bug recante la dicitura "FTBFS", ciò significa "Fails to build from source" - fallisce durante il build dai sorgenti . I porter usano spesso questo acronimo. Una volta che hai finito con un bug  (p.es. lo hai risolto), marcalo con done (chiudilo) mandando un messaggio esplicativo a <email>123-done@&bugs-host;</email>. Se stai risolvendo un bug cambiando il pacchetto ed effettuandone un upload, puoi automatizzare la chiusura del bug come descritto in <ref id="upload-bugfix">. Non dovresti mai chiudere bug attraverso il comando del bug server <tt>close</tt> inviato a &email-bts-control;. Se fai così, il segnalatore originario non riceverà alcuna informazione sul perchè detto bug è stato chiuso. <sect1 id="bug-housekeeping">Bug housekeeping  Come mantainer, toverai spesso bug in altri pacchetti o ti verranno segnalati bug in tuoi pacchetti che sono in realtà bug di altri pacchetti. Le feature del sistema di tracciamento dei bug interessanti per gli sviluppatori sono descritte nella <url id="&url-bts-devel;" name="Documentazione sul BTS per gli sviluppatori Debian">. Operazioni come reassegnare, fondere e marcare le segnalazioni di bug sono descritte nella <url id="&url-bts-control;" name="documentazione del server di controllo del BTS">. Questa sezione contiene alcune linee guida per la gestione dei tuoi bug, basate sull'esperienza collettiva degli sviluppatori Debian. Segnalare bug per problemi che incontri in altri pacchetti fa parte degli "obblighi civili"  nell'essere un mantainer, vedi <ref id="submit-bug"> per i dettagli. In ogni caso, gestire i bug nei tuoi stessi pacchetti è ancora più importante. Di seguito è riportata una lista di passi che puoi seguire per gestire una segnalazione di bug. <enumlist> <item> Stabilire se la segnalazione corrisponda o meno realmente a un bug. A volte gli utenti stanno solo invocando un programma nel modo sbagliato perchè non hanno letto la documentazione. Se pensi che sia successo in realtà questo, chiudi semplicemente il bug indicando abbastanza informazioni per permettere all'utente di risolvere il problema (indica la giusta documentazione e cose così). Se giungono in continuazione segnalazioni sullo stesso problema potresti chiederti se la documentazione sia adeguata o se il programma non dovrebbe accorgersi del problema e mandare in output un messaggio di errore più informativo.  Questo potrebbe essere un problema da sottoporre all'autore del software. Se il segnalatore originale del bug non è d'accordo con la tua decisione di chiudere il bug, possono riaprirlo finchè non trovate un accordo su come gestirlo. Se non riesci a trovarlo, puoi volere marcare il bug <tt>wontfix</tt> per fare sapere alla gente che il bug esiste ma che non sarà corretto. Se questa situazione è inaccettabile, tu (o il segnalatore) puoi richiedere una "sentenza" della commissione tecnica riassegnando il bug a <package>tech-ctte</package> (puoi usare il comando "clone" del BTS se desideri di tenerlo segnalato sul tuo pacchetto). Prima di farlo, per piacere leggi le <url id="&url-tech-ctte;" name="procedure raccomandate">. <item> Se il bug è reale ma è causato da un altro pacchetto, riassegnalo semplicemente al pacchetto giusto. Se non sai a quale pacchetto dovrebbe essere riassegnato, puoi o chiedere aiuto in &email-debian-devel; o riassegnarlo a <package>debian-policy</package> per fare decidere a loro quale pacchetto sia bacato. A volte puoi avere bisogno di aggiustare la severità del bug in modo che corrisponda alla nostra definizione di severità. Questo perché la gente tende a gonfiare la severità dei bug per assicurarsi che vengano risolti velocemente. Certi bug possono persino venire degradati a `wishlist' quando il cambiamento richiesto è solo cosmetico. <item> Il segnalatore del bug può avere dimenticato di fornire alcune informazioni, in tal caso devi chiedergli le informazioni necessarie. Puoi usare il tag <tt>moreinfo</tt> per marcare il bug di conseguenza. Oltretutto, se non puoi riprodurre il bug, marcalo <tt>unreproducible</tt>. Chiunque sia in grado di riprodurre il bug è quindi invitato a fornire ulteriori informazioni su come fare per riprodurlo. Dopo qualche mese, se nessuno ha mandato informazioni, il bug può essere chiuso. <item> Se il bug è dovuto alla pacchettizzazione, risolvilo semplicemente. Se non sei in grado di risolverlo da solo, marca il bug con <tt>help</tt>. Puoi anche chiedere aiuto su &email-debian-devel; oppure &email-debian-qa;. Se è un problema a livello upstream, devi inoltrarlo all'autore originale. Inoltrare un bug non è abbastanza, devi conrollare a ogni release  se il bug sia stato risolto o meno. In caso affermativo, chiudilo semplicemente, altrimenti devi ricordarne l'esistenza all'autore. Se hai l'abilità necessaria puoi preparare una patch che risolve il bug e spedirla allo stesso tempo all'autore. Assicurati di mandare la patch al BTS e marcare il bug con <tt>patch</tt>. <item> Se hai risolto un bug in locale, o una patch è stata inviata all'archivio CVS, puoi marcare il bug come <tt>pending</tt> per far sapere alla gente che il bug è stato corretto e che verrà chiuso con il prossimo upload (aggiungendo <tt>closes:</tt> nel <file>changelog</file>). Questo è particolarmente utile se ci sono più sviluppatori che lavorano sullo stesso pacchetto. <item> Una volta che un pacchetto corretto è disponibile nella distribuzione unstable, puoi chiudere il bug. Ciò puoò essere fatto automaticamente, vedi <ref id="upload-bugfix">. </enumlist> <sect1 id="upload-bugfix">Quando i bug vengono chiusi da nuovi upload. Intanto che bug e problemi nei tuoi pacchetti vengono risolti, è tua responsabilità come mantainer del pacchetto chiudere il bug. Comunque, non dovresti chiudere il bug finché il pacchetto che lo corregge non sia stato accettato nell'archivio Debian. Di conseguenza, una volta che ricevi la notifica che il tuo pacchetto aggiornato è stato installato nell'archivio, puoi e dovresti chiudere il bug nel BTS. È comunque possibile evitare di dover chiudere manualmente i bug dopo gli upload — elenca semplicemente i bug risolti nel tuo file <file>debian/changelog</file>, rispettando una certa sintassi, e il software di manutenzione dell'archivio chiuderà il bug per te. Per esempio: <example> acme-cannon (3.1415) unstable; urgency=low * Riempito di opzioni (closes: Bug#98339)  * Aggiunta protezione per prevenire la disintegrazione dell'operatore, closes: bug#98765, bug#98713, #98714.  * Aggiunta man page. Closes: #98725.  </example> In termini tecnici, la seguente espressione regolare Perl descrive come sono identificati i changelog che chiudono bug: <example> /closes:\s*(?:bug)?\#\s*\d+(?:,\s*(?:bug)?\#\s*\d+)*/ig </example> Noi preferiamo la sintassi <tt>closes: #<var>XXX</var></tt>, essendo la più concisa e la più facile da integrare con il testo del <file>changelog</file>. Se ti succede di sbagliare a scrivere il numero di un bug o di dimenticare un bug nelle voci del changelog, non esitare ad annullare ogni danno causato dall'errore. Per riaprire bug chiusi per errore, manda un comando <tt>reopen <var>XXX</var></tt> all'indirizzo del controllo del sistema di tracciamento dei bug, &email-bts-control;. Per chiudere i rimanenti bug risolti dal tuo upload, manda il file <file>.changes</file> a <email>XXX-done@&bugs-host;</email>, dove <var>XXX</var> è il numero del tuo bug. Tieni a mente che non è obbligatorio chiudere i bug usando il changelog come descritto sopra. Se vuoi chiudere bug che semplicemente non hanno niente a che fare con gli upload che hai fatto, fallo mandando una email di spiegazione a <email>XXX-done@&bugs-host;</email>. NON chiudere bug nella voce del changelog di una versione se i cambiamenti fatti in quella versione non hanno niente a che fare con il bug. Per informazioni generali su come scrivere le tue voci nel changelog, vedi <ref id="bpp-debian-changelog">. <sect1 id="bug-security">Gestire i bug di sicurezza Per la loro natura sensibile  , i bug di sicurezza devono essere gestiti con molta attenzione. Il Team di sicurezza Debian esiste per coordinare queta attività, tenendo traccia dei problemi di sicurezza esistenti, aiutando i mantainer con problemi di sicurezza o risolvendoli direttamente, mandando advisory di sicurezza e mantenendo  security.debian.org.   Quando vieni a conoscenza dell'esistenza di un bug di sicurezza in un pacchetto Debian, che tu ne sia o meno il mantainer raccogli informazioni pertinenti al problema, e contatta prontamente il team di sicurezza presso &email-security-team; il più presto possibile. Per esempio, sono informazioni utili: <list compact> <item>Quali versioni del pacchetto sono riconosciute essere affette dal bug. Controlla ogni versione presente in una release Debian supportata, così come testing e unstable. <item>La natura del rimedio, se disponibile (le patch sono perticolarmente d'aiuto) <item>Qualunque pacchetto "riparato"  che hai personalmente preparato (manda solo i file <tt>.diff.gz</tt> e <tt>.dsc</tt> e leggi prima <ref id="bug-security-building">) <item>Qualunque assistenza sei in grado di fornire per aiutare il testing (exploit, regression testing, ecc.) <item>Qualunque informazione necessaria per l'advisory (vedi <ref id="bug-security-advisories">) </list> <sect2 id="bug-security-confidentiality">Riservatezza Al contrario della maggior parte delle altre attività in Debian, a volte le informazioni sui problemi di sicurezza devono essere tenute private per un certo tempo. Questo permette ai distributori di software di coordinare il rilascio delle informazioni  in modo da minimizzare l'esposizione dei loro utenti. Questa decisione dipende dalla natura del problema e del rimedio corrispondente, e se sia già di pubblico dominio. Ci sono diversi modi in cui uno sviluppatore può venire a conoscenza di un problema di sicurezza: <list compact> <item>lo nota su un forum pubblico (mailing list, sito web, ecc.) <item>qualcuno manda un bug report <item>qualcuno li informa tramite un'email privata </list> Nei primi due casi, l'informazione è pubblica ed è importante avere un rimedio il più presto possibile. Nell'ultimo caso, comunque, potrebbe non essere un informazione pubblica. In quel caso ci sono poche alternative possibili per gestire il problema: <list> <item>Se l'esposizione di sicurezza è minima, a volte non c'è bisogno di tenere segreto il problema e un rimedio dovrebbe essere creato e rilasciato. <item>Se il problema è grave, è preferibile condividere le informazioni con gli altri produttori e coordinarne il rilascio. Il team di sicurezza mantiene i contatti con le varie organizzazioni e individui e può prendersene cura. </list> In ogni caso, se chi riporta il problema chiede che esso non sia reso pubblico, tale richiesta dovrebbe essere rispettata, con l'ovvia eccezione di informare il team di sicurezza in modo che una fix possa essere prodotta per una release stabile di Debian. Quando si mandano informazioni confidenziali al team di sicurezza, assicurati di menzionare il fatto. Per favore nota che se la segretezza è necessaria non puoi mandare una fix in upload su unstable (o da qualsiasi altra parte, come un archivio CVS pubblico). Non è sufficente offuscare i dettagli delle modifiche, essendo il codice stesso pubblico, e può essere (e sarà) esaminato dal pubblico in generale. Ci sono due ragioni per rilasciare informazioni anche se è richiesto un certo grado di sicurezza: il problema era risaputo da un certo tempo, o il problema o l'exploit è diventato pubblico. <sect2 id="bug-security-advisories">Advisory di sicurezza Le advisory di sicurezza sono rilasciate solo per la corrente, rilasciata distribuzione stabile, e non per testing o unstable. Quando sono rilasciate, le advisory sono inviate alla mailing list &email-debian-security-announce; e postate sulle <url id="&url-debian-security-advisories;" name="pagine web di sicurezza">. Le advisory di sicurezza vengono scritte e postate dal team di sicurezza. Nonostante ciò saranno certamente contenti se un mantainer può fornire qualche informazione per loro, o scrivere parte del testo. Le informazioni che dovrebbero comparire in un advisory includono: <list compact> <item>Una descrizione del problema e della sua portata, includendo: <list> <item>Il tipo del problema (privilege escalation, denial of service, etc.) <item>Quali privilegi possono essere ottenuti, e da chi (se da qualcuno) <item>Come può essere sfruttato <item>Se sia sfruttabile in remoto o in locale <item>Come il problema è stato risolto </list> Questa informazione permette agli utenti di stimare la minaccia ai loro sistemi. <item>Numeri di versione dei pacchetti affetti <item>Numeri di versione dei pacchetti sistemati <item>Informazioni su dove ottenere i pacchetti aggiornati (di solito dall'archivio di sicurezza Debian) <item>Riferimenti alle advisory originali <url id="http://cve.mitre.org" name="CVE">, identificatori, e quant'altro. informazioni utili per stabilire referenze incrociate alla vulnerabilità </list> <sect2 id="bug-security-building"> <heading>Preparare i pacchetti per indirizzare i problemi di sicurezza</heading> Un modo per assistere il team di sicurezza nei loro compiti è di fornirli di pacchetti sistemati adatti per un advisory di sicurezza per il rilascio di Debian stable. Quando viene aggiornata la release stable, bisogna fare attenzione per evitare di cambiare il comportamento del sistema o introdurre nuovi bug. Per fare ciò, fai meno modifiche possibile per sistemare il bug. Gli utenti e gli amministratori si fidano del comportamento esatto di una release una volta che è stata fatta, quindi qualsiasi modifica effettuata potrebbe infrangere il sistema di qualcuno. Ciò è specialmente vero con le librerie: assicurati di non cambiare mai le API o ABI, non importa quanto piccolo sia il cambiamento. Ciò significa che muoversi verso una nuova versione upstream non è una buona soluzione. Invece, i cambiamenti rilevanti dovrebbero essere applicate alla versione presente nella release Debian stabile corrente. Generalmente, i mantainer upstream sono disponibili ad aiutarti in caso di bisogno. Altrimenti, il team di sicurezza Debian può essere in grado di aiutarti. In qualche caso, non è possibile effettuare il back-port di un fix  di sicurezza, per esempio quando una notevole quantità di codice sorgente deve essere modificata o riscritta. Se questo è il caso, potrebbe essere necessario ripiegare su una nuova versione upstream. Comunque, questo succede solo in situazioni estreme, e devi sempre prima coordinarti con il team di sicurezza. Esiste un'altra linea guida importante correlata a questo: prova sempre le tue modifiche. Se hai un exploit disponibile, provalo e guarda se veramente ha successo sul pacchetto vecchio e fallisce su quello sistemato. Prova anche altre, normali azioni, siccome a volte un fix di sicurezza può infrangere altre feature che non hanno apparentemente alcuna relazione in modi molto sottili. NON includere alcuna modifica nel tuo pacchetto che non sia direttamente correlata alla risoluzione della vulnerabilità. Queste avranno solo bisogno di essere ripristinate, causando perdite di tempo. Se ci sono altri bug nel tuo pacchetto che vorresti sistemare, effettua un upload in proposed-updates nel solito modo, dopo il rilascio dell'advisory di sicurezza. Il meccanismo degli aggiornamenti di sicurezza non è un modo per introdurre modifiche nel tuo pacchetto che sarebbero altrimenti rifiutate dalla release stabile, qundi per favore non cercare di farlo. Riesamina e prova le tue modifiche più che puoi. Controlla le differenze con la versione precedente in continuazione (<prgn>interdiff</prgn> dal pacchetto <package>patchutils</package> e <prgn>debdiff</prgn> da <package>devscripts</package> sono strumenti utili per questo, vedi <ref id="debdiff">). Assicurati di verificare le seguenti cose: <list> <item>Assegna al giusta distribuzione nel tuo <file>debian/changelog</file>. Per stable è <tt>stable-security</tt> e per testing è <tt>testing-security</tt>, e per la release stable precedente è <tt>oldstable-security</tt>. Non indicare <var>distribution</var>-proposed-updates o <tt>stable</tt>! <item>Crea delle descrittive e significative voci di changelog. Gli altri si riferiranno su quelle per determinare se un particolare bug è stato risolto. Includi sempre un riferimento esterno, preferabilmente un identificatore CVE, in modo che possa essere referenziato in modo incrociato. Includi le stesse informazioni nel changelog per unstable, in modo che sia chiaro che è stato risolto lo stesso bug, essendo ciò molto di aiuto quando si verifica che il bug è risolto nella prossima release stabile. Se un identificatore CVE non è ancora stato assegnato, il team di sicurezza ne richiederà uno in modo che possa essere incluso nel pacchetto e nell'advisory. <item>Assicurati che il numero di versione sia giusto. Deve essere più alto rispetto al pacchetto corrente, ma più basso rispetto alle versioni dei pacchetti nelle distribuzioni successive. Se sei in dubbio, provalo con <tt>dpkg --compare-versions</tt>. Stai attento a non usare nuovamente un numero di versione che hai già usato per un precedente upload. Per testing, deve esserci una versione più alta in unstable. Se non ne esiste ancora una (per esempio, se sia testing che unstable hanno la stessa versione) devi prima effettuare un upload di una nuova versione in unstable. <item>Non effettuare upload di soli sorgenti se il tuo pacchetto ha qualche pacchetto binary-all (non usare l'opzione <tt>-S</tt> di <prgn>dpkg-buildpackage</prgn>). L'infrastruttura <prgn>buildd</prgn> non ne effettuerà il build. Questo si applica anche agli upload di pacchetti normali. <item>A meno che il sorgente upstream sia stato precedentemente inviato in upload a security.debian.org (da un precedente aggiornamento di sicurezza), costruisci l'upload con tutti i sorgenti upstream (<tt>dpkg-buildpackage -sa</tt>). Se c'è stato un precedente upload a security.debian.org con la stessa versione upstream, puoi inviare l'upload senza il sorgente upstream (<tt>dpkg-buildpackage -sd</tt>). <item>Assicurati di usare esattamente lo stesso <file>*.orig.tar.gz</file> usato nell'archivio normale, altrimenti non sarà in seguito possibile spostare il fix di sicurezza nell'archivio principale. <item>Effettua il build del pacchetto su un sistema pulito che ha pacchetti installati solo dalla distribuzione per cui stai effettuando il build. Se non possiedi un sistema così, puoi usare una macchina debian.org (see <ref id="server-machines">) o impostare un chroot (vedi <ref id="pbuilder"> e <ref id="debootstrap">). </list> <sect2 id="bug-security-upload">Upload del pacchetto sistemato NON effettuare un upload alla coda di upload di sicurezza (oldstable-security, stable-security, ecc.) senza avere precedentemente ottenuto l'autorizzazione dal team di sicurezza. Se il pacchetto non soddisfa pienamente le richieste del team, porterà numerosi problemi e ritardi durante la gestione dell'upload non voluto. NON inviare i tuoi fix a proposed-updates senza ccordinarti con il team di sicurezza. I pacchetti da security.debian.org saranno automaticamente copiati nella directory proposed-updates. Se un pacchetto con lo stesso o più alto numero di versione è già installato all'interno dell'archivio, l'aggiornamento di sicurezza sarà rifiutato dal sistema dell'archivio. In quel modo, invece, la distribuzione stable finirà senza un aggiornamento di sicurezza per questo pacchetto. Una volta che hai creato e controllato il nuovo pacchetto ed è stato approvato dal team di sicurezza, deve essere inviato in upload in modo che possa essere installato negli archivi. Per gli aggiornamenti di sicurezza, il posto in cui inviare l'upload è <tt>ftp://security.debian.org/pub/SecurityUploadQueue/</tt> . Una volta che un upload alla coda di sicurezza è stato accettato, il pacchetto sarà automaticamente ricostruito per tutte le architetture e messo da parte per la verifica dal team di sicurezza. Gli upload in attesa di essere accettati o verificati sono accessibili solo dal team di sicurezza. Questo è necessario siccome ci possono essere dei fix per problemi di sicurezza che non possono ancora essere divulgati. Se un membro del team di sicurezza accetta un pacchetto, questo sarà installato su security.debian.org così come nella giusta <var>distribution</var>-proposed-updates su ftp-master o nell'archivio non-US. <sect id="archive-manip"> <heading>Spostare, rimuovere, rinominare, adottare e abbandonare pacchetti</heading> Alcune operazioni di manipolazione dell'archivio non sono automatizzate nel processo di upload Debian. Queste procedure dovrebbero essere seguite manualmente dai mantainers. Questo capitolo fornisce delle linee guida su cosa fare in questi casi. <sect1 id="moving-pkgs">Spostare pacchetti A volte un pacchetto cambia la propria sezione. Per esempio, un pacchetto dalla sezione `non-free' potrebbe cambiare la propria licenza in GPL in una successiva versione, in qual caso il pacchetto dovrebbe essere spostato in `main' oppure `contrib'. <footnote> Vedi la <url id="&url-debian-policy;" name="Policy Debian"> per le linee guida su a quale sezione appartiene un pacchetto.</footnote> Se devi cambiare la sezione di uno dei tuoi pacchetti, cambia le informazioni di controllo del pacchetto per posizionarlo sella sezione desiderata, e invialo nuovamente in upload (vedi la <url id="&url-debian-policy;" name="Policy Debian"> per i dettagli). Se la tua nuova sezione è valida, sarà spostato automaticamente. Se ciò non accade, contatta gli ftpmasters per comprendere cosa è successo. Se, d'altro canto, devi cambiare la subsection di uno dei tuoi pacchetti (p.es. ``devel'', ``admin''),la procedura è leggermente diversa. Correggi la sottosezione come appare nel file di controllo del pacchetto, e invialo nuovamente in upload. In aggiunta, avrai bisogno di far sì che il file override venga aggiornato, come descritto in <ref id="override-file">. <sect1 id="removing-pkgs">Rimuovere pacchetti Se per qualche ragione vuoi completamente rimuovere un pacchetto (per dire, se è una vecchia libreria di compatibilità che non è più necessaria), devi mandare un bug contro <tt>ftp.debian.org</tt> chiedendo che il pacchetto venga rimosso. Assicurati di indicare da quale distribuzione debba venire rimosso il pacchetto. Normalmente, puoi rimuovere pacchetti solo da unstable ed experimental. I pacchetti non vengono rimossi da testing direttamente. Piuttosto, verranno automaticamente rimossi dopo che il pacchetto sia stato rimosso da unstable e nessun pacchetto dipenda da esso. Devi anche giustificare la richiesta spiegandone in dettaglio i dettagli. Ciò per evitare rimozioni indesiderate e tenere traccia del perchè un pacchetto è stato rimosso. Per esempio, puoi fornire il nome del pacchetto che sostituisce quello da rimuovere. Di solito puoi chiedere la rimozione solo di un pacchetto mantenuto da te stesso. Se vuoi rimuovere un altro pacchetto, devi ottenere l'autorizzazione del suo mantainer. Se sei in dubbio sul fatto che un pacchetto sia disponibile o meno, manda un email a &email-debian-devel; chiedendo altre opinioni. È inoltre interessante il programma <prgn>apt-cache</prgn> del pacchetto <package>apt</package>. Quando viene lanciato come <tt>apt-cache showpkg <var>package</var></tt>, il programma mostrerà i dettagli di <var>package</var>, incluse le dipendenze inverse. La rimozione dei pacchetti abbandonati è discussa su &email-debian-qa;. Una volta che il pacchetto è stato rimosso, bisognerebbe gestirne i bug. Dovrebbero o essere riassegnati a un altro pacchetto nel caso in cui il codice reale si sia evoluto in un altro pacchetto (p.es. <tt>libfoo12</tt> è stato rimosso perchè <tt>libfoo13</tt> lo sostituisce) oppure chiusi se semplicemente il software non fa più parte di Debian. <sect2>Rimuovere pacchetti da <file>Incoming</file> In passato, era possibile rimuovere pacchetti da <file>incoming</file>. Comunque, con l'introduzione del nuovo sistema di incoming, ciò non è più possibile. Piuttosto, devi inviare in upload una nuova revisione del tuo pacchetto con una versione superiore a quella del pacchetto che hai intenzione di sostituire. Entrambe le versioni verranno installate all'interno dell'archivio ma solo la versione più alta sarà realmente disponibile in unstable, siccome la versione precedente sarà immediatamente sostituita dalla più alta. Comunque, se controlli correttamente i tuoi pacchetti, il bisogno di sostituire un pacchetto non dovrebbe succedere troppo spesso. <sect1>Rimpiazzare o rinominare pacchetti Quando sbagli a dare il nome al tuo pacchetto, dovresti seguire un processo composto da due fasi per rinominarlo. Prima di tutto, imposta il tuo file <file>debian/control</file> per sostituire ed essere in conflitto  con il nome obsoleto del pacchetto (vedi la <url id="&url-debian-policy;" name="Policy Debian"> per i dettagli). Una volta che hai effettuato l'upload del pacchetto e che il pacchetto stesso è stato spostato nell'archivio, invia un bug contro <tt>ftp.debian.org</tt> chiedendo di rimuovere il pacchetto con il nome vecchio. Allo stesso tempo non dimenticare di riassegnare propriamente i bug del pacchetto. Altre volte, puoi commettere uno sbaglio mentre costruisci il tuo pacchetto e volerlo sostituire. Il solo modo di farlo è di aumentare il numero di versione è inviare in upload una nuova versione. La vecchia versione scadrà nel solito modo. Nota che questo si applica in ogni parte del tuo pacchetto, sorgenti compresi: se vuoi rimpiazzare la tarball dei sorgenti upstream del tuo pacchetto, dovrai inviarlo in upload con una versione differente. Una semplice possibilità è di sostituire <file>foo_1.00.orig.tar.gz</file> con <file>foo_1.00+0.orig.tar.gz</file>. Questa restrizione dà a ogni file sul sito ftp un nome unico, cosa che aiuta ad assicurare consistenza attraverso la rete dei mirror. <sect1 id="orphaning">Abbandonare un pacchetto Se non sei più in grado di mantenere un pacchetto, devi informare gli altri di questo, e vedere che il pacchetto sia marcato come orphaned.  Dovresti impostare il mantainer del pacchetto a <tt>Debian QA Group &orphan-address;</tt> e inviare un bug report contro il pseudo-pacchetto <package>wnpp</package>. Il bug report dovrebbe essere intitolato <tt>O: <var>package</var> -- <var>short description</var></tt> indicando che il pacchetto è ora abbandonato. La severità del bug dovrebbe essere impostata a normal. Se pensi che sia necessario, mandane una copia a &email-debian-devel; mattendo l'indirizzo nell'header X-Debbugs-CC: del messaggio (no, non usare CC:, in quel modo l'oggetto del messaggio non indicherà il numero del bug). Se il pacchetto è specialmente cruciale per Debian, dovresti invece mandare un bug contro <package>wnpp</package> e intitolarlo: <tt>RFA: <var>package</var> -- <var>short description</var></tt> e impostarne la severità a important. <tt>RFA</tt> sta per Request For Adoption (richiesta di adozione). In questo caso mandane certamente una copia a debian-devel, come descritto poc'anzi. Leggi le istruzioni sulle <url id="&url-wnpp;" name="pagine web WNPP"> per ulteriori informazioni. <sect1 id="adopting">Adottare un pacchetto Una lista dei pacchetti che necessitano un nuovo mantainer è disponibile nella <url name="lista dei pacchetti futuri e in bisogno di lavoro (WNPP)" id="&url-wnpp;">.  Se vuoi prenderti in carica la manutenzione di qualsiasi pacchetto elencato nella WNPP, per favore guarda la succitata pagina per informazioni e conoscere le procedure da seguire. Non è corretto semplicemente rilevare un pacchetto che pensi sia trascurato — questo sarebbe un hijacking di pacchetti. Puoi certamente contattare il mantainer corrente e chiedergli se puoi prendere il pacchetto sotto la tua custodia. Se hai delle ragioni per credere che un mantainer è andato "AWOL" (absent without leave) , vedi <ref id="mia-qa">. Generalmente, non puoi prendere il possesso del pacchetto senza il consenso del mantainer corrente. Anche se ti ignorano, non ci sono lo stesso le basi per rilevare un pacchetto. Le lamentele sui mantainer dovrebbero essere fatte sulla mailing list degli sviluppatori. Se la discussione non si conclude in modo positivo, e il problema è di natura tecnica, considera la possibilità di portarlo all'attenzione del comitato tecnico (vedi la <url name="pagina web del comitato tecnico" id="&url-tech-ctte;"> per ulteriori informazioni). Se rilevi un vecchio pacchetto, probabilmente vuoi essere elencato come il mantainer ufficiale del pacchetto nel sistema dei bug. Questo avverrà automaticamente una volta che effettui un upload di una nuova versione con il campo <tt>Maintainer:</tt> aggiornato, anche se ci vorrà qualche ora dopo che l'upload è stato fatto. Se non ti aspetti di effettuare alcun upload di una nuova versione per un po' di tempo, puoi usare <ref id="pkg-tracking-system"> per ottenere i bug report. Assicurati comunque che il vecchio mantainer non abbia dei problemi a continuare a ricevere i bug durante quel periodo. <sect id="porting">Porting  Debian supporta sempre più architetture. Anche se non sei un porter, e usi una sola architettura, fa parte dei tuoi doveri di mantainer essere conscio dei problemi relativi alla portabilità. Quindi, anche se non sei un porter, dovresti comunque leggere buona parte di questo paragrafo. Il porting è l'atto di costruire pacchetti Debian per architetture diverse da quella originaria del mantainer del pacchetto binario. È un'attività unica ed essenziale. Infatti, i porter effetuano la maggior parte della compilazione reale di pacchetti Debian. Per esempio, per ogni singolo pacchetto binario per i386, deve esserci una ricompilazione per ogni architettura, il che significa &number-of-arches; ulteriori build. <sect1 id="kind-to-porters">Essere cortesi con i porter I porters hanno un compito difficile e unico, dovendo avere a che fare con un grande numero di pacchetti. Idealmente, ogni pacchetto sorgente dovrebbe riuscire nel build al primo colpo. Sfortunatamente ciò spesso non accade. Questa sezione contiene una lista di errori <-- FIXME: era gotchas --> commessi di frequente dai mantainer Debian — problemi comuni che spesso pesano sui porter e rendono il loro lavoro inutilmente difficile. La prima e più importarte cosa è rispondere velocemente ai bug o problemi sollevati dai porter. Per favore sii cortese con i porter, come se fossero co-mantainer del tuo pacchetto (e in un certo senso lo sono). Per favore sii tollerante con bug report succinti o persino non chiari, fa del tuo meglio per ricercare cosa sia il problema. Ad oggi, la maggior parte dei problemi incontrati dai porter sono causati da bug di pacchettizzazione nei pacchetti sorgenti. Ecco una lista di cose che dovresti controllare o esserne a conoscenza. <enumlist> <item> Assicurati che i settaggi <tt>Build-Depends</tt> e <tt>Build-Depends-Indep</tt> nel tuo <file>debian/control</file> siano correttamente impostati. Il miglior modo per assicurarsene è quello di usare il pacchetto <package>debootstrap</package> per creare un ambiente chroot unstable (vedi <ref id="debootstrap">). All'interno di quell'ambiente chroot, installa il pacchetto <package>build-essential</package> e tutte le dipendenze menzionate nei campi <tt>Build-Depends</tt> e/o <tt>Build-Depends-Indep</tt>. Dopodichè prova a fare il build del tuo pacchetto all'interno di quell'ambiente chroot. Questo procedimento può essere automatizzato tramite l'uso del programma <prgn>pbuilder</prgn> il quale è fornito dal pacchetto omonimo (vedi <ref id="pbuilder">). Se non puoi impostare un chroot corretto, <prgn>dpkg-depcheck</prgn> può aiutarti (vedi <ref id="dpkg-depcheck">). Vedi la <url id="&url-debian-policy;" name="Policy Debian"> per istruzioni su come impostare le dipendenze di build. <item> Non impostare ``architecture'' a un valore diverso da ``all'' o ``any'' a meno che tu non sappia cosa stai facendo. In troppi casi i mantainer non seguono le istruzioni della <url id="&url-debian-policy;" name="Policy Debian">. Impostare la tua architettura a ``i386'' è generalmente sbagliato. <item> Assicurati che il tuo pacchetto sorgente sia corretto. Lancia <tt>dpkg-source -x <var>package</var>.dsc</tt> per essere sicuro che il tuo pacchetto sorgente si decomprima correttamente. Dopodichè, da lì, prova a effettuare il build del tuo pacchetto da zero con <prgn>dpkg-buildpackage</prgn>. <item> Assicurati di non inserire nel pacchetto sorgente i file <file>debian/files</file> o <file>debian/substvars</file>. Questi file dovrebbero essere rimossi dal target `clean' di <file>debian/rules</file>. <item> Assicurati di non fare affidamento su programmi installati in locale o su particolari configurazioni. Per esempio, non dovresti mai chiamare programmi in <file>/usr/local/bin</file> o simili. Prova a non fare affidamento a programmi impostati in modo speciale. Prova a fare il build del tuo pacchetto su un altra macchina, anche se della stessa architettura. <item> Non dipendere dal fatto che il pacchetto che stai costruendo sia già installato (un sotto-caso del problema sopra descritto). <item> Non dipendere se possibile dal fatto che il compilatore sia di una certa versione. Se non è possibile, assicurati che le tue dipendenze di build rifletta la restrizione, anche se stai probabilmente cercando dei guai, siccome a volte architetture diverse hanno dei compilatori standard diversi. <item> Assicurati che il tuo debian/rules contenga separatamente i target ``binary-arch'' e ``binary-indep'', come richiede la Policy Debian. Assicurati che i due target lavorino in modo indipendente tra di loro, il che significa che si possa invocarne uno senza prima aver invocato l'altro. Per provarlo, prova a lanciare <tt>dpkg-buildpackage -B</tt>. </enumlist> <sect1 id="porter-guidelines">Linee guida per gli upload dei porter Se il pacchetto effettua il build senza problemi sull'architettura su cui si deve fare il porting, sei fortunato e il tuo lavoro sarà facile. Questa sezione si applica per questi casi; descrive come fare il build e l'upload del tuo pacchetto binario in modo che sia propriamente installato nell'archivio. Se devi apportare delle correzioni al pacchetto per fare in modo che possa essere compilato per l'altra architettura, stai in realtà effettuando un NMU, qundi devi invece consultare <ref id="nmu-guidelines">. Per un upload del porter, non si apporta alcuna modifica al sorgente. Non hai bisogno di toccare nessuno dei file nel pacchetto sorgente. Ciò include anche <file>debian/changelog</file>. Il modo invocare <prgn>dpkg-buildpackage</prgn> è <tt>dpkg-buildpackage -B -m<var>porter-email</var></tt>. Ovviamente imposta <var>porter-email</var> con il tuo indirizzo email. Questo effettuerà il build binario solo per le parti del pacchetto dipendenti dall'architettura, usando il target `binary-arch' in <file>debian/rules</file>. <sect2 id="binary-only-nmu"> <heading>Ricompilazione di NMU esclusivamente binari</heading> A volte l'upload iniziale del porter è problematico in quanto l'ambiente in cui è stato costruito il pacchetto non è abbastanza buono (librerie vecchie o obsolete, cattivo compilatore, ...). In tal caso potresti semplicemente doverlo ricompilare in un ambiente aggiornato. In questo caso, devi incrementare il numero di versione, in modo che il vecchio pacchetto non funzionante possa essere rimpiazzato nell'archivio Debian (<prgn>katie</prgn> si rifiuta di installare nuovi pacchetti se non hanno un numero di versione maggiore rispetto a quello correntemente disponibile). Nonostante le modifiche richieste al changelog, queste sono chiamate NMU solo binari — in questo caso non c'è bisogno di fare scattare tutte le altre architetture per considerarsi superate o richiederne la ricompilazione. Tali ricompilazioni richiedono una speciale ``magica'' numerazione di versione, in modo che gli strumenti di manutenzione dell'archivio riconoscano che, sebbene ci sia una nuova versione Debian, non esiste un corrispondente aggiornamento dei sorgenti. Se sbagli, i mantainer dell'archivio respingeranno il tuo upload (dovuto alla mancanza del corrispondente codice sorgente). La ``magia'' per un NMU solo di ricompilazione viene fatta scattare usando il numero di terzo livello sulla parte Debian del numero di versione. Per esempio, se stai ricompilando la versione ``2.9-3'', il tuo NMU dovrebbe avere versione ``2.9-3.0.1''. Se l'ultima versione era``3.4-2.1'', il tuo NMU dovrebbe avere il numero di versione``3.4-2.1.1''. <sect2 id="source-nmu-when-porter"> <heading>Quando fare un NMU di sorgenti se sei un porter</heading> I porter che effettuano un NMU di sorgenti seguono generalmente le linee guida trovate in <ref id="nmu">, esattamente come gli altri. Comunque, ci si aspetta che il ciclo di attesa per un NMU sorgente di un porter sia minore rispetto per uno normale, siccome i porter devono far fronte a una grande quantità di pacchetti. Di nuovo, la situazione cambia dipendentemente dalla distribuzione su cui si vuole effettuare l'upload.  Comunque, se sei un porter e stai facendo un NMU per `unstable', dovresti seguire le linee guida sopra descritte, con due variazioni. Primo, il tempo di attesa accettabile — il tempo tra quando il bug è inviato al BTS e quando va bene fare un NMU — è di sette giorni per i porter che lavorano sulla distribuzione unstable. Questo periodo può essere accorciato se il problema è critico e ostacola l'attività di porting, a discrezione del gruppo dei porter. (Ricorda, niente di tutto ciò è Policy, ma solo accordi sulle linee guida.) Secondo, i porter che effettuano NMU di sorgenti dovrebbero assicurarsi che il bug che inviano al BTS dovrebbe essere di severità `serious' o maggiore. Ciò assicura che un singolo pacchetto sorgente possa essere compilato su tutte le architetture supportate da Debian al tempo del rilascio. È molto importante il fatto di avere una versione del pacchetto binario e sorgente per tutte le architetture in modo da soddisfare i requisiti di molte licenze. I porter dovrebbero provare a evitare patch che girano semplicemente attorno a bug nella versione corrente dell'ambiente di compilazione, del kernel, o delle libc. A volte questi kludge non si possono evitare. Se devi girare attorno a bug del compilatore e cose simili, assicurati di definire propriamente il tuo lavoro con <tt>#ifdef</tt>; inoltre, documenta i kludge che fai in modo che la gente possa sapere come rimuoverli una volta che il problema esterno è stato risolto. I porter possono anche avere un posto non ufficiale dove riporre i risultati del proprio lavoro durante il periodo di attesa. Ciò aiuta gli altri che usano il port a trarne beneficio anche durante il periodo di attesa. Ovviamente tali locazioni non hanno nessuna 'benedizione' ne riscontro ufficiale, quindi i clienti sono avvisati. <sect1 id="porter-automation"> <heading>Infrastrutture e automazione nel porting</heading> Esiste un'infrastruttura e diversi strumenti per aiutare ad automatizzare il porting dei pacchetti. Questa sezione contiene una breve vista d'insieme di questa automazione e di questi strumenti; leggi la documentazione del pacchetto o altri riferimenti per le informazioni complete. <sect2> <heading>Mailing list e pagine web</heading> Le pagine web contenenti lo stato di ogni port si trovano all'indirizzo <url id="&url-debian-ports;">. Ogni port di Debian ha la propria mailing list. La lista delle mailing list dei porting si trova all'indirizzo <url id="&url-debian-port-lists;">. Queste liste sono usate per coordinare i porter e per mettere in contatto gli utenti di un dato port con i porter. </sect2> <sect2> <heading>Strumenti dei porter</heading> Le descrizioni dei diversi strumenti per il porting si trovano in <ref id="tools-porting">. </sect2> <sect2 id="buildd"> <heading><package>buildd</package></heading> Il sistema <package>buildd</package> è usato come un sistema distribuito client-server di build delle distribuzioni. Di solito è usato insieme a auto-builders, che sono host ``slave'' che semplicemente controllano e cercano di fare il build automatico dei pacchetti dei quali si deve effettuare il porting. Esiste anche un'interfaccia email al sistema, che permette ai porter di controllare un pacchetto sorgente (di solito uno di cui non si puo' ancora fare il build automaticamente) e lavorarci sopra. <package>buildd</package> non è ancora disponibile come pacchetto; comunque, la maggior parte dei porter o lo stanno correntemente usando o pianificando di usarlo in un futuro non lontano. Il builder reale è pacchettizzato come <package>sbuild</package>, vedi la sua descrizione in <ref id="sbuild">. Il sistema <package>buildd</package> completo include anche un certo numero di componenti ancora da pacchettizzare molto utili che vengono usati continuamente, come <prgn>andrea</prgn> e <prgn>wanna-build</prgn>. Una parte delle informazioni prodotte da <package>buildd</package> che sono generalmente utili ai porter sono disponibili sul web all'indirizzo <url id="&url-buildd;">. Queste informazioni includono le informazioni aggiornate giornalmente  da <prgn>andrea</prgn> (dipendenze dei sorgenti) e <package>quinn-diff</package> (pacchetti che necessitano una ricompilazione). Siamo abbastanza fieri di questo sistema, siccome ha tanti usi possibili. Gruppi di sviluppatori indipendenti possono usare il sistema per diverse varianti secondarie di Debian, che possono essere o meno di interesse generale (per esempio, una versione di Debian costruita con il bound-checking di <prgn>gcc</prgn>). Renderà inoltre Debian in grado di ricompilare velocemente intere distribuzioni. </sect2> <sect id="nmu">Non-Maintainer Upload (NMU) In certe circostanze è necessario per qualcuno che non sia il mantainer ufficiale del pacchetto effettuarne una release. Questo è chiamato un non-maintainer upload, in breve NMU. I porter Debian, i quali compilano i pacchetti per differenti architetture, effettuano occasionalmente dei NMU solo binari come parte della loro attività di porter (vedi <ref id="porting">). Un altra ragione per cui vengono fatti dei NMU è quando uno sviluppatore Debian necessita di correggere pacchetti di altri sviluppatori in modo da indirizzare seri problemi di sicurezza o bug paralizzanti, specialmente durante il periodo di freeze, o quando il mantainer del pacchetto non è in grado di risolvere il problema in tempi ragionevoli. Questo capitolo contiene informazioni che forniscono le linee guida su quando e come dovrebbero essere fatti i NMU. Una distinzione fondamentale è fatta tra NMU di sorgenti e solo binari, spiegata nella prossima sezione. <sect1 id="nmu-terms">Terminologia Ci sono due nuovi termini usati all'interno di questa sezioni: ``NMU solo binari'' e ``NMU di sorgenti''. Questi termini vengono usati con dei significati tecnici specifici in tutto questo documento. NMU di sorgenti e solo binari sono simili tra loro, siccome implicano entrambi un upload di un pacchetto da uno sviluppatore che non è il mantainer ufficiale del pacchetto. Ecco perchè è un non-maintainer upload. Un NMU di sorgenti è un upload di un pacchetto fatto da uno sviluppatore che non è il mantainer ufficiale del pacchetto, fatto per risolvere un baco del pacchetto. Gli NMU di sorgenti implicano sempre delle modifiche al sorgente (anche se è solo una modifica al <file>debian/changelog</file>). Cio può essere sia una modifica al sorgente upstream o una modifica alla parte Debian del sorgente. Nota, comunque, che NMU di sorgenti possono anche includere pacchetti dipendenti dall'architettura, così come una diff Debian aggiornata. Un NMU solo binario è una ricompilazione e upload di un pacchetto binario per una certa architettura. Di solito è parte di un lavoro di porting. Un NMU solo binario è un upload, non effettuato dal suo mantainer, della versione binaria del pacchetto, senza che siano richieste modifiche ai sorgenti. Ci sono diversi casi in cui i porter devono risolvere dei problemi nei sorgenti per farli compilare nella loro architettura; questo sarebbe considerato un NMU di sorgenti piuttosto che un NMU solo binario. Come puoi vedere, non facciamo alcuna distinzione nella terminologia tra NMU di porter e NMU non di porter. Entrambe le classi di NMU, di sorgenti e solo binari, possono essere riferite con il termine generico ``NMU''. Ciò nonostante, questo causa spesso confusione, in quanto per molta gente ``NMU'' significa ``NMU di sorgenti'', quindi è meglio fare attenzione. In questo capitolo, se usiamo il termine generico ``NMU'' ci riferiamo a qualunque tipo di non-mantainer upload, che sia di entrambi (sorgenti e binari) o solo di binari. <sect1 id="nmu-who">Chi può fare un NMU Solo i mantainer Debian ufficiali e registrati possono fare NMU binari o di sorgenti, Un mantainer ufficiale è qualcuno che ha la sua chiave nel keyring Debian. I non sviluppatori, comunque, sono incoraggiati a scaricare il pacchetto sorgente e iniziare a lavorarci su per risolvere i problemi; comunque, piutosto che fare un NMU, dovrebbero semplicemente inviare patch al sistema di tracciamento dei bug. I mantainer quasi sempre apprezzano le patch di qualità e i bug report. <sect1 id="nmu-when">Quando fare un NMU di sorgenti Le linee guida su quando fare un NMU di sorgenti dipendono dalla distribuzione bersaglio, ovvero stable, unstable o experimental. I porter hanno delle regole leggermente differenti rispetto ai non-porter, a causa delle loro circostanze uniche (vedi <ref id="source-nmu-when-porter">). Quando viene trovato un bug di sicurezza, il team di sicurezza può effettuare un NMU. Per favore vedi <ref id="bug-security"> per ulteriori informazioni. Durante il ciclo di rilascio (vedi <ref id="sec-dists">), gli NMU che sistemano bug di sicurezza di severità uguale o maggiore a serious sono incoraggiati e accettati. Anche in questo caso dovresti comunque adoperarti per contattare il mantainer del pacchetto; potrebbe stare giusto per inviare in upload un fix per il problema. Come per qualunque NMU di sorgenti, devono essere seguite le linee guida in <ref id="nmu-guidelines">. Si fanno eccezioni speciali per <ref id="qa-bsp">. Upload di fix per bug in unstable dovrebbero essere fatti solo rispettando questo protocollo: <list> <item> Assicurati che i bug a cui è indirizzato a risolvere il NMU sono tutti schedati nel sistema di tracciamento dei bug (BTS). Se non lo sono, inviali immediatamente. <item> Aspetta qualche giorno la risposta dal mantainer. Se non ricevi alcuna risposta, puoi se vuoi aiutarli inviando la patch che sistema il bug. Non dimenticare di marcare il bug con la parola chiave "patch". <item> Aspetta ancora qualche giorno. Se ancora non ricevi risposta dal mantainer, scrivigli una email annunciando la tua intenzione di fare un NMU sul pacchetto. Prepara un NMU come descritto in <ref id="nmu-guidelines">, controllalo attentamente sulla tua macchina (vedi <ref id="sanitycheck">). Controlla doppiamente che la tua patch non abbia alcun inaspettato effetto collaterale. Assicurati che la tua patch sia più piccola e non distruttiva possibile. <item> Invia il pacchetto in upload a incoming in <file>DELAYED/7-day</file> (vedi <ref id="delayed-incoming">), manda la patch definitiva al mantainer via BTS e spiegagli che hanno 7 giorni per reagire se vogliono cancellare l'NMU. <item> Segui quello che accade, sei responsabile per qualsiasi bug tu abbia introdotto con il tuo NMU. Probabilmente dovresti usare <ref id="pkg-tracking-system"> (PTS) per essere informato dello stato del pacchetto dopo il tuo NMU. </list> A volte, il release manager di un gruppo organizzato di sviluppatori può annunciare un certo periodo di tempo in cui le regole sugli NMU vengono rese meno severe. Questo di solito implica l'accorciamento del periodo di attesa che precede l'invio dei fix e del periodo DELAYED. È importante notare che anche durante i cosiddetti "bug squashing party", colui che esegue l'NMU deve prima inviare i bug e contattare lo sviluppatore e poi agire. <sect1 id="nmu-guidelines">Come fare un NMU di sorgenti Ciò che segue si applica ai porter finchè giocano il doppio ruolo di bug-fixer e porter di pacchetti. Se un porter deve modificare l'archivio dei sorgenti Debian, il suo upload è automaticamente un NMU di sorgenti ed è soggetto alle sue regole. Se un porter sta solo inviando in upload un pacchetto binario ricompilato, le regole sono differenti; vedi <ref id="porter-guidelines">. Prima di tutto è essenziale che le patch NMU dovrebbero essere meno distruttive possibile per i sorgenti. Non fare dell'housekeeping di task , non cambiare il nome di moduli o di file, non spostare directory; in generale, non aggiustare niente che non sia rotto. Rendi la patch più piccola possibile. Se ci sono cose che esteticamente non ti piacciono, parlane al mantainer Debian, parlane al mantainer upstream, o riporta un bug. In ogni caso, modifiche estetiche non devono essere fatte in un non-maintainer upload. <sect2 id="nmu-version">Numerazione versioni NMU di sorgenti Ogni volta che fai delle modifiche ad un pacchetto, anche banali, devi cambiare il numero di versione. Questo permette al nostro sistema di funzionare. Se stai facendo un non-maintainer upload (NMU), dovresti aggiungere un nuovo numero di versione minore alla parte <var>debian-revision</var> del numero di versione (la parte dopo l'ultimo trattino). Questo numero extra minore comincerà da `1'. Per esempio, considera il pacchetto `foo', che è alla versione 1.1-3. Nell'archivio, il file di controllo del sorgente del pacchetto sarebbe <file>foo_1.1-3.dsc</file>. La versione upstream è `1.1' e la revisione Debian è `3'. Il successivo NMU aggiungerebbe un nuovo numero minore `.1' alla revisione Debian; il nuovo file di controllo del sorgente sarebbe <file>foo_1.1-3.1.dsc</file>. Il numero minore della revisione Debian serve per evitare di rubare uno dei numeri di versione dei mantainer del pacchetto, che potrebbe distruggere il loro lavoro. Ha anche il vantaggio di rendere visibilmente chiaro che un pacchetto nell'archivio non è stato fatto dal mantainer ufficiale. Se non c'è nessuna componente <var>debian-revision</var> nel numero di versione ne dovrebbe essere creata una, cominciando da `0.1'. Se è assolutamente necessario per qualcuno che non sia il solito mantainer rilasciare una release basata su una nuova versione upstream, questa persona dovrebbe cominciare con il valore <var>debian-revision</var> a `0.1'. Il mantainer ufficiale di un pacchetto dovrebbe cominciare la sua numerazione <var>debian-revision</var> con `1'. <sect2 id="nmu-changelog"> <heading>Gli NMU di sorgenti devono avere una nuova voce di changelog</heading> Un non-mantainer che fa un NMU di sorgenti deve creare una voce di changelog, descrivendo quali bug sono sistemati dal NMU, e generalmente perchè era richiesto un NMU e cosa ha risolto. La voce di changelog avrà l'indirizzo email del non-mantainer nella voce di log e il numero della versione del NMU in essa. Per consuetudine, le voci di changelog degli NMU di sorgenti cominciano con la linea <example> * Non-maintainer upload </example> <sect2 id="nmu-patch">NMU di sorgenti e il sistema di tracciamento dei bug I mantainer diversi dal mantainer ufficiale del pacchetto dovrebbero fare meno modifiche possibili al pacchetto, e dovrebbero sempre mandare una patch nel formato "unified context diff" (<tt>diff -u</tt>) spiegando i dettagli delle loro modifiche al sistema di tracciamento dei bug. E se stai semplicemente ricompilando il pacchetto? Se hai solo bisogno di ricompilarlo per una singola architettura puoi fare un NMU solo binario come descritto in <ref id="binary-only-nmu"> il che non richiede l'invio di alcuna patch. Se vuoi che il pacchetto venga ricompilato per tutte le architetture, fai un NMU di sorgenti come al solito e dovrai spedire una patch. Se il NMU (non-mantainer upload) di sorgenti risolve qualche bug esistente, tali bug piuttosto che essere chiusi dovrebbero essere marcati come fixed nel sistema di tracciamento dei bug. Per convenzione, solo il mantainer ufficiale del pacchetto o chi ha originariamente riportato il bug sono autorizzati a chiudere bug. Fortunatamente il sistema dell'archivio Debian riconosce i NMU e quindi marca appropriatamente i bug sistemati dal NMU se chi lo ha inviato ha elencato tutti i bug nel changelog con la sintassi <tt>Closes: bug#<var>nnnnn</var></tt>(vedi <ref id="upload-bugfix"> per ulteriori informazioni su come chiudere bug attraverso il changelog). Marcare i bug fixed assicura che tutti sappiano che il bug è stato risolto in un NMU; comunque il bug è lasciato aperto finche le modifiche fatte nel NMU non siano ufficialmente incorporate nel pacchetto dal suo mantainer ufficiale. Inoltre, dopo aver fatto un NMU, devi aprire un nuovo bug e includere una patch mostrando tutte le modifiche che hai apportato. In alternativa puoi mandare quelle informazioni ai bug esistenti che sono stati sistemati dal tuo NMU. Il mantainer normale o applicherà la patch o impiegherà un metodo alternativo per risolvere il problema. A volte i bug sono sistemati a monte in modo indipendente, che è un altra buona ragione per annullare le modifiche fatte dalla patch NMU. Se il mantainer decide di non applicare la patch NMU ma di rilasciare una nuova versione, egli deve assicurarsi che la nuova versione upstream risolva sul serio ogni problema che è stato sistemato nella release del non-mantainer. In aggiunta, il mantainer normale dovrebbe sempre conservare la voce nel changelog che documenta il non-mantainer upload. <sect2 id="nmu-build">Costruire NMU di sorgenti I NMU di sorgenti dei pacchetti sono costruiti normalmente. Scegli una distribuzione usando le stesse regole trovate in <ref id="distribution">, segui le altre prescrizioni in <ref id="upload">. Assicurati di non cambiare il valore del mantainer nel file <file>debian/control</file>. Il tuo nome come dato nella voce del NMU del file <file>debian/changelog</file> sarà usato per firmare il file changes. <sect1 id="ack-nmu">Riconoscere un NMU Se viene effettuato un NMU su uno dei tuoi pacchetti, devi incorporare le modifiche nella tua copia dei sorgenti. Questo è facile, devi solo applicare la patch che ti è stata spedita. Una volta che l'hai fatto, devi chiudere i bug che sono stati marcati come fixed dal NMU. Puoi chiuderli o manualmente mandando le mail richieste al BTS o aggiungendo le richieste <tt>closes: #nnnn</tt> nella voce del changelog del tuo prossimo upload. In ogni caso, non dovresti essere arrabbiato per il NMU. Un NMU non è un attacco personale nei confronti del mantainer, è una prova che qualcuno tiene abbastanza al pacchetto da volerti aiutare nel tuo lavoro, quindi dovresti esserne grato. Potresti anche volergli chiedere se sarebbero interessati ad aiutarti più frequentemente come co-mantainer o mantainer di riserva (vedi <ref id="collaborative-maint">). <sect id="collaborative-maint"> <heading>Manutenzione collaborativa</heading> "Manutenzione collaborativa" è un termine che descrive la condivisione dei compiti di manutenzione di pacchetti da parte di più persone. Questa collaborazione è quasi sempre una buona idea, siccome porta a una maggiore qualità e velocizza i tempi di sistemazione dei bug. È fortemente raccomandato che i pacchetti con una priorità <tt>Standard</tt> o che fanno parte del sistema base abbiano dei co-mantainer. Generalmente c'è un mantainer principale e uno o più co-mantainer. Il mantainer principale è la persona il cui nome è elencato nel campo <tt>Maintainer</tt> del file <file>debian/control</file>. I co-mantainer sono tutti gli altri. Nella sua forma di base, il processo di aggiungere un nuovo co-mantainer è abbastanza semplice: <list> <item> Dai al co-mantainer accesso ai sorgenti da cui costruisci il pacchetto. Generalmente questo implica l'uso di un sistema di controllo di versione network-capable, come <prgn>CVS</prgn> o <prgn>Subversion</prgn>. </item> <item> Aggiungi il nome e l'indirizzo corretti del maintainer al campo <tt>Uploaders</tt> nella sezione globale del file <file>debian/control</file>. <example> Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org> </example> </item> <item> Usando il PTS (<ref id="pkg-tracking-system">), i co-maintainer dovrebbero iscriversi all'appropriato pacchetto sorgente. </item> </list> La manutenzione collaborativa spesso può essere ulteriormente facilitata con l'uso degli strumenti su Alioth (vedi <ref id="alioth">). </sect> <chapt id="best-pkging-practices"> <heading>Procedimenti di pacchetizzazione consigliati</heading> La qualità di Debian è in gran parte dovuta alla <url id="&url-debian-policy;" name="policy Debian">, che definisce degli espliciti requisiti di base a cui tutti i pacchetti Debian devono conformarsi. C'è anche ormai un passato di esperienze condivise che vanno oltre la policy Debian, un accumulo di anni di esperienza nella pacchettizzazione. Molta gente di grande talento ha creato strumenti grandiosi, strumenti che aiutano te, il mantainer Debian, a creare e mantenere pacchetti eccellenti. Questo capitolo indica alcuni procedimenti consigliati per sviluppatori Debian. Tutti queste raccomandazioni sono da considerarsi tali, non sono requisiti. Questi sono solo consigli soggettivi, avvisi e puntatori collezionati da sviluppatori Debian. Sentiti libero di scegliere ciò che ritieni opportuno. <sect id="bpp-debian-rules"> <heading>Procedimenti consigliati per <file>debian/rules</file></heading> Le seguenti raccomandazioni riguardano il file <file>debian/rules</file>. Considerando che il file <file>debian/rules</file> controlla il processo di build del pacchetto e seleziona i file che debbono andare nel pacchetto (direttamente o indirettamente), è solitamente il file su cui i maintainer passano più tempo. <sect1 id="helper-scripts">Script helper La ragione per cui utilizzare gli script helper in <file>debian/rules</file> è che permettono ai maintainer di usare e condividere una logica comune tra più pacchetti. Si prenda per esempio il problema di installare degli elementi di menu: è necessario mettere il file in <file>/usr/lib/menu</file>, e aggiungere comandi ai maintainer script per registrare e eliminare elementi dal menu. Visto che si tratta di una cosa molto comune che i pacchetti fanno, perchè ogni maintainer dovrebbe riscrivere tutto ciò da solo, a volte con dei bug? Inoltre, supponendo che la directory dei menu cambi, ogni pacchetto dovrebbe essere modificato. Gli script helper si occupano di queste problematiche. Rispettando le convenzioni, gli script helper si prendono cura di tutti i dettagli. I cambiamenti della policy possono essere introdotti negli script helper; in questo modo è suffigiente ricostruire i pacchetti con la nuova version degli helper e nessun altro cambiamento. <ref id="tools"> contiene un paio di diversi helper. Il sistema (a nostro parere) migliore e più comune è <package>debhelper</package>. I precedenti sistemi, come <package>debmake</package>, erano "monolitici": non era possibile scegliere la parte desiderata del sistema ed utilizzarla, si doveva utilizzare il sistema intero per fare tutto. <package>debhelper</package>, invece, è una raccolta di piccoli programmi <prgn>dh_*</prgn>. Per esempio, <prgn>dh_installman</prgn> installa e comprime le pagine di manuale, <prgn>dh_installmenu</prgn> installa i file menu e via dicendo. Offre quindi abbastanza flessibilità da essere in grado di utilizzare i piccoli script helper, quando servono, insieme ad altri comandi in <file>debian/rules</file>. Si può iniziare con <package>debhelper</package> leggendo <manref name="debhelper" section="1">, e seguendo gli esempi forniti con il pacchetto. <prgn>dh_make</prgn>, dal pacchetto <package>dh-make</package> (si veda <ref id="dh-make">), può essere usato per convertire un pacchetto sorgente "vanilla" in uno che fa uso di <package>debhelper</package>. Questa scorciatoia, comunque, non dovrebbe convincerti che non hai bisogno di disturbarti a capire i singoli script <prgn>dh_*</prgn>. Se userai un helper, hai bisogno di impararlo, per comprenderne il comportamento. Alcuni sono convinti che i normali file <file>debian/rules</files> siano meglio, visto che non c'è bisogno di imparare nessun sistema di helper. La scelta dipende completamente da te. Usa il metodo che preferisci. Molti esempi di <file>debian/rules</file> vanilla sono disponibili su <url id="&url-rules-files;">. <sect1 id="multiple-patches"> <heading>Separare le patch in file multipli</heading> Pacchetti grandi e complessi possono avere molti bug su cui lavorare. Correggendo un bug direttamente nei sorgenti, può diventare difficile differenziare le varie patch applicate. Può diventare un bel problema quando è necessario aggiornare il pacchetto ad un nuovo rilascio upstream che integra alcune delle modifiche (ma non tutte). Non è possibile prendere l'insieme totale dei diff (per esempio, da <file>.diff.gz</file>) e trovare in maniera unitaria le patch che risolvono bug chiusi dall'upstream. Sfortunatamente, al momento il sistema di pacchettizzazione non fornisce il supporto per separare le patch in più file. Comunque, ci sono modi per separare le patch: i file che le contengono sono inclusi nel file patch Debian (<file>.diff.gz</file>), solitamente nella directory <file>debian/</file>. L'unica differenza è che non vengono applicate immediatamente da dpkg-source, ma dalla regola <tt>build</tt> di <file>debian/rules</file>. La regola <tt>clean</tt> si occupa di invertire questo comportamento. <prgn>dbs</prgn> è uno degli approcci più comuni a questo problema. Consente di fare tutto quello che è stato spiegato precedentemente e agevola la creazione e l'aggiornamento di vecchie patch. Si veda il pacchetto <package>dbs</package> per ulteriori informazioni e <package>hello-dbs</package> come esempio. Anche <prgn>dpatch</prgn> ha queste caratteristiche, ma è pensato per essere ancora più facile da usare. Si faccia riferimento al pacchetto <package>dpatch</package> come fonte di documentazione ed esempi (in <file>/usr/share/doc/dpatch</file>). <sect1 id="multiple-binary">Pacchetti binari multipli Un singolo pacchetto sorgente costruisce spesso più di un pacchetto binario, sia per fornire più versioni dello stesso software (es., il pacchetto sorgente di <package>vim</package>) o per dividere un grosso pacchetto in pacchetti più piccoli (es., se l'utente può installare solo il sottoinsieme di pacchetti di cui ha bisogno, risparmiando un po' di spazio disco). La seconda situazione può essere trattata facilmente in <file>debian/rules</file>. Semplicemente, è necessario spostare i file appropriati dalla directory di build negli alberi temporanei dei pacchetti. Per farlo si possono usare <prgn>install</prgn> oppure <prgn>dh_install</prgn>, dal pacchetto <package>debhelper</package>. Ci si assicuri di controllare come interagiscono i vari pacchetti, assicurandosi di avere le corrette dipendenze tra pacchetti in <file>debian/control</file>. Il primo caso è un pochino più difficile visto che coinvolge ricompilazioni multiple dello stesso software ma con opzioni di configurazione differenti. Il pacchetto sorgente di <package>vim</vim> è un esempio di come gestire questa situazione usando un file <file>debian/rules</files> scritto a mano.  </sect1> </sect> <sect id="bpp-debian-control"> <heading>Procedimenti consigliati per <file>debian/control</file></heading> I consigli seguenti sono relativi al file <file>debian/control</file>. Sono un supplemento alla <url id="&url-debian-policy;ch-binary.html#s-descriptions" name="Policy on package descriptions">. La descrizione del pacchetto, definita dal campo corrispondente del file <file>control</file>, contiene sia la descrizione breve (synopsis) che quella lunga del pacchetto. <ref id="bpp-desc-basics"> descrive alcune linee guida applicabili ad entrambe. <ref id="bpp-pkg-synopsis"> fornisce consigli specifici alla descrizione breve, mentre <ref id="bpp-pkg-desc"> contiene consigli relativi alla descrizione lunga. <sect1 id="bpp-desc-basics"> <heading>General guidelines for package descriptions</heading> The package description should be written for the average likely user, the average person who will use and benefit from the package. For instance, development packages are for developers, and can be technical in their language. More general-purpose applications, such as editors, should be written for a less technical user. Our review of package descriptions lead us to conclude that most package descriptions are technical, that is, are not written to make sense for non-technical users. Unless your package really is only for technical users, this is a problem. How do you write for non-technical users? Avoid jargon. Avoid referring to other applications or frameworks that the user might not be familiar with — "GNOME" or "KDE" is fine, since users are probably familiar with these terms, but "GTK+" is probably not. Try not to assume any knowledge at all. If you must use technical terms, introduce them. Be objective. Package descriptions are not the place for advocating your package, no matter how much you love it. Remember that the reader may not care about the same things you care about. References to the names of any other software packages, protocol names, standards, or specifications should use their canonical forms, if one exists. For example, use "X Window System", "X11", or "X"; not "X Windows", "X-Windows", or "X Window". Use "GTK+", not "GTK" or "gtk". Use "GNOME", not "Gnome". Use "PostScript", not "Postscript" or "postscript". If you are having problems writing your description, you may wish to send it along to &email-debian-l10n-english; and request feedback. </sect1> <sect1 id="bpp-pkg-synopsis"> <heading>The package synopsis, or short description</heading> The synopsis line (the short description) should be concise. It must not repeat the package's name (this is policy). It's a good idea to think of the synopsis as an appositive clause, not a full sentence. An appositive clause is defined in WordNet as a grammatical relation between a word and a noun phrase that follows, e.g., "Rudolph the red-nosed reindeer". The appositive clause here is "red-nosed reindeer". Since the synopsis is a clause, rather than a full sentence, we recommend that it neither start with a capital nor end with a full stop (period). It should also not begin with an article, either definite ("the") or indefinite ("a" or "an"). It might help to imagine that the synopsis is combined with the package name in the following way: <example><var>package-name</var> is a <var>synopsis</var>.</example> Alternatively, it might make sense to think of it as <example><var>package-name</var> is <var>synopsis</var>.</example> or, if the package name itself is a plural (such as "developers-tools") <example><var>package-name</var> are <var>synopsis</var>.</example> This way of forming a sentence from the package name and synopsis should be considered as a heuristic and not a strict rule. There are some cases where it doesn't make sense to try to form a sentence. </sect1> <sect1 id="bpp-pkg-desc"> <heading>The long description</heading> The long description is the primary information available to the user about a package before they install it. It should provide all the information needed to let the user decide whether to install the package. Assume that the user has already read the package synopsis. The long description should consist of full and complete sentences. The first paragraph of the long description should answer the following questions: what does the package do? what task does it help the user accomplish? It is important to describe this in a non-technical way, unless of course the audience for the package is necessarily technical. The following paragraphs should answer the following questions: Why do I as a user need this package? What other features does the package have? What outstanding features and deficiencies are there compared to other packages (e.g., "if you need X, use Y instead")? Is this package related to other packages in some way that is not handled by the package manager (e.g., "this is the client to the foo server")? Be careful to avoid spelling and grammar mistakes. Ensure that you spell-check it. <prgn>ispell</prgn> has a special <tt>-g</tt> option for <file>debian/control</file> files: <example>ispell -d american -g debian/control</example> </sect1> <sect1 id="bpp-upstream-info"> <heading>Upstream home page</heading> We recommend that you add the URL for the package's home page to the package description in <file>debian/control</file>. This information should be added at the end of description, using the following format: <example> . Homepage: http://some-project.some-place.org/</example> Note the spaces prepending the line, which serves to break the lines correctly. To see an example of how this displays, see <url id="&url-eg-desc-upstream-info;">. If there is no home page for the software, this should naturally be left out. Note that we expect this field will eventually be replaced by a proper <file>debian/control</file> field understood by <prgn>dpkg</prgn> and <tt>&packages-host;</tt>. If you don't want to bother migrating the home page from the description to this field, you should probably wait until that is available. </sect1> </sect> <sect id="bpp-debian-changelog"> <heading>Best practices for <file>debian/changelog</file></heading> The following practices supplement the <url name="Policy on changelog files" id="&url-debian-policy;ch-docs.html#s-changelogs">. <sect1 id="bpp-changelog-do"> <heading>Writing useful changelog entries</heading> The changelog entry for a package revision documents changes in that revision, and only them. Concentrate on describing significant and user-visible changes that were made since the last version. Focus on what was changed — who, how and when are usually less important. Having said that, remember to politely attribute people who have provided notable help in making the package (e.g., those who have sent in patches). There's no need to elaborate the trivial and obvious changes. You can also aggregate several changes in one entry. On the other hand, don't be overly terse if you have undertaken a major change. Be especially clear if there are changes that affect the behaviour of the program. For further explanations, use the <file>README.Debian</file> file. Use common English so that the majority of readers can comprehend it. Avoid abbreviations, "tech-speak" and jargon when explaining changes that close bugs, especially for bugs filed by users that did not strike you as particularly technically savvy. Be polite, don't swear. It is sometimes desirable to prefix changelog entries with the names of the files that were changed. However, there's no need to explicitly list each and every last one of the changed files, especially if the change was small or repetitive. You may use wildcards. When referring to bugs, don't assume anything. Say what the problem was, how it was fixed, and append the "closes: #nnnnn" string. See <ref id="upload-bugfix"> for more information. <sect1 id="bpp-changelog-misconceptions"> <heading>Common misconceptions about changelog entries</heading> The changelog entries should not document generic packaging issues ("Hey, if you're looking for foo.conf, it's in /etc/blah/."), since administrators and users are supposed to be at least remotely acquainted with how such things are generally arranged on Debian systems. Do, however, mention if you change the location of a configuration file. The only bugs closed with a changelog entry should be those that are actually fixed in the same package revision. Closing unrelated bugs in the changelog is bad practice. See <ref id="upload-bugfix">. The changelog entries should not be used for random discussion with bug reporters ("I don't see segfaults when starting foo with option bar; send in more info"), general statements on life, the universe and everything ("sorry this upload took me so long, but I caught the flu"), or pleas for help ("the bug list on this package is huge, please lend me a hand"). Such things usually won't be noticed by their target audience, but may annoy people who wish to read information about actual changes in the package. See <ref id="bug-answering"> for more information on how to use the bug tracking system. It is an old tradition to acknowledge bugs fixed in non-maintainer uploads in the first changelog entry of the proper maintainer upload, for instance, in a changelog entry like this: <example> * Maintainer upload, closes: #42345, #44484, #42444. </example> This will close the NMU bugs tagged "fixed" when the package makes it into the archive. The bug for the fact that an NMU was done can be closed the same way. Of course, it's also perfectly acceptable to close NMU-fixed bugs by other means; see <ref id="bug-answering">. </sect1> <sect1 id="bpp-changelog-errors"> <heading>Common errors in changelog entries</heading> The following examples demonstrate some common errors or example of bad style in changelog entries. <example> * Fixed all outstanding bugs. </example> This doesn't tell readers anything too useful, obviously. <example> * Applied patch from Jane Random. </example> What was the patch about? <example> * Late night install target overhaul. </example> Overhaul which accomplished what? Is the mention of late night supposed to remind us that we shouldn't trust that code? <example> * Fix vsync FU w/ ancient CRTs. </example> Too many acronyms, and it's not overly clear what the, uh, fsckup (oops, a curse word!) was actually about, or how it was fixed. <example> * This is not a bug, closes: #nnnnnn. </example> First of all, there's absolutely no need to upload the package to convey this information; instead, use the bug tracking system. Secondly, there's no explanation as to why the report is not a bug. <example> * Has been fixed for ages, but I forgot to close; closes: #54321. </example> If for some reason you didn't mention the bug number in a previous changelog entry, there's no problem, just close the bug normally in the BTS. There's no need to touch the changelog file, presuming the description of the fix is already in (this applies to the fixes by the upstream authors/maintainers as well, you don't have to track bugs that they fixed ages ago in your changelog). <example> * Closes: #12345, #12346, #15432 </example> Where's the description? If you can't think of a descriptive message, start by inserting the title of each different bug. </sect1> </sect>  <sect id="bpp-debian-maint-scripts"> <heading>Best practices for maintainer scripts</heading> Maintainer scripts include the files <file>debian/postinst</file>, <file>debian/preinst</file>, <file>debian/prerm</file> and <file>debian/postrm</file>. These scripts take care of any package installation or deinstallation setup which isn't handled merely by the creation or removal of files and directories. The following instructions supplement the <url id="&url-debian-policy;" name="Debian Policy">. Maintainer scripts must be idempotent. That means that you need to make sure nothing bad will happen if the script is called twice where it would usually be called once. Standard input and output may be redirected (e.g. into pipes) for logging purposes, so don't rely on them being a tty. All prompting or interactive configuration should be kept to a minimum. When it is necessary, you should use the <package>debconf</package> package for the interface. Remember that prompting in any case can only be in the <tt>configure</tt> stage of the <file>postinst</file> script. Keep the maintainer scripts as simple as possible. We suggest you use pure POSIX shell scripts. Remember, if you do need any bash features, the maintainer script must have a bash sh-bang line. POSIX shell or Bash are preferred to Perl, since they enable <package>debhelper</package> to easily add bits to the scripts. If you change your maintainer scripts, be sure to test package removal, double installation, and purging. Be sure that a purged package is completely gone, that is, it must remove any files created, directly or indirectly, in any maintainer script. If you need to check for the existence of a command, you should use something like <example>if [ -x /usr/sbin/install-docs ]; then ...</example> If you don't wish to hard-code the path of the command in your maintainer script, the following POSIX-compliant shell function may help: &example-pathfind; You can use this function to search <tt>$PATH</tt> for a command name, passed as an argument. It returns true (zero) if the command was found, and false if not. This is really the most portable way, since <tt>command -v</tt>, <prgn>type</prgn>, and <prgn>which</prgn> are not POSIX. While <prgn>which</prgn> is an acceptable alternative, since it is from the required <package>debianutils</package> package, it's not on the root partition. That is, it's in <file>/usr/bin</file> rather than <file>/bin</file>, so one can't use it in scripts which are run before the <file>/usr</file> partition is mounted. Most scripts won't have this problem, though. </sect> <sect id="bpp-config-mgmt"> <heading>Configuration management with <package>debconf</package></heading> <package>Debconf</package> is a configuration management system which can be used by all the various packaging scripts (<file>postinst</file> mainly) to request feedback from the user concerning how to configure the package. Direct user interactions must now be avoided in favor of <package>debconf</package> interaction. This will enable non-interactive installations in the future. Debconf is a great tool but it is often poorly used. Many common mistakes are listed in the <manref name="debconf-devel" section="7"> man page. It is something that you must read if you decide to use debconf. </sect> <sect id="bpp-i18n"> <heading>Internationalization</heading> <sect1 id="bpp-i18n-debconf"> <heading>Handling debconf translations</heading> Like porters, translators have a difficult task. They work on many packages and must collaborate with many different maintainers. Moreover, most of the time, they are not native English speakers, so you may need to be particularly patient with them. The goal of <package>debconf</package> was to make packages configuration easier for maintainers and for users. Originally, translation of debconf templates was handled with <prgn>debconf-mergetemplate</prgn>. However, that technique is now deprecated; the best way to accomplish <package>debconf</package> internationalization is by using the <package>po-debconf</package> package. This method is easier both for maintainer and translators; transition scripts are provided. Using <package>po-debconf</package>, the translation is stored in <file>po</file> files (drawing from <prgn>gettext</prgn> translation techniques). Special template files contain the original messages and mark which fields are translatable. When you change the value of a translatable field, by calling <prgn>debconf-updatepo</prgn>, the translation is marked as needing attention from the translators. Then, at build time, the <prgn>dh_installdebconf</prgn> program takes care of all the needed magic to add the template along with the up-to-date translations into the binary packages. Refer to the <manref name="po-debconf" section="7"> manual page for details. </sect1> <sect1 id="bpp-i18n-docs"> <heading>Internationalized documentation</heading> Internationalizing documentation is crucial for users, but a lot of labor. There's no way to eliminate all that work, but you can make things easier for translators. If you maintain documentation of any size, its easier for translators if they have access to a source control system. That lets translators see the differences between two versions of the documentation, so, for instance, they can see what needs to be retranslated. It is recommended that the translated documentation maintain a note about what source control revision the translation is based on. An interesting system is provided by <url id="&url-i18n-doc-check;" name="doc-check"> in the <package>boot-floppies</package> package, which shows an overview of the translation status for any given language, using structured comments for the current revision of the file to be translated and, for a translated file, the revision of the original file the translation is based on. You might wish to adapt and provide that in your CVS area. If you maintain XML or SGML documentation, we suggest that you isolate any language-independent information and define those as entities in a separate file which is included by all the different translations. This makes it much easier, for instance, to keep URLs up-to-date across multiple files. </sect1> </sect> <sect id="bpp-common-situations"> <heading>Common packaging situations</heading>  <sect1 id="bpp-autotools"> <heading>Packages using <prgn>autoconf</prgn>/<prgn>automake</prgn></heading> Keeping <prgn>autoconf</prgn>'s <file>config.sub</file> and <file>config.guess</file> files up-to-date is critical for porters, especially on more volatile architectures. Some very good packaging practices for any package using <prgn>autoconf</prgn> and/or <prgn>automake</prgn> have been synthesized in &file-bpp-autotools; from the <package>autotools-dev</package> package. You're strongly encouraged to read this file and to follow the given recommendations. <sect1 id="bpp-libraries">Libraries Libraries are always difficult to package for various reasons. The policy imposes many constraints to ease their maintenance and to make sure upgrades are as simple as possible when a new upstream version comes out. A breakage in a library can result in dozens of dependent packages breaking. Good practices for library packaging have been grouped in <url id="&url-libpkg-guide;" name="the library packaging guide">. <sect1 id="bpp-docs">Documentation Be sure to follow the <url id="&url-debian-policy;ch-docs.html" name="Policy on documentation">. If your package contains documentation built from XML or SGML, we recommend you not ship the XML or SGML source in the binary package(s). If users want the source of the documentation, they should retrieve the source package. Policy specifies that documentation should be shipped in HTML format. We also recommend shipping documentation in PDF and plain text format if convenient and quality output is possible. However, it is generally not appropriate to ship plain text versions of documentation whose source format is HTML. Major shipped manuals should register themselves with <package>doc-base</package> on installation. See the <package>doc-base</package> package documentation for more information. <sect1 id="bpp-other">Specific types of packages Several specific types of packages have special sub-policies and corresponding packaging rules and practices: <list> <item> Perl related packages have a <url name="Perl policy" id="&url-perl-policy;">, some examples of packages following that policy are <package>libdbd-pg-perl</package> (binary perl module) or <package>libmldbm-perl</package> (arch independent perl module). <item> Python related packages have their python policy; see &file-python-policy; in the <package>python</package> package. <item> Emacs related packages have the <url id="&url-emacs-policy;" name="emacs policy">. <item> Java related packages have their <url id="&url-java-policy;" name="java policy">. <item> Ocaml related packages have their own policy, found in &file-ocaml-policy; from the <package>ocaml</package> package. A good example is the <package>camlzip</package> source package. <item> Packages providing XML or SGML DTDs should conform to the recommendations found in the <package>sgml-base-doc</package> package. <item> Lisp packages should register themselves with <package>common-lisp-controller</package>, about which see &file-lisp-controller;. </list> </sect1>  <sect1 id="bpp-archindepdata"> <heading>Architecture-independent data</heading> It is not uncommon to have a large amount of architecture-independent data packaged with a program. For example, audio files, a collection of icons, wallpaper patterns, or other graphic files. If the size of this data is negligible compared to the size of the rest of the package, it's probably best to keep it all in a single package. However, if the size of the data is considerable, consider splitting it out into a separate, architecture-independent package ("_all.deb"). By doing this, you avoid needless duplication of the same data into eleven or more .debs, one per each architecture. While this adds some extra overhead into the <file>Packages</file> files, it saves a lot of disk space on Debian mirrors. Separating out architecture-independent data also reduces processing time of <prgn>lintian</prgn> or <prgn>linda</prgn> (see <ref id="tools-lint">) when run over the entire Debian archive. </sect1> </sect> </chapt> <chapt id="beyond-pkging"> <heading>Beyond Packaging</heading> Debian is about a lot more than just packaging software and maintaining those packages. This chapter contains information about ways, often really critical ways, to contribute to Debian beyond simply creating and maintaining packages. As a volunteer organization, Debian relies on the discretion of its members in choosing what they want to work on and in choosing the most critical thing to spend their time on. <sect id="submit-bug"> <heading>Bug reporting</heading> We encourage you to file bugs as you find them in Debian packages. In fact, Debian developers are often the first line testers. Finding and reporting bugs in other developers' packages improves the quality of Debian. Read the <url name="instructions for reporting bugs" id="&url-bts-report;"> in the Debian <url name="bug tracking system" id="&url-bts;">. Try to submit the bug from a normal user account at which you are likely to receive mail, so that people can reach you if they need further information about the bug. Do not submit bugs as root. You can use a tool like <manref name="reportbug" section="1"> to submit bugs. It can automate and generally ease the process. Make sure the bug is not already filed against a package. Each package has a bug list easily reachable at <tt>http://&bugs-host;/<var>packagename</var></tt> Utilities like <manref name="querybts" section="1"> can also provide you with this information (and <prgn>reportbug</prgn> will usually invoke <prgn>querybts</prgn> before sending, too). Try to direct your bugs to the proper location. When for example your bug is about a package that overwrites files from another package, check the bug lists for both of those packages in order to avoid filing duplicate bug reports. For extra credit, you can go through other packages, merging bugs which are reported more than once, or tagging bugs `fixed' when they have already been fixed. Note that when you are neither the bug submitter nor the package maintainer, you should not actually close the bug (unless you secure permission from the maintainer). From time to time you may want to check what has been going on with the bug reports that you submitted. Take this opportunity to close those that you can't reproduce anymore. To find out all the bugs you submitted, you just have to visit <tt>http://&bugs-host;/from:<var><your-email-addr></var></tt>. <sect1 id="submit-many-bugs">Reporting lots of bugs at once Reporting a great number of bugs for the same problem on a great number of different packages — i.e., more than 10 — is a deprecated practice. Take all possible steps to avoid submitting bulk bugs at all. For instance, if checking for the problem can be automated, add a new check to <package>lintian</package> so that an error or warning is emitted. If you report more than 10 bugs on the same topic at once, it is recommended that you send a message to &email-debian-devel; describing your intention before submitting the report. This will allow other developers to verify that the bug is a real problem. In addition, it will help prevent a situation in which several maintainers start filing the same bug report simultaneously. Note that when sending lots of bugs on the same subject, you should send the bug report to <email>maintonly@&bugs-host;</email> so that the bug report is not forwarded to the bug distribution mailing list. <sect id="qa-effort">Quality Assurance effort <sect1 id="qa-daily-work">Daily work Even though there is a dedicated group of people for Quality Assurance, QA duties are not reserved solely for them. You can participate in this effort by keeping your packages as bug-free as possible, and as lintian-clean (see <ref id="lintian">) as possible. If you do not find that possible, then you should consider orphaning some of your packages (see <ref id="orphaning">). Alternatively, you may ask the help of other people in order to catch up the backlog of bugs that you have (you can ask for help on &email-debian-qa; or &email-debian-devel;). At the same time, you can look for co-maintainers (see <ref id="collaborative-maint">). <sect1 id="qa-bsp">Bug squashing parties From time to time the QA group organizes bug squashing parties to get rid of as many problems as possible. They are announced on &email-debian-devel-announce; and the announce explains what area will be focused on during the party: usually they focus on release critical bugs but it may happen that they decide to help finish a major upgrade going on (like a new perl version which requires recompilation of all the binary modules). The rules for non-maintainer uploads differ during the parties because the announce of the party is considered like a prior notice for NMU. If you have packages that may be affected by the party (because they have release critical bugs for example), you should send an update to each of the corresponding bug to explain their current status and what you expect from the party. If you don't want an NMU, or if you're only interested in a patch, or if you will deal yourself with the bug, please explain that in the BTS. People participating in the party have special rules for NMU, they can NMU without prior notice if they upload their NMU to DELAYED/3-day at least. All other NMU rules applies as usually, they should send the patch of the NMU in the BTS (in one of the open bugs fixed by the NMU or in a new bug tagged fixed). They should also respect the maintainer's wishes if he expressed some. If someone doesn't feel confident with an NMU, he should just send a patch to the BTS. It's far better than a broken NMU. <sect id="contacting-maintainers">Contacting other maintainers During your lifetime within Debian, you will have to contact other maintainers for various reasons. You may want to discuss a new way of cooperating between a set of related packages, or you may simply remind someone that a new upstream version is available and that you need it. Looking up the email address of the maintainer for the package can be distracting. Fortunately, there is a simple email alias, <tt><package>@&packages-host;</tt>, which provides a way to email the maintainer, whatever their individual email address (or addresses) may be. Replace <tt><package></tt> with the name of a source or a binary package. You may also be interested in contacting the persons who are subscribed to a given source package via <ref id="pkg-tracking-system">. You can do so by using the <tt><package-name>@&pts-host;</tt> email address. <sect id="mia-qa">Dealing with inactive and/or unreachable maintainers If you notice that a package is lacking maintenance, you should make sure that the maintainer is active and will continue to work on their packages. It is possible that they are not active any more, but haven't registered out of the system, so to speak. On the other hand, it is also possible that they just need a reminder. The first step is to politely contact the maintainer, and wait for a response, for a reasonable time. It is quite hard to define "reasonable time", but it is important to take into account that real life is sometimes very hectic. One way to handle this would be send a reminder after two weeks. If the maintainer doesn't reply within four weeks (a month), one can assume that a response will probably not happen. If that happens, you should investigate further, and try to gather as much useful information about the maintainer in question as possible. This includes: <list> <item>The "echelon" information available through the <url id="&url-debian-db;" name="developers' LDAP database">, which indicates when's the last time a developer has posted to a Debian mailing list. (This includes uploads via debian-*-changes lists.) Also, remember to check whether the maintainer is marked as "on vacation" in the database. <item>The number of packages this maintainer is responsible for, and the condition of those packages. In particular, are there any RC bugs that have been open for ages? Furthermore, how many bugs are there in general? Another important piece of information is whether the packages have been NMUed, and if so, by whom? <item>Is there any activity of the maintainer outside of Debian? For example, they might have posted something recently to non-Debian mailing lists or news groups. </list> One big problem are packages which were sponsored -- the maintainer is not an official Debian developer. The echelon information is not available for sponsored people, for example, so you need to find and contact the Debian developer who has actually uploaded the package. Given that they signed the package, they're responsible for the upload anyhow, and should know what happened to the person they sponsored. It is also allowed to post a query to &email-debian-devel;, asking if anyone is aware of the whereabouts of the missing maintainer. Once you have gathered all of this, you can contact &email-debian-qa;. People on this alias will use the information you provided in order to decide how to proceed. For example, they might orphan one or all of the packages of the maintainer. If a packages has been NMUed, they might prefer to contact the NMUer before orphaning the package -- perhaps the person who has done the NMU is interested in the package. One last word: please remember to be polite. We are all volunteers and cannot dedicate all of our time to Debian. Also, you are not aware of the circumstances of the person who is involved. Perhaps they might be seriously ill or might even had died -- you do not know who may be on the receiving side -- imagine how a relative will feel if they read the e-mail of the deceased and find a very impolite, angry and accusing message!) On the other hand, although we are volunteers, we do have a responsibility. So you can stress the importance of the greater good -- if a maintainer does not have the time or interest anymore, they should "let go" and give the package to someone with more time. <sect id="newmaint"> <heading>Interacting with prospective Debian developers</heading> Debian's success depends on its ability to attract and retain new and talented volunteers. If you are an experienced developer, we recommend that you get involved with the process of bringing in new developers. This section describes how to help new prospective developers. <sect1 id="sponsoring">Sponsoring packages Sponsoring a package means uploading a package for a maintainer who is not able to do it on their own, a new maintainer applicant. Sponsoring a package also means accepting responsibility for it. If you wish to volunteer as a sponsor, you can sign up at <url id="&url-sponsors;">. New maintainers usually have certain difficulties creating Debian packages — this is quite understandable. That is why the sponsor is there, to check the package and verify that it is good enough for inclusion in Debian. (Note that if the sponsored package is new, the ftpmasters will also have to inspect it before letting it in.) Sponsoring merely by signing the upload or just recompiling is definitely not recommended. You need to build the source package just like you would build a package of your own. Remember that it doesn't matter that you left the prospective developer's name both in the changelog and the control file, the upload can still be traced to you. If you are an application manager for a prospective developer, you can also be their sponsor. That way you can also verify how the applicant is handling the 'Tasks and Skills' part of their application. <sect1>Managing sponsored packages By uploading a sponsored package to Debian, you are certifying that the package meets minimum Debian standards. That implies that you must build and test the package on your own system before uploading. You can not simply upload a binary <file>.deb</file> from the sponsoree. In theory, you should only ask for the diff file and the location of the original source tarball, and then you should download the source and apply the diff yourself. In practice, you may want to use the source package built by your sponsoree. In that case, you have to check that they haven't altered the upstream files in the <file>.orig.tar.gz</file> file that they're providing. Do not be afraid to write the sponsoree back and point out changes that need to be made. It often takes several rounds of back-and-forth email before the package is in acceptable shape. Being a sponsor means being a mentor. Once the package meets Debian standards, build and sign it with <example>dpkg-buildpackage -k<var>KEY-ID</var></example> before uploading it to the incoming directory. The Maintainer field of the <file>control</file> file and the <file>changelog</file> should list the person who did the packaging, i.e., the sponsoree. The sponsoree will therefore get all the BTS mail about the package. If you prefer to leave a more evident trace of your sponsorship job, you can add a line stating it in the most recent changelog entry. You are encouraged to keep tabs on the package you sponsor using <ref id="pkg-tracking-system">. <sect1>Advocating new developers See the page about <url id="&url-newmaint-advocate;" name="advocating a prospective developer"> at the Debian web site. <sect1>Handling new maintainer applications Please see <url id="&url-newmaint-amchecklist;" name="Checklist for Application Managers"> at the Debian web site. <appendix id="tools">Overview of Debian Maintainer Tools This section contains a rough overview of the tools available to maintainers. The following is by no means complete or definitive, but just a guide to some of the more popular tools. Debian maintainer tools are meant to help convenience developers and free their time for critical tasks. As Larry Wall says, there's more than one way to do it. Some people prefer to use high-level package maintenance tools and some do not. Debian is officially agnostic on this issue; any tool which gets the job done is fine. Therefore, this section is not meant to stipulate to anyone which tools they should use or how they should go about with their duties of maintainership. Nor is it meant to endorse any particular tool to the exclusion of a competing tool. Most of the descriptions of these packages come from the actual package descriptions themselves. Further information can be found in the package documentation itself. You can also see more info with the command <tt>apt-cache show <package-name></tt>. <sect id="tools-core"> <heading>Core tools</heading> The following tools are pretty much required for any maintainer. <sect1 id="dpkg-dev"> <heading><package>dpkg-dev</package> <package>dpkg-dev</package> contains the tools (including <prgn>dpkg-source</prgn>) required to unpack, build and upload Debian source packages. These utilities contain the fundamental, low-level functionality required to create and manipulated packages; as such, they are required for any Debian maintainer. <sect1 id="debconf"> <heading><package>debconf</package></heading> <package>debconf</package> provides a consistent interface to configuring packages interactively. It is user interface independent, allowing end-users to configure packages with a text-only interface, an HTML interface, or a dialog interface. New interfaces can be added modularly. You can find documentation for this package in the <package>debconf-doc</package> package. Many feel that this system should be used for all packages requiring interactive configuration; see <ref id="bpp-config-mgmt">. <package>debconf</package> is not currently required by Debian Policy, but that may change in the future. </sect1> <sect1 id="fakeroot"> <heading><package>fakeroot</package> <package>fakeroot</package> simulates root privileges. This enables you to build packages without being root (packages usually want to install files with root ownership). If you have <package>fakeroot</package> installed, you can build packages as a user: <tt>dpkg-buildpackage -rfakeroot</tt>. </sect1> </sect> <sect id="tools-lint"> <heading>Package lint tools</heading> According to the Free On-line Dictionary of Computing (FOLDOC), `lint' is "a Unix C language processor which carries out more thorough checks on the code than is usual with C compilers." Package lint tools help package maintainers by automatically finding common problems and policy violations with their packages. <sect1 id="lintian"> <heading><package>lintian</package></heading> <package>lintian</package> dissects Debian packages and emits information on bugs and policy violations. It contains automated checks for many aspects of Debian policy as well as some checks for common errors. You should periodically get the newest <package>lintian</package> from `unstable' and check over all your packages. Notice that the <tt>-i</tt> option provides detailed explanations of what each error or warning means, what is its basis in Policy, and commonly how you can fix the problem. Refer to <ref id="sanitycheck"> for more information on how and when to use Lintian. You can also see a summary of all problems reported by Lintian on your packages at <url id="&url-lintian;">. Those reports contain the latest <prgn>lintian</prgn> output on the whole development distribution ("unstable"). </sect1> <sect1 id="linda"> <heading><package>linda</package></heading> <package>linda</package> is another package linter. It is similar to <package>lintian</package> but has a different set of checks. Its written in Python rather than Perl. </sect1> <sect1 id="debdiff"> <heading><package>debdiff</package></heading> <prgn>debdiff</prgn> (from the <package>devscripts</package> package, <ref id="devscripts">) compares file lists and control files of two packages. It is a simple regression test, as it will help you notice if the number of binary packages has changed since the last upload, or if something's changed in the control file. Of course, some of the changes it reports will be all right, but it can help you prevent various accidents. You can run it over a pair of binary packages: <example> debdiff package_1-1_arch.deb package_2-1_arch.deb </example> Or even a pair of changes files: <example> debdiff package_1-1_arch.changes package_2-1_arch.changes </example> For more information please see <manref name="debdiff" section="1">. </sect1> </sect> <sect id="tools-helpers"> <heading>Helpers for <file>debian/rules</file></heading> Package building tools make the process of writing <file>debian/rules</file> files easier. See <ref id="helper-scripts"> for more information on why these might or might not be desired. <sect1 id="debhelper"> <heading><package>debhelper</package></heading> <package>debhelper</package> is a collection of programs that can be used in <file>debian/rules</file> to automate common tasks related to building binary Debian packages. Programs are included to install various files into your package, compress files, fix file permissions, integrate your package with the Debian menu system. Unlike some approaches, <package>debhelper</package> is broken into several small, granular commands which act in a consistent manner. As such, it allows a greater granularity of control than some of the other "debian/rules tools". There are a number of little <package>debhelper</package> add-on packages, too transient to document. You can see the list of most of them by doing <tt>apt-cache search ^dh-</tt>. </sect1> <sect1 id="debmake"> <heading><package>debmake</package> <package>debmake</package>, a pre-cursor to <package>debhelper</package>, is a less granular <file>debian/rules</file> assistant. It includes two main programs: <prgn>deb-make</prgn>, which can be used to help a maintainer convert a regular (non-Debian) source archive into a Debian source package; and <prgn>debstd</prgn>, which incorporates in one big shot the same sort of automated functions that one finds in <package>debhelper</package>. The consensus is that <package>debmake</package> is now deprecated in favor of <package>debhelper</package>. However, it's not a bug to use <package>debmake</package>. </sect1> <sect1 id="dh-make"> <heading><package>dh-make</package> The <package/dh-make/ package contains <prgn/dh_make/, a program that creates a skeleton of files necessary to build a Debian package out of a source tree. As the name suggests, <prgn/dh_make/ is a rewrite of <package/debmake/ and its template files use dh_* programs from <package/debhelper/. While the rules files generated by <prgn/dh_make/ are in general a sufficient basis for a working package, they are still just the groundwork: the burden still lies on the maintainer to finely tune the generated files and make the package entirely functional and Policy-compliant. </sect1> <sect1 id="yada"> <heading><package>yada</package> <package>yada</package> is another packaging helper tool. It uses a <file>debian/packages</file> file to auto-generate <file>debian/rules</file> and other necessary files in the <file>debian/</file> subdirectory. Note that <package>yada</package> is called "essentially unmaintained" by it's own maintainer, Charles Briscoe-Smith. As such, it can be considered deprecated. </sect1> <sect1 id="equivs"> <heading><package>equivs</package> <package>equivs</package> is another package for making packages. It is often suggested for local use if you need to make a package simply to fulfill dependencies. It is also sometimes used when making ``meta-packages'', which are packages whose only purpose is to depend on other packages. </sect1> </sect> <sect id="tools-builders"> <heading>Package builders</heading> The following packages help with the package building process, general driving <prgn>dpkg-buildpackage</prgn> as well as handling supporting tasks. <sect1 id="cvs-buildpackage"> <heading><package>cvs-buildpackage</package> <package>cvs-buildpackage</package> provides the capability to inject or import Debian source packages into a CVS repository, build a Debian package from the CVS repository, and helps in integrating upstream changes into the repository. These utilities provide an infrastructure to facilitate the use of CVS by Debian maintainers. This allows one to keep separate CVS branches of a package for stable, unstable and possibly experimental distributions, along with the other benefits of a version control system. </sect1> <sect1 id="debootstrap"> <heading><package>debootstrap</package></heading> The <package>debootstrap</package> package and script allows you to "bootstrap" a Debian base system into any part of your file-system. By "base system", we mean the bare minimum of packages required to operate and install the rest of the system. Having a system like this can be useful in many ways. For instance, you can <prgn>chroot</prgn> into it if you want to test your build depends. Or, you can test how your package behaves when installed into a bare base system. Chroot builders use this package, see below. </sect1> <sect1 id="pbuilder"> <heading><package>pbuilder</package></heading> <package>pbuilder</package> constructs a chrooted system, and builds a package inside the chroot. It is very useful to check that a package's build-dependencies are correct, and to be sure that unnecessary and wrong build dependencies will not exist in the resulting package. A related package is <package>pbuilder-uml</package>, which goes even further build doing the build within User-mode-linux. </sect1> <sect1 id="sbuild"> <heading><package>sbuild</package></heading> <package>sbuild</package> is another automated builder. It can use chrooted environments as well. It can be used stand-alone, or as part of a networked, distributed build environment. As the latter, it is part of the system used by porters to build binary packages for all the available architectures. See <ref id="buildd"> for more information, and <url id="&url-buildd;"> to see the system in action. </sect1> </sect> <sect id="uploaders"> <heading>Package uploaders</heading> The following packages help automate or simplify the process of uploading packages into the official archive. <sect1 id="dupload"> <heading><package>dupload</package></heading> <package>dupload</package> is a package and a script to automatically upload Debian packages to the Debian archive, to log the upload, and to send mail about the upload of a package. You can configure it for new upload locations or methods. </sect1> <sect1 id="dput"> <heading><package>dput</package></heading> The <package>dput</package> package and script does much the same thing as <package>dupload</package>, but in a different way. It has some features over <package>dupload</package>, such as the ability to check the GnuPG signature and checksums before uploading, and the possibility of running <prgn>dinstall</prgn> in dry-run mode after the upload. </sect1> </sect> <sect id="tools-maint-automate"> <heading>Maintenance automation</heading> The following tools help automate different maintenance tasks, from adding changelog entries or signature lines, looking up bugs in Emacs, to making use of the newest and official use of <file>config.sub</file>. <sect1 id="devscripts"> <heading><package>devscripts</package></heading> <package>devscripts</package> is a package containing wrappers and tools which are very helpful for maintaining your Debian packages. Example scripts include <prgn>debchange</prgn> and <prgn>dch</prgn>, which manipulate your <file>debian/changelog</file> file from the command-line, and <prgn>debuild</prgn>, which is a wrapper around <prgn>dpkg-buildpackage</prgn>. The <prgn>bts</prgn> utility is also very helpful to update the state of bug reports on the command line. <prgn>uscan</prgn> can be used to watch for new upstream versions of your packages. The <prgn>debrsign</prgn> can be used to remotely sign a package prior to upload, which is nice when the machine you build the package on is different from where your GPG keys are. See the <manref name="devscripts" section="1"> manual page for a complete list of available scripts. </sect1> <sect1 id="autotools-dev"> <heading><package>autotools-dev</package></heading> Contains best practices for people maintaining packages that use <prgn>autoconf</prgn> and/or <prgn>automake</prgn>. Also contains canonical <file>config.sub</file> and <file>config.guess</file> files which are known to work on all Debian ports. </sect1> <sect1 id="dpkg-repack"> <heading><package>dpkg-repack</package></heading> <prgn>dpkg-repack</prgn> creates Debian package file out of a package that has already been installed. If any changes have been made to the package while it was unpacked (e.g., files in <file>/etc</file> were modified), the new package will inherit the changes. This utility can make it easy to copy packages from one computer to another, or to recreate packages that are installed on your system but no longer available elsewhere, or to store the current state of a package before you upgrade it. </sect1> <sect1 id="alien"> <heading><package>alien</package></heading> <prgn>alien</prgn> converts binary packages between various packaging formats, including Debian, RPM (RedHat), LSB (Linux Standard Base), Solaris and Slackware packages. </sect1> <sect1 id="debsums"> <heading><package>debsums</package></heading> <prgn>debsums</prgn> checks installed packages against their MD5 sums. Note that not all packages have MD5 sums, since they aren't required by Policy. </sect1> <sect1 id="dpkg-dev-el"> <heading><package>dpkg-dev-el</package></heading> <package>dpkg-dev-el</package> is an Emacs lisp package which provides assistance when editing some of the files in the <file>debian</file> directory of your package. For instance, when editing <file>debian/changelog</file>, there are handy functions for finalizing a version and listing the package's current bugs. </sect1> <sect1 id="dpkg-depcheck"> <heading><package>dpkg-depcheck</package></heading> <prgn>dpkg-depcheck</prgn> (from the <package>devscripts</package> package, <ref id="devscripts">) runs a command under <prgn>strace</prgn> to determine all the packages that were used by the said command. For Debian packages, this is useful when you have to compose a <tt>Build-Depends</tt> line for your new package: running the build process through <prgn>dpkg-depcheck</prgn> will provide you with a good first approximation of the build-dependencies. For example: <example> dpkg-depcheck -b debian/rules build </example> <prgn>dpkg-depcheck</prgn> can also be used to check for run-time dependencies, especially if your package uses exec(2) to run other programs. For more information please see <manref name="dpkg-depcheck" section="1">. </sect1> </sect> <sect id="tools-porting"> <heading>Porting tools</heading> The following tools are helpful for porters and for cross-compilation. <sect1 id="quinn-diff"> <heading><package>quinn-diff</package> <package>quinn-diff</package> is used to locate the differences from one architecture to another. For instance, it could tell you which packages need to be ported for architecture <var>Y</var>, based on architecture <var>X</var>. <sect1 id="dpkg-cross"> <heading><package>dpkg-cross</package> <package>dpkg-cross</package> is a tool for installing libraries and headers for cross-compiling in a way similar to <package>dpkg</package>. Furthermore, the functionality of <prgn>dpkg-buildpackage</prgn> and <prgn>dpkg-shlibdeps</prgn> is enhanced to support cross-compiling. </sect1> <sect id="tools-doc"> <heading>Documentation and information</heading> The following packages provide information for maintainers or help with building documentation. <sect1 id="debiandoc-sgml"> <heading><package>debiandoc-sgml</package></heading> <package>debiandoc-sgml</package> provides the DebianDoc SGML DTD, which is commonly used for Debian documentation. This manual, for instance, is written in DebianDoc. It also provides scripts for building and styling the source to various output formats. Documentation for the DTD can be found in the <package>debiandoc-sgml-doc</package> package. </sect1> <sect1 id="debian-keyring"> <heading><package>debian-keyring</package></heading> Contains the public GPG and PGP keys of Debian developers. See <ref id="key-maint"> and the package documentation for more information. </sect1> <sect1 id="debview"> <heading><package>debview</package></heading> <package>debview</package> provides an Emacs mode for viewing Debian binary packages. This lets you examine a package without unpacking it. </sect1> </sect>  </appendix> </book> </debiandoc>

%versiondata; %commondata; FIXME: "> ]> Guida di riferimento per lo sviluppatore Debian <author>Developer's Reference Team &email-devel-ref; <author>Adam Di Carlo, editor <author>Raphaël Hertzog <author>Christian Schwarz <author>Ian Jackson <author> <translator>Traduzione:</translator> <translator>Francesco Donadon <francesco.donadon@katamail.com></translator> <translator>Emanuele Rocca <ema@debian.org></translator> <version>ver. &version;, &date-it; <copyright> <copyrightsummary> copyright © 1998—2003 Adam Di Carlo</copyrightsummary> <copyrightsummary> copyright © 2002—2003 Raphaël Hertzog</copyrightsummary> <copyrightsummary> copyright © 1997, 1998 Christian Schwarz</copyrightsummary> Questo manuale è considerato free software; puoi redistribuirlo e/o modificarlo sotto le condizioni della GNU General Public License rilasciata dalla Free Software Foundation; versione 2 o (a tua discrezione) qualunque versione successiva. Questo manuale è distribuito nella speranza che sia utile, ma senza alcuna garanzia; senza neanche la garanzia implicita che sia commerciabile o utile per un particolare scopo. Leggi la GNU General Public License per ulteriori dettagli. Una copia della GNU General Public License è disponibile nel file &file-GPL; all'interno della distribuzione &debian-formal; o in rete su <url id="&url-gpl;" name="il sito web GNU">. Puoi anche ottenerne una copia scrivendo a &fsf-addr;. <toc detail="sect1"> <chapt id="scope">Scopo Di Questo Documento L'obiettivo di questo documento è di fornire una vista d'insieme delle procedure raccomandate e le risorse disponibili agli sviluppatori Debian.  Le procedure qui discusse includono come diventare un mantainer (<ref id="new-maintainer">); come creare nuovi pachetti (<ref id="newpackage">) e come effettuarne l'upload (<ref id="upload">); come gestire i bug reports (<ref id="bug-handling">); come muovere, rimuovere, o abbandonare pacchetti (<ref id="archive-manip">); come fare il port di pacchetti (<ref id="porting">); e come e quando rilasciare versioni temporanee di pacchetti di altri mantainers (<ref id="nmu">). Le risorse qui discusse includono le mailing list (<ref id="mailing-lists">) X.YZWe i server (<ref id="server-machines">); una discussione sulla struttura dell'archivio Debian (<ref id="archive">); spiegazione sui diversi server che accettano l'upload di pacchetti (<ref id="upload-ftp-master">); e una discussione sulle risorse che possono aiutare i mantainer a curare la qualità dei propri pacchetti. (<ref id="tools">). Dovrebbe essere chiaro che questo documento non scende nei dettagli tecnici dei pacchetti Debian e neppure su come generare detti pacchetti. Questa guida non spiega nemmeno in dettaglio gli standard a cui i pacchetti Debian devono sottostare. Tutte queste informazioni possono essere trovate nella <url id="&url-debian-policy;" name="Debian Policy">. Inoltre, questo documento non è espressione formale della politica Debian. Contiene la documentazione per il sistema Debian e i -generalmente convenuti- migliori metodi  operativi. Quindi, è ciò che è chiamato un documento ``normativo''. <chapt id="new-maintainer">Applying per diventare un maintainer <sect id="getting-started">Iniziare Hai letto tutta la documentazione, sei gone through la <url id="&url-newmaint-guide;" name="Debian New Maintainers' Guide">, hai capito a cosa serve ogni parte del pacchetto di esempio <package>hello</package> e stai per Debianizzare il tuo software preferito. Ma come diventare uno sviluppatore Debian in modo da incorporare il tuo lavoro nel Progetto? Innanzitutto, iscriviti alla lista &email-debian-devel; se non l'hai ancora fatto. Invia la parola <tt>subscribe</tt> nelSubject di una email a &email-debian-devel-req;. In caso di problemi, contatta l'amministratore delle liste a &email-listmaster;. Altre informazioni sulle mailing list disponibili possono essere trovate in <ref id="mailing-lists">. &email-debian-devel-announce; è un'altra lista essenziale per chiunque voglia seguire lo sviluppo di Debian. Dovresti iscriverti e "lurkare" (leggere senza inviare messaggi) per un pò prima di iniziare a sviluppare e dovresti post la tua intenzione di lavorare su qualcosa per evitare di duplicare gli sforzi. Un' altra buona lista cui iscriversi è &email-debian-mentors;. Vedi <ref id="mentors"> per i dettagoi. Il canale IRC <tt>#debian</tt> può anche esserre d'aiuto. Quando hai deciso come vuoi contribuire a &debian-formal;, dovresti metterti in contatto con dei maintainer Debian che lavorano su tasks simili. In questo modo puoi imparare da sviluppatori esperti. Per esempio, se sei interessato a pacchettizzare software esistente per Debian dovresti provare a trovare uno sponsor. Uno sponsor lavorerà con te sul tuo pacchetto e ne effettuerà l'upload nell'archivio Debian una volta che sarà soddisfatto del tuo lavoro di pacchetizzazione. Puoi trovare uno sponsor inviando una mail alla mailing list &email-debian-mentors;, descrivendo il tuo pacchetto and yourself (vedi <ref id="sponsoring"> per maggiori informazioni sullo sponsoring). D'altro canto, se sei interessato nel port di Debian ad architetture alternative o kernel non ancora supportati puoi iscriverti alle mailinglist relative al tuo port e chiedere da dove iniziare. Infine, se sei interessato a lavorare sulla documentazione o alla Quality Assurance (QA) puoi unirti agli sviluppatori che lavorano in questi campi ed inviare patch e miglioramenti. <sect id="registering">Registrarsi come sviluppatore Debian Prima di decidere di unirti a &debian-formal;, hai bisogno di leggere tutte le informazioni disponibili nell' <url id="&url-newmaint;" name="Angolo del nuovo manutentore">. Esso descrive esattamente la preparazione che devi seguire prima di poterti registrare per diventare uno sviluppatore Debian. Per esempio, prima di iniziare la procedura devi leggere il <url id="&url-social-contract;" name="Contratto sociale Debian">. Diventare sviluppatore significa essere d'accordo con il Contratto sociale Debian ed impegnarsi a sostenerlo; è molto importante che gli sviluppatori siano d'accordo con le idee essenziali che stanno dietro &debian-formal;. Anche il <url id="&url-gnu-manifesto;" name="Manifesto GNU"> può essere una buona lettura. Il processo per diventare sviluppatore consiste nella verifica della tua identità e delle tue intenzioni, nonchè il controllo delle tue capacità tecniche. Considerando che il numero di persone che lavorano su &debian-formal; è cresciuto a più di &number-of-maintainers; persone e che i nostri sistemi sono usati in posti molto importanti dobbiamo stare attenti a non essere compromessi. Quindi, dobbiamo verificare i nuovi manutentori prima di fornire loro degli accessi sui nostri server e di permettergli di effettuare degli upload di pacchetti. Prima di registrarti dovresti aver dimostrato che puoi fare del lavoro competente e contribuire positivamente. Puoi dimostrarlo inviando delle patch tramite il Bug Tracking System o avendo un pacchetto sponsorizzato da uno sviluppatore Debian per un pò di tempo. Inoltre ci aspettiamo che chi contribuisce sia interessato al Progetto intero e non solo al mantenere il proprio software. Se puoi aiutare gli altri manutentori inviando maggiori informazioni su un bug o magari una patch, fallo! La registrazione richiede che tu abbia familiarità con la filosofia Debian e la documentazione tecnica. Inoltre, hai bisogno di una chiave GnuPG firmata da un manutentore. Se la tua chiave GnuPG non è firmata dovresti provare ad incontrare uno sviluppatore Debian di persona per avere la sua firma sulla tua chiave. C'è una <url id="&url-gpg-coord;" name="Pagina di coordinamento per la firma delle chiavi GnuPG Key"> che dovrebbe aiutarti a trovare un manutentore vicino a te (se non riesci a trovarlo c'è un modo alternativo per passare il controllo dell'identità puoi inviare un photo ID firmato con la tua chiave GnuPG. Avere la tua chiave GnuPG firmata è il modo migliore, comunque. Vedi la <url id="&url-newmaint-id;" name="identification page"> per maggiori informazioni su queste due opzioni). Se non hai ancora una chiave OpenPGP, generane una. Ogni sviluppatore ne ha bisogno per firmare e verificare gli upload di pacchetti. Dovresti leggere la documentazione del software che stai usando visto che vi sono molte informazioni critiche dal punto di vista della sicurezza. Sono più i problemi di sicurezza dovuti ad errori umani rispetto a quelli imputabili a problemi nel software or high-powered spy techniques. Vedi <ref id="key-maint"> per maggiori informazioni sul mantenimento della tua chiave pubblica. Debian utilizza <prgn>GNU Privacy Guard</prgn> (pacchetto <package>gnupg</package>, versione 1 o superiore) come standard. Puoi comunque usare altre implementazioni di OpenPGP. Nota che OpenPGP è uno standard aperto basato sull' <url id="&url-rfc2440;" name="RFC 2440">. L'algoritmo di chiave pubblica raccomandato per lo sviluppo in Debian è il DSA (a volte chiamato ``DSS'' o ``DH/ElGamal''). Comunque possono essere usati altri tipi di chiavi. La tua chiave deve essere lunga al meno 1024 bit; non c'è motivo di usare una chiave più piccola e farlo implica un livello di sicurezza molto più basso. La tua chiave deve essere firmata almeno dai tuoi user ID; questo previene lo "user ID tampering". <prgn>gpg</prgn> lo fa automaticamente. Se la tua chiave pubblica non è su keyserver pubblici come &pgp-keyserv;, leggi la documentazione disponibile localmente in &file-keyservs;. Quel documento contiene istruzioni su come mettere la tua chiave sui keyserver pubblici. Il New Maintainer Group metterà la tua chiave pubblica sui server se non c'è già. Alcuni paesi limitano l'utilizzo di software crittografico ai propri cittadini. Questo non impedisce l'attività come manutentore di pacchetti Debian, visto che è perfettamente legale l'utilizzo di prodotti crittografico per l'autenticazione, piuttosto che per la crittazione. &debian-formal; non richiede l'uso della crittografia qua in alcun modo. Se vivi in un paese dove l'uso della crittografia è proibito anche per scopi di autenticazione sei pregato di contattarci così che possiamo trovare special arrangements. Per apply as a new maintainer, hai bisogno di un maintainer Debian che verifichi la tua application (un advocate). Dopo che hai contribuito a Debian per un pò di tempo, e vuoi apply per diventare uno sviluppatore registrato, uno sviluppatore esistente con cui hai lavorato nei mesi precedenti deve express their belief che puoi contribuire a Debian con successo. Quando hai trovato un advocate, hai la tua chiave GnuPG firmata e hai contribuito a Debian per un periodo, sei pronto ad apply. Puoi semplicemente registrarti sulla nostra<url id="&url-newmaint-apply;" name="pagina di application">. Dopo che ti sei registrato, un advocate deve confermare la tua application. Quando il tuo advocate ha completato questo passo ti verrà assegnato un Application Manager che effettuerà con te i passi del New Maintainer process. Puoi sempre controllare lo stato sull'<url id="&url-newmaint-db;" name="applications status board">. Per ulteriori dettagli, consulta <url id="&url-newmaint;" name="L'angolo del nuovo manutentore"> sul sito web Debian. Assicurati di avere familiarità coi passi necessari del the New Maintainer process prima di effettuare applying. Se sei ben preparato, puoi risparmiare molto tempo dopo. <sect id="mentors">Debian mentor e sponsor La mailing list &email-debian-mentors; è stata creata per novelli manutentori alla ricerca di aiuto sulla pacchettizzazione iniziale ed altri problemi da sviluppatore. Ogni nuovo sviluppatore è invitato ad iscriversi a questa lista (vedi <ref id="mailing-lists"> per i dettagli). Quelli che preferiscono aiuto uno-ad-uno (via email private) dovrebbero scrivere a questa lista ed uno sviluppatore esperto potrebbe offrire il suo aiuto. Inoltre, se hai dei pacchetti pronti per l'inclusione in Debian, ma stai aspettando di finire la tua new maintainer application potresti riuscire a trovare degli sponsor che effettuino l'upload dei pacchetti per te. Gli sponsor sono persone che sono manutentori Debian ufficiali e che are willing to criticize ed effettuare l'upload dei pacchetti per te. Coloro i quali cerchino uno sponsor possono richiederne uno a <url id="&url-sponsors;">. Se vuoi essere un mentor e/o uno sponsor, ulteriori informazioni sono disponibili in <ref id="newmaint">. <chapt id="developer-duties">Compiti dello sviluppatore Debian <sect id="user-maint">Aggiornare le tue informazioni in Debian Esiste un database LDAP contenente informazioni sugli sviluppatori Debian all'indirizzo <url id="&url-debian-db;">. Qui dovresti inserire le tue informazioni aggiornarle non appena cambiano. La cosa piu' importante è di assicurarsi che l'indirizzo dove la tua email debian.org viene inoltrata sia sempre aggiornato, così come l'indirizzo dove impostare la tua sottoscrizione a debian-private, se decidi di iscriverti. Per ulteriori informazioni circa il database, visitare <ref id="devel-db">. <sect id="key-maint">Mantenere la tua chiave privata Sii molto accorto con le tue chiavi private. Non metterle in nessun server pubblico o macchine multi-utente, come ad esempio i server Debian (leggi <ref id="server-machines">). Fai una copia delle tue chiavi; tienine una copia offline. Leggi la documentazione fornita insieme al software, leggi le <url id="&url-pgp-faq;" name="PGP FAQ">. Se aggiungi firme alla tua chiave pubblica, o aggiungi altre identità, puoi aggiornare il server Debian mandando la chiave al server <tt> &keyserver-host;</tt> Se hai bisogno di aggiungere una chiave completamente nuova, o di rimuoverne una vecchia, manda una e-mail a &email-debian-keyring;. Si applicano le stesse procedure di estrazione chiavi discusse in <ref id="registering">. Puoi trovare una discussione dettagliata sulla manutenzione delle chiavi Debian nella documentazione del pacchetto <package> debian-keyring</package>. <sect id="voting">Votare Anche se Debian non è realmente una democrazia, noi usiamo un procedimento democratico per eleggere i nostri leaders e per approvare risoluzioni generali. Questi procedimenti sono definiti dalla <url id="&url-constitution;" name="Costituzione Debian">. A parte l'elezione annuale del leader, le votazioni non sono sistematiche, e non sono svolte alla leggera. Ogni proposta e' prima discussa sulla mailing list &email-debian-vote; e richiede svariate approvazioni prima che il segretario del progetto dia l'inizio alla procedura di voto. Non sei obbligato a seguire le discussioni pre-voto, il segretario annuncerà le votazioni diverse volte su &email-debian-devel-announce; (tutti gli sviluppatori dovrebbero essere iscritti a tale lista). La democrazia non funziona bene se le persone non prendono parte al voto, è per questo che incoraggiamo tutti gli sviluppatori a votare. Il voto è condotto attraverso messaggi e-mail criptati e firmati con GPG. La lista di tuttte le proposte (passate e presenti) è disponibile sulla pagina di <url id="&url-vote;" name="Informazioni sulle votazioni Debian">, insieme alle informazioni su come fare, sostenere e votare proposte. <sect id="inform-vacation">Andare in vacanza È comune per gli sviluppatori avere periodi di assenza, sia che siano vacanze pianificate o semplicemente essere oberati dal lavoro. La cosa importante da capire è che gli altri sviluppatori hanno bisogno di sapere se sei in vacanza in modo che possano fare ciò che devono se accade un problema con i tuoi pacchetti o altri compiti nel progetto. Solitamente ciò significa che altri sviluppatori sono autorizzati a fare un NMU (vedi <ref id="nmu">) del tuo pacchetto se un grosso problema (bug release-critical, aggiornamenti di sicurezza, ecc.) salta fuori mentre sei via. A volte non è niente di così grave, ma è comunque appropriato far sapere agli altri se sei indisponibile. Per informare gli altri sviluppatori, ci sono due cose che dovresti fare. Per prima cosa manda una e-mail a &email-debian-private; mettendo "[VAC] " all'inizio del subject del messaggio<footnote>Questo in modo che chi non volesse leggere tali messaggi possa filtrarli facilmente.</footnote> indicando il periodo in cui non sarai raggiungibile. Puoi anche dare istruzioni speciali su cosa fare se succede un problema. L'altra cosa da fare è quella di marcarti "in vacanza" nel <qref id="devel-db">database LDAP degli sviluppatori Debian</qref> (questa informazione è accessibile soltanto dagli sviluppatori Debian). Non dimenticarti di togliere la flag "in vacanza" quando torni! <sect id="upstream-coordination">Cooperazione con gli sviluppatori upstream Una grossa parte del tuo lavoro come mantainer Debian sarà di stare in contatto con gli sviluppatori upstream. Gli utenti Debian a volte segnaleranno dei bug non specifici di Debian al nostro sistema di tracciamento dei bug. Devi inoltrare queste segnalazioni di bug agli sviluppatori upstream in modo che possano essere risolti in un futuro rilascio upstream. Anche se non è il tuo lavoro risolvere bug non specifici Debian, puoi liberamente farlo se ne sei capace. Quando lo fai, assicurati di mandare la patch anche agli sviluppatori upstream. Gli utenti e sviluppatori Debian a volte manderanno delle patch che risolvono bug upstream -- dovresti valutare e nel caso mandare tali patch agli sviluppatori upstream. Se devi modificare i sorgenti originali per far sì che il pacchetto sia conforme ai requisiti della politica Debian, dovresti proporre tali modifiche agli sviluppatori upstream in modo che quando rilasceranno una nuova versione, tu non dovrai modificarne i sorgenti. Qualunque modifica tu debba fare, cerca sempre di non separarti dai sorgenti upstream. <sect id="rc-bugs">Gestire i bug release-critical Generalmente dovresti gestire le segnalazioni di bug sui tuoi pacchetti come descritto nella sezione <ref id="bug-handling">. Nonostante ciò, esiste una speciale categoria di bug di cui devi prenderti cura -- i cosiddetti release-critical bugs (RC bugs). Tutti le segnalazioni di bug con severità critica, grave o seria hanno un impatto sulla possibilità che il pacchetto venga incluso nel prossimo rilascio stabile di Debian. Questi bug possono ritardare il rilascio e/o giustificarne la rimozione durante il periodo di "freeze". Ecco perchè questi bug devono essere chiusi prima possibile. Gli sviluppatori che fanno parte del gruppo di <url id="&url-debian-qa;" name="Assicurazione Qualità"> seguono tutti quei bug e tentano ad aiutare quando possibile. Se per qualche ragione non riesci a risolvere un bug RC in un tuo pacchetto entro 2 settimane, dovresti o chiedere aiuto mandando una e-mail al gruppo di Assicurazione Qualità (QA) &email-debian-qa; oppure spiegare le tue difficoltà e presentare un piano per risolverle mandando una e-mail alla segnalazione del bug. Altrimenti, qualcuno del gruppo QA potrebbe avere intenzione di effettuare un Non-Mantainer Upload (vedi <ref id="nmu">) dopo aver provato a contattarti (potrebbero non aspettare tanto quanto fanno di solito prima di fare il loro NMU se non vedono nessuna tua recente attività nel BTS). <sect>Ritirarsi Se scegli di abbandonare il progetto Debian, dovresti assicurarti di compiere i seguenti passaggi: <enumlist> <item> Abbandonare tutti i tuoi pacchetti, come descritto in <ref id="orphaning">. <item> Mandare una e-mail spiegando perchè lasci il progetto a &email-debian-private;. <item> Fare sapere a chi mantiene le chiavi Debian (&email-debian-keyring;)che lasci il progetto. </enumlist> <chapt id="resources">Risorse per gli sviluppatori Debian In questo capitolo troverai una road map molto concisa delle mailing list Debian, le macchine Debian che potrebbero essere disponibili per te come sviluppatore e tutte le altre risorse che sono disponibili per aiutarti nel tuo lavoro di mantainer. <sect id="mailing-lists">Mailing list Gran parte delle conversazioni tra sviluppatori (e utenti) Debian sono gestite attraverso un grande numero di mailing list che ospitiamo all'indirizzo <tt><url id="http://&lists-host;/" name="&lists-host;"></tt>. Per ulteriori informazioni su come sottoscriversi o togliersi, come postare e come non postare, dove trovare i vecchi post e come cercarli, come contattare i mantainer delle liste e vedere varie altre informazioni circa le mailing list, per favore vedi <url id="&url-debian-lists;">. Questa sezione coprirà solo gli aspetti delle mailing list che sono di particolare interesse per gli sviluppatori. <sect1 id="mailing-lists-rules">Regole di base Quando rispondi ai messaggi sulla mailing list, per favore non mandare una copia carbone (<tt>CC</tt>) al mittente originario a meno che non lo richiedano esplicitamente. Chiunque mandi un messaggio a una mailing list dovrebbe leggerla per vedere le risposte. Il cross-posting (mandare lo stesso messaggio a più liste) è sconsigliato. Come sulla rete, per favore minimizza il quoting degli articoli a cui stai rispondendo. In generale, per favore rispetta le convenzioni usuali per mandare messaggi. Per favore leggi il <url name="codice di condotta" id="&url-debian-lists;#codeofconduct"> per ulteriori informazioni. <sect1 id="core-devel-mailing-lists">Core development mailing lists  Le mailing list Debian di base che gli sviluppatori dovrebbero usare sono: <list> <item>&email-debian-devel-announce;, usata per annunciare cose importanti agli sviluppatori. Ci si aspetta che tutti gli sviluppatori siano iscritti a questa lista. </item> <item>&email-debian-devel;, usata per discussioni tecniche riguardanti lo sviluppo. </item> <item>&email-debian-policy;, dove la policy Debian viene discussa e votata. </item> <item>&email-debian-project;, usate per discutere questioni non tecniche riguardanti il progetto. </item> </list> Sono disponibili altre mailing list per una varietà di argomenti speciali, vedi <url id="http://&lists-host;/"> per una lista. <sect1 id="mailing-lists-special">Liste speciali &email-debian-private; è una mailing list speciale per discussioni private tra gli sviluppatori Debian. È intesa per essere usata per post che per qualunque ragione non dovrebbero essere apertamente pubblicati. Per questo, è una lista a basso traffico, e gli utenti sono pregati di non usare &email-debian-private; a meno che non sia assolutamente necessario. Inoltre, non inoltrare email da questa lista a nessuno. Gli archivi di questa lista non sono disponibili sul web per ovvie ragioni, ma puoi consultarli usando il tuo account di shell su <tt>lists.debian.org</tt> e guardando nella directory <file>~debian/archive/debian-private</file>. &email-debian-email; è una mailing list speciale usata per conservare la corrispondenza legata a Debian, come quando si contattano gli autori upstream circa licenze, bug, ecc. o si discute il progetto con altre persone dove potrebbe essere utile avere la discussione archiviata da qualche parte. <sect1 id="mailing-lists-new">Richiedere nuove liste relative allo sviluppo. Prima di richiedere una mailing list correlata allo sviluppo di un pacchetto (o un piccolo gruppo di pacchetti tra loro correlati), per favore considera se sia più appropriato usare un alias (via un file .forward-aliasname su master.debian.org, che si traduce in un ragionevole indirizzo <var>you-aliasname@debian.org</var>) o una mailing list autogestita su <qref id="alioth">Alioth</qref>. Se decidi che una mailing list regolare su lists.debian.org è realmente quello che vuoi, vai avanti e compila una richiesta, seguendo <url name="l'HOWTO" id="&url-debian-lists-new;">. <sect id="irc-channels">Canali IRC Diversi canali IRC sono dedicati allo sviluppo di Debian. Sono principalmente ospitati sulla rete <url id="&url-openprojects;" name="freenode"> (precedentemente nota come Open Projects Network). La voce di DNS <tt>irc.debian.org</tt>è un alias di <tt>irc.freenode.net</tt>. Il canale principale per Debian in generale è #debian. Questo è un grosso canale "general-purpose" dove gli utenti possono trovare notizie recenti nel topic e servite dai bot. #debian è per gli utenti che parlano inglese; ci sono anche #debian.de, #debian-fr, #debian-br e altri canali chiamati in modo simile per gli utenti che parlano altre lingue. Il canale principale per lo sviluppo di Debian è #debian-devel. È un canale molto attivo in quanto di solito ci sono sempre oltre 150 persone loggate. È un canale per persone che lavorano su Debian, non è un canale di supporto (esiste #debian per quello). È comunque aperto a chiunque voglia leggere (e imparare). Il suo topic è comunemente pieno di informazioni interessanti per gli sviluppatori. Siccome #debian-devel è un canale aperto, non dovresti parlare qui di questioni che sono discusse in &email-debian-private;. Esiste un altro canale per questo scopo, è chiamato #debian-private ed è protetto da una chiave. La chiave è disponibile negli archivi di debian-private in <file>master.debian.org:&file-debian-private-archive;</file>, usa sempilcemente <prgn>zgrep</prgn> cercando #debian-private in tutti i file. Ci sono altri canali addizionali dedicati ad argomenti specifici. #debian-bugs è usato per coordinare i bug squash party. #debian-boot è usato per coordinare il lavoro sui floppy di boot (ovvero l'installer). #debian-doc è usato occasionalmente per parlare circa la documentazione, come il documento che stai leggendo. Altri canali sono dedicati a un'architettura o un set di pacchetti: #debian-bsd, #debian-kde, #debian-jr, #debian-edu, #debian-sf (pacchetto SourceForge), #debian-oo (pacchetto OpenOffice) ... Esistono anche qualche canale di sviluppatori non in Inglese, per esempio #debian-devel-fr per le persone che parlano Francese interessate allo sviluppo di Debian. Esistono canali dedicati a Debian anche su altri network IRC, in particolare sul network IRC <url name="Open and free technology community (OFTC)" id="http://www.oftc.net/">. <sect id="doc-rsrcs">Documentazione Questo documento contiene molte informazioni molto utili agli sviluppatori Debian, ma non può contenere tutto. Per la maggior parte degli altri documenti interessanti è presente il link dall'<url id="&url-devel-docs;" name="Angolo degli sviluppatori">. Prenditi il tempo di consultare tutti i collegamenti, imparerai molte più cose. <sect id="server-machines">Macchine Debian Debian possiede diversi computer che fungono da server, la maggior parte dei quali hanno funzioni critiche nel pregetto Debian. La maggior parte delle macchine sono usate per attività di porting, e hanno tutte una connessione permanente a Internet. La maggior parte delle macchine sono disponibili per essere usate dagli sviluppatori, finchè si attengano alle regole imposte nella <url name="Policy di utilizzo delle macchine Debian" id="&url-dmup;">. In generale, puoi usare queste macchine a tua discrezione per scopi correlati a Debian. Per favore sii cortese con gli amministratori di sistema, e non usare tonnellate di spazio disco, banda o CPU senza aver ottenuto prima l'approvazione degli amministratori di sistema. Di solito queste macchine sono gestite da volontari. PEr favore fai attenzione a proteggere le tue password Debian e le chiavi SSH installate su macchine Debian. Evita metodi di login o di upload che mandano le password su Internet in chiaro, come telnet, FTP, POP ecc. Per favore non mettere nessun materiale non correlato a Debian sui server Debian, a meno che tu non ne abbia il permesso. La lista aggiornata delle macchine Debian è disponibile all'indirizzo <url id="&url-devel-machines;">. Quella pagina web contiene i nomi delle macchine, informazioni sui contatti, informazioni su chi può entrarci, le chiavi SSH ecc. Se hai un problema con il funzionamento di un server Debian, e pensi che gli operatori di sistema debbano esserne informati, il team degli amministratori di sistema Debian è raggiungibile a <email>debian-admin@lists.debian.org</email>. Se hai un problema con un certo servizio non correlato all'amministrazione di sistema (come pacchetti da rimuovere dall'archivio, suggerimenti per il sito web, ecc.), generalmente riporterai un bug su uno ``pseudo-pacchetto''. Vedi <ref id="submit-bug"> per informazioni su come riportare i bug. <sect1 id="servers-bugs">Il server bugs <tt>&bugs-host;</tt> è la locazione canonica del sistema di tracciamento dei bug (BTS). Se stai pianificando di fare qualche analisi statistica o di processare i bug Debian, questo sarebbe il posto per farlo. Per favore esplica le tue intenzioni su &email-debian-devel; prima di implementare qualsiasi cosa, comunque, per non duplicare inutilmente gli sforzi o sprecare del tempo. Tutti gli sviluppatori Debian hanno un account su <tt>&bugs-host;</tt>. <sect1 id="servers-ftp-master">Il server ftp-master Il server <tt>ftp-master.debian.org</tt> mantiene la canonica copia dell'archivio Debian (a parte i pacchetti non-US). Generalmente, gli upload di pacchetti vanno su questo server; vedi <ref id="upload">. I problemi con l'archivio FTP Debian devono generalmente essere riportati come bug sullo pseudo-pacchetto <package>ftp.debian.org</package> o un'email a &email-ftpmaster;, ma vedi anche le procedure in <ref id="archive-manip">. <sect1 id="servers-non-us">Il server non-US Il server non-US, <tt>non-us.debian.org</tt>, mantiene la canonica copia della parte non-US dell'archivio Debian. Se devi effettuare l'upload di un pacchetto in una delle sezioni non-US, fallo su questo server; vedi <ref id="upload-non-us">. I problemi con l'archivio dei pacchetti non-US generalmente dovrebbero essere riportati come bug sullo pseudo-pacchetto <package>nonus.debian.org</package> (nota la mancanza del trattino tra "non" e "us" nel nome dello pseudo-pacchetto — questo per compatibilità all'indietro). Ricorda di controllare se qualcun'altro abbia o meno già riportato il problema sul <url id="http://&bugs-host;/nonus.debian.org" name="sistema di tracciamento dei bug">. <sect1 id="servers-www">Il server www-master Il server web principale è <tt>www-master.debian.org</tt>. Tiene le pagine web ufficiali, la facciata di Debian per molti newbie. Se scovi un problema nel server web Debian, generalmente dovresti riportare un bug contro lo pseudo-pacchetto <package>www.debian.org</package>. Ricorda di controllare se qualcun'altro abbia o meno già riportato il problema sul <url id="http://&bugs-host;/www.debian.org" name="sistema di tracciamento dei bug">. <sect1 id="servers-people">Il server web people <tt>people.debian.org</tt> è il server usato per le pagine web personali degli sviluppatori su qualunque cosa correlata a Debian. Se hai delle informazioni su Debian che vuoi mettere a disposizione sul web, puoi farlo mettendo il materiale nella directory <file>public_html</file> sotto la tua home directory su <tt>people.debian.org</tt>, che sarà quindi disponibile all'indirizzo <tt>http://people.debian.org/~<var>your-user-id</var>/</tt>. Dovresti usare questa particolare locazione solo perchè ne verranno fatte delle copie di backup, mentre in altri host no. Di solito l'unica ragione per cui potresti voler usare un host diverso è quando hai bisogno di pubblicare materiale soggetto alle restrizioni di esportazione degli U.S.A., in qual caso puoi usare uno degli altri server situati fuori dagli Stati Uniti, come il già menzionato <tt>non-us.debian.org</tt>. Se hai qualche domanda manda un'email a &email-debian-devel;. <sect1 id="servers-cvs">Il server CVS Il nostro server CVS è situato su <tt>cvs.debian.org</tt>. Se hai bisogno di usare un server CVS che sia pubblicamente accessibile, per esempio, per aiutarti a coordinare il lavoro su un pacchetto tra molti sviluppatori diversi, puoi richiedere un'area CVS sul server. Generalmente, <tt>cvs.debian.org</tt> offre una combinazione di accesso CVS locale, accesso client-server anonimo a sola lettura e pieno accesso client-server attraverso <prgn>ssh</prgn>. Inoltre, si può accedere all'area CVS in sola lettura via web all'indirizzo <url id="&url-cvsweb;">. Per richiedere un'area CVS, manda una richiesta via email a &email-debian-admin;. Includi nella richiesta il nome dell'area CVS richiesta, l'account Debian che dovrebbe detenere la root dell'area CVS e perchè ne hai bisogno. <sect id="devel-db">Il database degli sviluppatori Il database degli sviluppatori, all'indirizzo <url id="&url-debian-db;">, è una directory LDAP per gestire gli attributi degli sviluppatori Debian. Puoi usare questa risorsa per cercare la lista degli sviluppatori Debian. Una parte di queste informazioni è accessibile attraverso il servizio finger sui server Debian, prova <prgn>finger yourlogin@db.debian.org</prgn> per vedere che cosa riporta. Gli sviluppatori possono <url name="effettuare il login nel database" id="&url-debian-db-login;"> per cambiare diverse informazioni su di loro, come: <list> <item>indirizzo di inoltro per la tua email debian.org <item>iscrizione a debian-private <item>se sei assente <item>informazioni personali come il tuo indirizzo, nazione, latitudine e longitudine del posto dove vivi per usarli nella <url name="mappa mondiale degli sviluppatori Debian" id="&url-worldmap;">, numero di telefono e di fax, nickname IRC e pagina web. <item>password e shell preferita sulle macchine del progetto Debian </list> Naturalmente, la maggior parte delle informazioni non sono accessibili al pubblico. Per ulteriori informazioni per favore leggi la documentazione online che puoi trovare all'indirizzo <url id="&url-debian-db-doc;">. Uno può anche inviare le sue chiavi SSH perchè siano usate per l'autenticazione sulle macchine ufficiali Debian, e persino aggiungere nuove voci DNS *.debian.net. Queste funzionalità sono documentate all'indirizzo <url id="&url-debian-db-mail-gw;">. <sect id="archive">L'archivio Debian La distribuzione &debian-formal; contiene un grande numero di pacchetti (<file>.deb</file>, correntemente sono circa &number-of-pkgs;) e pochi altri file aggiuntivi (come la documentazione e le immagini dei dischi di installazione). Ecco un albero di directory di esempio di un archivio Debian completo: &sample-dist-dirtree; Come puoi vedere, la directory di più alto livello contiene due directory,<file>dists/</file> e <file>pool/</file>. L'ultima è una “pool” nella quale i pacchetti ci sono veramente, e che è gestita dal database di manutenzione dell'archivio e i relativi programmi. La prima contiene le distribuzioni, stable, testing e unstable. I file <file>Packages</file> e <file>Sources</file> nelle sottodirectory delle distribuzioni possono referenziare file nella directory <file>pool/</file>. L'albero delle directory sotto ognuna delle distribuzioni è arrangiato in maniera identica agli altri. Ciò che sotto descriviamo per stable è ugualmente applicabile alle distribuzioni unstable e testing. <file>dists/stable</file> contiene tre directory, chiamate <file>main</file>, <file>contrib</file> e <file>non-free</file>. In ciascuna di queste aree c'è una directory per i pacchetti sorgente (<file>source</file>) e una directory per ogni architettura supportata (<file>binary-i386</file>, <file>binary-m68k</file>, ecc.). L'area <file>main</file> contiene delle directory addizionali che tengono le immagini disco e frammenti essenziali di documentazione richiesti per installare la distribuzione Debian su una specifica architettura (<file>disks-i386</file>, <file>disks-m68k</file>, ecc.). <sect1 id="archive-sections">Sezioni La sezione main dell'archivio Debian è quella che forma la ditribuzione &debian-formal; ufficiale. La sezione main è ufficiale perchè è pienamente conforme a tutte le linee guida. Le altre sezioni no, con gradualità diverse; perciò non fanno ufficialmente parte di &debian-formal;. Ogni pacchetto nella sezione main deve essere pienamente conforme alle <url id="&url-dfsg;" name="Linee guida Debian sul software libero"> (DFSG)e a tutti gli altri requisiti della policy come descritto nella <url id="&url-debian-policy;" name="Policy Debian">. Le DFSG sono la nostra definizione di “software libero.” controlla la policy Debian per i dettagli. I pacchetti nella sezione contrib devono conformarsi alle DFSG, ma possono non soddisfare altri requisiti. Per esempio, possono dipendere da pacchetti non-free. I pacchetti che non sono conformi alla DFSG sono posti nella sezione non-free. Questi pacchetti non sono considerati parte della distribuzione Debian, anche se diamo supporto per l'utilizzo e forniamo infrastrutture (come il nostro sistema di tracciamento dei bug e mailing list) per i pacchetti di software non-free. La <url id="&url-debian-policy;" name="Policy Debian"> contiene una definizione più esatta delle tre sezioni. La discussione soprastante è solo un'introduzione. La separazione delle tre sezioni al livello più alto dell'archivio è importante per chiunque abbia intenzione di distribuire Debian, sia attraverso server FTP su internet sia su CD-ROM: distribuendo solo le sezioni main e contrib, uno può evitare qualunque rischio di tipo legale. Alcuni pacchetti nella sezione non-free non ammettono per esempio la distibuzione commerciale. D'altra parte, un commerciante di CD-ROM  potrebbe facilmente controllare le licenze di ogni singolo pacchetto in non-free e includere tutti quelli che può nel CD-ROM. (Siccome questo varia enormemente da un commerciante all'altro, questo lavoro non può essere svolto dagli sviluppatori Debian.) Nota anche che il termine "sezione" è usato anche per riferirsi alle categorie che simplificano l'organizzazione e la consultazione dei pacchetti disponibili, p. es. admin, net, utils ecc. Una volta queste sezioni (più che altro sottosezioni) esistevano nella forma di sottodirectory nell'archivio Debian. Oggi queste esistono solo nel campo "Section" degli header dei pacchetti. <sect1>Architetture Nei primi tempi, il kernel Linux era disponibile solo per le piattaforme Intel i386 (o maggiori), e così anche Debian. Ma quando Linux divenne sempre più popolare, il kernel fu portato anche su altre architetture. Il kernel Linux 2.0 supporta Intel x86, DEC Alpha, SPARC, Motorola 680x0 (come Atari, Amiga e i Macintosh), MIPS, e PowerPC. Il kernel Linux 2.2 supporta ancora più architetture, incluse ARM e UltraSPARC. Siccome Linux supporta quelle piattaforme, Debian decise che anch'essa avrebbe dovuto farlo. Quindi, Debian sta sviluppando dei porting; in effetti, abbiamo anche in preparazione port per kernel non Linux.  A parte i386 (il nostro nome per Intel x86), ci sono m68k, alpha, powerpc, sparc, hurd-i386, arm, ia64, hppa, s390, mips, mipsel e sh al tempo di questo documento. &debian-formal; 1.3 è disponibile solo per i386. Debian 2.0 uscì per architetture i386 e m68k. Debian 2.1 supporta architetture i386, m68k, alpha, e sparc. Debian 2.2 aggiunse il supporto per architetture powerpc e arm. Debian 3.0 aggiunge il supporto a cinque nuove architetture: ia64, hppa, s390, mips and mipsel. Informazioni per sviluppatori e utenti circa specifici port sono disponibili nelle <url id="&url-debian-ports;" name="pagine web dei port Debian">. <sect1>Pacchetti Ci sono due tipi di pacchetti Debian, nominalmente pacchetti sorgenti e binari. I pacchetti sorgenti consistono di due o tre file: un file <file>.dsc</file>e o un file <file>.tar.gz</file> o sia un <file>.orig.tar.gz</file> che un file <file>.diff.gz</file>. Se un pacchetto è sviluppato specialmente per Debian e non è distribuito al di fuori di Debian, c'è solo un file <file>.tar.gz</file> che contiene i sorgenti del programma. Se un pacchetto è distribuito anche altrove, il file <file>.orig.tar.gz</file> contiene il cosiddetto codice sorgente upstream, che è il codice sorgente che è distribuito dal mantainer upstream (spesso l'autore del software). In questo caso, il <file>.diff.gz</file> contiene le modifiche effettuate dal mantainer Debian. Il file <file>.dsc</file> elenca tutti i file nel pacchetto sorgente insieme ai checksum (<prgn>md5sums</prgn>) e qualche informazione addizionale sul pacchetto (mantainer, versione, ecc.). <sect1>Distribuzioni Il sistema di directory descritto nel capitolo precedente è a sua volta contenuto nelle directory delle distribuzioni. Ogni distribuzione è in realtà contenuta nella directory <file>pool</file> al livello più alto dello stesso archivio Debian. Per riepilogare, l'archivio Debian ha una directory di root in un server FTP. Per esempio, nel sito mirror <ftpsite>ftp.us.debian.org</ftpsite>, l'archivio Debian stesso è contenuto in <ftppath>/debian</ftppath>, che è una locazione comune (un altra è <file>/pub/debian</file>). Una distribuzione comprende pacchetti Debian sorgenti e binari e i rispettivi file indice <file>Sources</file> e <file>Packages</file>, contenenti le informazioni degli header da tutti quei pacchetti. I primi sono contenuti nella directory <file>pool/</file>, mentre i secondi sono contenuti nella directory <file>dists/</file> dell'archivio (per compatibilità all'indietro). <sect2 id="sec-dists">Stable, testing e unstable Ci sono sempre distribuzioni chiamate stable (residente in <file>dists/stable</file>), una chianata testing (residente in <file>dists/testing</file>) e una chiamata unstable (residente in <file>dists/unstable</file>). Questo riflette il processo di sviluppo del progetto Debian. Lo sviluppo attivo viene fatto nella distrubuzione unstable (ecco perchè questa distribuzione viene a volte chiamata la distribuzione di sviluppo). Ogni sviluppatore Debian può aggiornare i suoi pacchetti in questa distribuzione in qualsiasi momento. Di conseguenza, i contenuti di questa distribuzione cambiano giornalmente. Siccome non viene fatto alcuno sforzo speciale per assicurarsi che tutto funzioni propriamente in questa distribuzione, a volte è letteralmente instabile. <qref id="testing">"testing"</qref> è generata automaticamente prendendo i pacchetti da unstable se questi soddisfano certi criteri. Questi criteri dovrebbero assicurare una buona qualità per i pacchetti in testing. L'aggiornamento a testing è lanciato ogni giorno dopo che i nuovi pacchetti vengano installati. Vedi <ref id="testing">. Dopo un periodo di sviluppo, una volta che il release manager lo ritiene opportuno, la distribuzione testing viene "congelata", il che significa che le regole che controllano come i pacchetti sono spostati da unstable a testing vengono ristrette. I pacchetti troppo bacati sono rimossi. Nessun cambiamento è ammesso in testing a eccezione dei fix dei bug. Dopo che è passato un po' di tempo, dipendentemente dai progressi, la distribuzione testing va in uno stato di `deep freeze', durante il quale non viene fatta alcuna modifica su di essa a eccezione di quelle necessarie per il sistema di installazione. Questo è chiamato un “ciclo di test”, e può durare fino a due settimane. Ci possono essere diversi cicli di test, finchè la distribuzione è pronta per il rilascio, come deciso dal release manager. Alla fine dell'ultimo ciclo di test, la distribuzione testing è rinominata stable, rimpiazzando la vecchia distribuzione stable, che a quel punto viene rimossa (anche se può essere sempre trovata all'indirizzo <tt>&archive-host;</tt>). Questo ciclo di sviluppo è basato sulla supposizione che la distribuzione unstable diventa stable dopo che è passata un periodo di tempo in testing. Persino una volta che una distribuzione viene considerata stabile, inevitabilmente rimangono ancora dei bug — ecco perchè la distribuzione stable viene ogni tanto aggiornata. Comunque, questi aggiornamenti sono controllati molto attentamente e devono essere introdotti nell'archivio individualmente, per ridurre il rischio di introdurre nuovi bug. Puoi trovare le aggiunte proposte per stable nella directory <file>proposed-updates</file>. Questi pacchetti in <file>proposed-updates</file> che passano l'ispezione sono periodicamente spostati  in blocco nella distribuzione stable e il suo livello di revisione viene incrementato (p.es., ‘3.0’ diventa ‘3.0r1’, ‘2.2r4’ diventa ‘2.2r5’, e così via). Nota che lo sviluppo sotto unstable continua anche durante il periodo di "freeze", siccome la distribuzione unstable rimane al suo posto in parallelo con testing. <sect2 id="testing"> <heading>Ulteriori informazioni sulla distribuzione testing</heading> Gli script che aggiornano la distribuzione testing vengono lanciati ogni giorno dopo l'installazione dei pacchetti aggiornati. Generano i file <file>Packages</file> per la distribuzione testing, ma lo fanno in modo intelligente cercando di evitare qualsiasi inconsistenza e cercando di usare solo pacchetti non bacati. L'inclusione di un paccchetto da unstable è soggetta alle seguenti condizioni: <list> <item> Il pacchetto deve essere stato disponibile in unstable per diversi giorni; il numero preciso dipende dal campo "urgency" dell'upload. È 10 giorni per urgenza bassa, 5 giorni per urgenza media e 2 giorni per urgenza elevata.  Questi periodi possono essere raddoppiati durante un freeze. <item> Deve avere meno bug release-critical rispetto alla versione disponibile in testing; <item> Deve essere disponibile per tutte le architetture per cui è stato precedentemente fatto il build. <ref id="madison"> può essere interessante per controllare quell'informazione. <item> Non deve infrangere alcuna dipendenza di un pacchetto che è già disponibile in testing; <item> I pacchetti sui quali dipende devono o essere disponibili in testing o essere accettati in testing contemporaneamente (e lo saranno se rispettano tutti i criteri necessari); </list> Per scoprire se un pacchetto stia o meno progredendo in testing vedi l'output dello script di testing sulla <url name="pagina web della distribuzione testing" id="&url-testing-maint;">, oppure usa il programma <prgn>grep-excuses</prgn> che è nel pacchetto <package>devscripts</package>. Questa utility può essere facilmente usata in un <manref name="crontab" section="5"> per tenere le persone informate sul progresso dei loro pacchetti in testing. Il file <file>update_excuses</file> non fornisce sempre la ragione precisa per la quale il pacchetto è stato rifiutato, uno può dovere trovarla per proprio conto cercando cosa potrebbe impedire l'inclusione del pacchetto. La <url id="&url-testing-maint;" name="pagina web testing"> fornisce qualche altra informazione circa i problemi comuni che possono causare guai simili. A volte qualche pacchetto non entra mai in testing perchè l'insieme delle inter-dipendenze è troppo complicato e non può essere risolto dagli script. In quel caso si deve contattare il release manager che forzerà l'inclusione dei pacchetti. In generale, per favore riferisciti alla <url name="pagina web testing" id="&url-testing-maint;"> per ulteriori informazioni. Include anche risposte a qualcuna delle domande poste più di frequente. <sect2 id="experimental">Experimental La distribuzione experimental è una distribuzione speciale. Non è una distribuzione completa nello senso in cui lo sono `stable' e `unstable'. È invece intesa ad essere un area di stasi temporanea per software altamente sperimentale dove c'è una buona possibilità che il software possa infrangere il tuo sistema, o software che è semplicemente troppo instabile persino per la distribuzione unstable (ma nonostante ciò esiste una ragione per farne un pacchetto). Gli utenti che scaricano e installano pacchetti da experimental ci si aspetta che siano stati debitamente avvisati. In breve, dalla distribuzione experimental non ci si può aspettare nulla.  Queste sono le linee di <manref name="sources.list" section="5"> per experimental: <example> deb http://ftp.<var>xy</var>.debian.org/debian/ ../project/experimental main deb-src http://ftp.<var>xy</var>.debian.org/debian/ ../project/experimental main </example> Se esiste una possibilità che il software possa fare gravi danni a un sistema, è altamente probabile che sia meglio metterlo in experimental. Per esempio, un file system compresso sperimentale dovrebbe probabilmente andare in experimental. Ogni volta che c'è una nuova versione upstream di un pacchetto che introduce nuove features ma ne infrange un gran numero di vecchie, o non si dovrebbe farne l'upload o si dovrebbe farlo in experimental. Una nuova versione beta di qualche software che usa una configurazione completamente differenrte può andare in experimental, a discrezione del mantainer. Se stai lavorando su una situazione in cui l'aggiornamento è incompatibile o complesso puoi anche usare experimental come un'area di stasi, in modo che i tester possano ottenerne un accesso rapido. Qualche software sperimentale può lo stesso andare in unstable, con qualche avviso nella descrizione, ma non è raccomandato in quanto i pacchetti da unstable ci si aspetta che si propaghino in testing e quindi in stable. Non dovresti temere di usare experimental siccome non causa alcun dolore agli ftpmaster, i pacchetti in experimental vengono rimossi automaticamente una volta che effettui l'upload del pacchetto in unstable con un numero di versione più alto. Nuovi software che probabilmente non danneggeranno il tuo sistema possono andare direttamente in unstable. Un alternativa a experimental è di usare il tuo spazio web personale su <tt>people.debian.org</tt>. <sect1 id="codenames">Nomi in codice delle release Ogni release di una distribuzione Debian ha un nome in codice: Debian 1.1 è chiamata `buzz'; Debian 1.2, `rex'; Debian 1.3, `bo'; Debian 2.0, `hamm'; Debian 2.1, `slink'; Debian 2.2, `potato'; e Debian 3.0, `woody'. C'è anche una ``pseudo-distribuzione'', chiamata `sid', che è la corrente distribuzione `unstable'; siccome i pacchetti vengono spostati da `unstable' a `testing' come si avvicinano a una condizione di stabilità, `sid' stessa non viene mai rilasciata. Così come i soliti contenuti di una distibuzione Debian, `sid' contiene pacchetti per architetture che non sono ancora ufficialmente supportate o rilasciate da Debian. Queste architetture sono pianificate a essere integrate nella distribuzione principale in qualche data futura. Siccome Debian ha un modello di sviluppo aperto (ovvero chiunque può partecipare e seguire lo sviluppo) anche le distribuzioni `unstable' e `testing' sono distribuite su internet attraverso la rete di server FTP e HTTP Debian. Quindi, se avessimo chiamato `testing' la directory che contiene la versione candidata alla release, avremmo dovuto rinominarla `stable' quando la versione fosse stata rilasciata, la qual cosa avrebbe forzato tutti i mirror FTP a riscaricarsi l'intera distribuzione (che è abbastanza grossa). D'altro canto, se avessimo chiamato sin dall'inizio le directory delle distribuzioni Debian-x.y, La gente penserebbe che la release Debian x.y è disponibile. (Ciò è successo in passato, un venditore di CD-ROM costruì un cdrom Debian 1.0 basato su una versione di sviluppo pre-1.0. Questa è la ragione per cui la prima release ufficiale Debian fu la 1.1 e non la 1.0.) Quindi, i nomi delle directory delle distribuzioni nell'archivio sono determinate dai loro nomi in codice e non dal loro stato di release (p.es. `slink'). Questi nomi rimangono sempre gli stessi durante il periodo di sviluppo e dopo il rilascio; link simbolici, che possono essere facilmente cambiati, indicano la release corrente della distribuzione stabile. Ecco perché le directory reali delle distribuzioni usano i nomi in codice, mentre link simbolici per stable, testing, e unstable puntano alle directory appropriate delle distribuzioni. <sect id="mirrors">Mirror Debian I vari archivi per i download e il sito web hanno diversi mirror disponibili in modo da non sottoporre i nostri server a carichi di lavoro troppo pesanti. In effetti, alcuni nostri server non sono pubblici — al loro posto, una prima serie di mirror si bilanciano il carico. In questo modo gli utenti accedono sempre ai mirror e si abituano ad usarli, la qual cosa permette a Debian di distribuire meglio i propri requisiti di banda su diversi server e network, e di base fa in modo che gli utenti evitino di accanirsi su una locazione primaria. Nota che la prima serie di mirror è sempre aggiornata in quanto si aggiornano al comando dei siti interni (chiamiamo questa cosa "push mirroring"). Tutte le informazioni sui mirror Debian, inclusa una lista dei server FTP/HTTP pubblici disponibili, possono essere trovate all'indirizzo <url id="&url-debian-mirrors;">. Questa utile pagina include anche informazioni e strumenti che possono esserti d'aiuto se sei interessato a impostare un mirror tuo, sia per uso interno o di pubblico accesso. Nota che i mirror sono generalmente gestiti da terze parti che sono interessate ad aiutare Debian, perciò gli sviluppatori generalmente non hanno un account su quelle macchine. <sect id="incoming-system"> <heading>Il sistema incoming Il sistema incoming è responsabile di collezionare pacchetti aggiornati e installarli nell'archivio Debian. Consiste in un insieme di directory e script che sono installati sia su <tt>&ftp-master-host;</tt> sia su <tt>&non-us-host;</tt>. I pacchetti vengono inviati in upload da tutti i mantainer in una directory chiamata <file>unchecked</file>. Questa directory viene scandita ogni 15 minuti dallo script <prgn>katie</prgn>, che verifica l'integrità dei pacchetti inviati in upload e le loro firme crittografiche. Se il pacchetto viene considerato pronto per essere installato, è spostato nella directory <file>accepted</file>. Se questo è il primo upload del pacchetto, esso viene spostato nella directory <file>new</file>, dove aspetta l'approvazione dei ftpmaster. Se il pacchetto contiene file che devono essere installati a mano viene spostato nella directory <file>byhand</file>, dove aspetta l'installazione manuale da parte dei ftpmaster. Altrimenti, se viene scovato un qualsiasi errore, il pacchetto viene rifiutato e spostato nella directory <file>reject</file>. Una volta che il pacchetto viene accettato il sistema manda una mail di conferma al mantainer, chiude tutti i bug marcati come risolti dall'upload e gli auto-builder possono cominciare a ricompilarlo. Il pacchetto è ora pubblicamente accessibile all'indirizzo <url id="&url-incoming;"> (non esiste nessun URL del genere per i pacchetti nell'archivio non-US) finchè non viene realmente installato nell'archivio Debian. Questo accade solo una volta al giorno, il pacchetto viene poi rimosso da incoming e installato nella pool con tutti gli altri pacchetti. Una volta che tutti gli altri aggiornamenti (per esempio la generazione dei nuovi file indice <file>Packages</file> e <file>Sources</file>) vengono completati, viene invocato uno script speciale per chiedere a tutti i mirror primari di aggiornarsi. Il software di manutenzione dell'archivio manderà inoltre i file <file>.changes</file> firmati con OpenPGP/GnuPG che hai inviato in upload alle mailing list appropriate. Se un pacchetto viene rilasciato con <tt>Distribution:</tt> impostato a `stable', l'annuncio è inviato a &email-debian-changes;. Invece, se il pacchetto viene rilasciato con <tt>Distribution:</tt> impostato a `unstable' oppure `experimental', l'annuncio verrà inviato a &email-debian-devel-changes;. Tutti gli sviluppatori Debian hanno accesso in scrittura alla directory <file>unchecked</file> in modo da inviare in upload i loro pacchetti, hanno anche tale accesso alla directory <file>reject</file> in modo da rimuovere i loro upload non validi o per spostare qualche file di nuovo nella directory <file>unchecked</file>. Ma tutte le altre directory sono scrivibili solo dagli ftpmaster, ecco perchè non puoi rimuovere un upload una volta che è stato accettato. <sect1 id="delayed-incoming">Incoming ritardato La directory <file>unchecked</file> ha una speciale sottodirectory <file>DELAYED</file>. Essa stessa è suddivisa in nove directory chiamate da <file>1-day</file> a <file>9-day</file>. I pacchetti che vengono inviati in upload in una di queste directory verranno spostati nella directory unchecked reale dopo il corrispondente numero di giorni. Questo viene fatto da uno script che è lanciato ogni giorno e che sposta i pacchetti tra le varie directory. Quelli che sono in "1-day" sono installati in <file>unchecked</file> mentre gli altri vengono spostati nelle directory adiacenti (per esempio, un pacchetto in <file>5-day</file> sarà spostato in <file>4-day</file>). Questa feature è particolarmente utile alle persone che stanno facendo dei non-maintainer uploads. Invece che aspettare prima di fare l'upload di un NMU, è inviato in upload appena è pronto in una di quelle directory <file>DELAYED/<var>x</var>-day</file>. Questo lascia il corrispondente numero di giorni al mantainer per reagire e fare loro stessi l'upload di un altro fix se non sono completamente soddisfatti dal NMU. In alternativa possono rimuovere il NMU. L'uso della feature delayed può essere semplificato con un poco di integrazione nel tuo strumento di upload. Per esempio, se usi <prgn>dupload</prgn> (vedi <ref id="dupload">), puoi aggiungere questo pezzetto  al tuo file di configurazione: <example> $delay = ($ENV{DELAY} || 7); $cfg{'delayed'} = { fqdn => "&ftp-master-host;", login => "iltuologindebian",  incoming => "/org/ftp.debian.org/incoming/DELAYED/$delay-day/", dinstall_runs => 1, method => "scpb" }; </example> Una volta che hai fatto tale modifica, <prgn>dupload</prgn> può essere usato per effettuare facilmente l'upload di un pacchetto in una delle directory delayed: <example>DELAY=5 dupload --to delayed <changes-file></example> <sect id="pkg-info">Informazioni sui pacchetti <sect1 id="pkg-info-web">Sul web Ciascun pacchetto ha diverse pagine web dedicate. <tt>http://&packages-host;/<var>package-name</var></tt> visualizza ogni versione del pacchetto disponibile nelle varie distribuzioni. Ogni versione si collega a una pagina che fornisce informazioni, inclusa la descrizione del pacchetto, le dipendenze e i collegamenti per il download del pacchetto. Il sistema di tracciamento dei bug tiene traccia dei bug per ogni pacchetto. Puoi vedere i bug di un certo pacchetto all' indirizzo <tt>http://&bugs-host;/<var>package-name</var></tt>. <sect1 id="madison">L'utility <prgn>madison</prgn> <prgn>madison</prgn> è un'utility a linea di comando che è disponibile su entrambi <tt>&ftp-master-host;</tt> e <tt>&non-us-host;</tt>. Usa un singolo argomento corrispondente al nome di un pacchetto. Come risultato visualizza quale versione del pacchetto è disponibile per ogni combinazione di architettura e distribuzione. Un esempio lo spiegherà meglio. <example> $ madison libdbd-mysql-perl libdbd-mysql-perl | 1.2202-4 | stable | source, alpha, arm, i386, m68k, powerpc, sparc libdbd-mysql-perl | 1.2216-2 | testing | source, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc libdbd-mysql-perl | 1.2216-2.0.1 | testing | alpha libdbd-mysql-perl | 1.2219-1 | unstable | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc </example> In questo esempio, puoi vedere che la versione in unstable è diversa da quella in testing e che c'è stato un NMU solo binario del pacchetto per l'architettura alpha. Ogni volta il pacchetto è stato ricompilato sulla maggior parte delle architetture. <sect id="pkg-tracking-system">Il sistema di tracciamento dei pacchetti Il sistema di tracciamento dei pacchetti (PTS) è uno strumento basato su e-mail atto a tenere traccia dell'attività di un pacchetto sorgente. Questo significa in realtà che puoi ricevere le stesse email che riceve il mantainer, semplicemente sottoscrivendoti al pacchetto nel PTS. Ogni email inviata attraverso il PTS viene classificata con una delle parole chiave sotto elencate. Questo ti permetterà di selezionare le email che vuoi ricevere. Di default riceverai: <taglist> <tag><tt>bts</tt> <item> Tutti i bug report e le conseguenti discussioni. <tag><tt>bts-control</tt> <item> Le notifiche email da <email>control@bugs.debian.org</email> circa i cambiamenti di stato dei bug report. <tag><tt>upload-source</tt> <item> Le notifiche email da <prgn>katie</prgn> quando un upload viene accettato. <tag><tt>katie-other</tt> <item> Altre email di avvertimento ed errore da <prgn>katie</prgn> (come una disparità di override per il campo sezione e/o priorità). <tag><tt>default</tt> <item> Qualunque email non automatica inviata al PTS da persone che volevano contattare i sottoscritti al pacchetto. Questo può essere fatto inviando una mail a <tt><var>sourcepackage</var>@&pts-host;</tt>. Per prevenire lo spam, tutti i messaggi inviati a quegli indirizzi devono contenere l'header <tt>X-PTS-Approved</tt> con un valore non vuoto. <tag><tt>summary</tt> <item> (Questa è un'espansione pianificata.) Le email regolari di riepilogo circa lo stato del pacchetto (statistiche sui bug, una vista d'insieme sul porting, il progresso in testing, ...). </taglist> Puoi anche decidere di ricevere delle informazioni addizionali: <taglist> <tag><tt>upload-binary</tt> <item> La notifica email da <prgn>katie</prgn> quando viene accettato un upload di un pacchetto binario. In altre parole, ogni volta che un demone di build o un porter effettua un upload del tuo pacchetto per un'altra architettura, puoi ricevere una email per tracciare come il tuo pacchetto venga ricompilato per tutte le architetture. <tag><tt>cvs</tt> <item> Notifiche di commit CVS, se il pacchetto ha un archivio CVS e il mantainer ha impostato l'inoltro delle notifiche di commit al PTS. <tag><tt>ddtp</tt> <item> Traduzioni di descrizioni o di template di debconf inviate al progetto di traduzione delle descrizioni Debian. </taglist> <sect1 id="pts-commands">L'interfaccia email del PTS Puoi controllare le tue sottoscrizioni al PTS mandando vari comandi a <email>pts@qa.debian.org</email>. <taglist> <tag><tt>subscribe <sourcepackage> [<email>]</tt> <item> Sottoscrive <var>email</var> alle comunicazioni relative al pacchetto sorgente <var>sourcepackage</var>. Se il secondo argomento non è presente viene usato l'indirizzo del mittente. Se <var>sourcepackage</var> non è un valido pacchetto sorgente, riceverai un avvertimento. Comunque se è un pacchetto binario valido, il PTS ti sottoscriverà al pacchetto sorgente corrispondente. <tag><tt>unsubscribe <sourcepackage> [<email>]</tt> <item> Rimuove una precedente sottoscrizione al pacchetto sorgente <var>sourcepackage</var> usando l'indirizzo email specificato oppure l'indirizzo del mittente se il secondo argomento non è specificato. <tag><tt>which [<email>]</tt> <item> Lista tutte le sottoscrizioni per il mittente o l'indirizzo email opzionalmente specificato. <tag><tt>keyword [<email>]</tt> <item> Ti dice le parole chiave che stai accettando. Per una spiegazione sulle parole chiave, <qref id="pkg-tracking-system">vedi sopra</qref>. Ecco un veloce riepilogo: <list> <item><tt>bts</tt>: mail provenienti dal sistema di tracciamento dei bug Debian <item><tt>bts-control</tt>: risposte alle mail inviate a &email-bts-control; <item><tt>summary</tt>: mail automatiche di repilogo sullo stato di un pacchetto <item><tt>cvs</tt>: notifiche di commit CVS <item><tt>ddtp</tt>: traduzioni di descrizioni e template di debconf <item><tt>upload-source</tt>: annuncio dell'avvenuta accettazione di un nuovo upload di sorgenti <item><tt>upload-binary</tt>: annuncio di un nuovo upload solo binario (porting) <item><tt>katie-other</tt>: altre mail dagli ftpmaster (disparità di override, ecc.) <item><tt>default</tt>: tutte le altre mail (quelle che non sono "automatiche") </list> <tag><tt>keyword <sourcepackage> [<email>]</tt> <item> Come il precededente ma per il dato pacchetto sorgente, siccome puoi selezionare un set di keyword differenti per ogni pacchetto sorgente. <tag><tt>keyword [<email>] {+|-|=} <lista di keyword></tt> <item> Accetta (+) o rifiuta (-) le mail classificate sotto le date parole chiave. Definisce la lista (=) delle parole chiave accettate. <tag><tt>keyword <sourcepackage> [<email>] {+|-|=} <lista di keyword></tt> <item> Come il precedente ma sovrascrive la lista delle parole chiave per il pacchetto sorgente indicato. <tag><tt>quit | thanks | --</tt> <item> Ferma l'analisi dei comandi. Tutte le linee successive sono ignorate dal bot. </taglist> <sect1 id="pts-mail-filtering">Filtrare le mail del PTS Una volta che sei sottoscritto a un pacchetto, riceverai le mail spedita a <tt><var>sourcepackage</var>@packages.qa.debian.org</tt>. Queste mail hanno appesi degli header speciali per lasciartele filtrare in una mailbox speciale (p.es. con <prgn>procmail</prgn>). Gli header aggiunti sono <tt>X-Loop</tt>, <tt>X-PTS-Package</tt>, <tt>X-PTS-Keyword</tt> e <tt>X-Unsubscribe</tt>. Ecco un esempio di header aggiunti per una notifica di upload di sorgenti del pacchetto <package>dpkg</package>: <example> X-Loop: dpkg@&pts-host; X-PTS-Package: dpkg X-PTS-Keyword: upload-source X-Unsubscribe: echo 'unsubscribe dpkg' | mail pts@qa.debian.org </example> <sect1 id="pts-cvs-commit">Inoltrare i commit CVS nel PTS Se usi un archivio CVS pubblicamente accessibile per mantenere il tuo pacchetto Debian puoi volere inoltrare le notifiche di commit al PTS in modo che chi si è sottoscritto (e i possibili co-mantainer) possano seguire da vicino l'evoluzione del pacchetto. Una volta che hai impostato l'archivio CVS per generare le notifiche di commit, devi semplicemente assicurarti che mandi una copia di queste email a <tt><var>sourcepackage</var>_cvs@&pts-host;</tt>. Solo le persone che accettano la keyword cvs riceveranno queste notifiche. <sect1 id="pts-web">L'interfaccia web del PTS Il PTS ha un'interfaccia web all'indirizzo <url id="http://&pts-host;/"> che mette insieme un grande numero di informazioni su ogni pacchetto sorgente. Mette in evidenza molti link utili (BTS, statistiche di QA, informazioni sui contatti, stato delle traduzioni DDTP, log di buildd) e raccoglie molte altre informazioni da vari posti (le ultime 30 voci di changelog, stato di testing, ...). È uno strumento molto utile se vuoi conoscere cosa sta succedendo su uno specifico pacchetto sorgente. Oltretutto c'è una form che permette di sottoscriversi facilmente al PTS via email. Puoi saltare direttamente alla pagina web di uno specifico pacchetto sorgente con un URL tipo <tt>http://&pts-host;/<var>sourcepackage</var></tt>. Questa interfaccia web è stata designata come un portale per lo sviluppo di pacchetti: puoi aggiungere contenuti personalizzati sulle pagine dei tuoi pacchetti. Puoi aggiungere "informazioni statiche" (notizie che devono essere disponibili per un tempo indefinito) e notizie nella sezione "latest news" (ultime notizie). Notizie statiche possono essere usate per indicare: <list> <item>la disponibilità di un progetto ospitato su <qref id="alioth">Alioth</qref> per co-mantenere il pacchetto <item>un link per il sito web upstream <item>un link al bug tracker upstream <item>l'esistenza di un canale IRC dedicato al software <item>qualunque altra risorsa disponibile che può essere utile per la manutenzione del pacchetto </list> Notizie classiche possono essere usate per annunciare che: <list> <item>pacchetti beta sono disponibili per il testing <item>si aspettano pacchetti finali per la prossima settimana <item>la pacchettizazione sta per essere rifatta da zero <item>sono disponibili dei backport <item>il mantainer è "in vacanza" (se vogliono pubblicare questa informazione) <item>si sta lavorando per un NMU <item>qualcosa di importante sta per essere fatto al pacchetto </list> Entrambi i tipi di news sono generati in maniera simile: devi solo mandare una email a <email>pts-static-news@qa.debian.org</email> oppure a <email>pts-news@qa.debian.org</email>. La mail dovrebbe indicare a quale pacchetto concerne mettendo il nome del pacchetto sorgente nell'header <tt>X-PTS-Package</tt> della email o in un pseudo-header <tt>Package</tt> (come nei report del BTS). Se un URL è disponibile nell'header <tt>X-PTS-Url</tt> della email o nel pseudo-header tt>Url</tt>, allora il risultato è un link a tale URL invece che una completa news. Ecco qualche esempio di mail valide usate per generare news nel PTS. Il primo aggiunge un link all'interfaccia cvsweb di debian-cd nella sezione "informazioni statiche": <example> From: Raphael Hertzog <hertzog@debian.org> To: pts-static-news@qa.debian.org Subject: Browse debian-cd CVS repository with cvsweb Package: debian-cd Url: http://cvs.debian.org/debian-cd/ </example> Il secondo è un annuncio spedito a una mailing list che è anche mandato al PTS in modo che venga pubblicato sulla pagina web PTS del pacchetto. Nota l'uso del campo BCC per evitare risposte inviate per errore al PTS. <example> From: Raphael Hertzog <hertzog@debian.org> To: debian-gtk-gnome@lists.debian.org Bcc: pts-news@qa.debian.org Subject: Galeon 2.0 backported for woody X-PTS-Package: galeon Hello gnomers! I'm glad to announce that galeon has been backported for woody. You'll find everything here: ... </example> Pensaci due volte prima di aggiungere una news al PTS perchè dopo non sarai più in grado di rimuoverla e nemmeno di modificarla. L'unica cosa che puoi fare è mandare un'altra news che renderà obsolete le informazioni contenute nella precedente. <sect id="ddpo">Vista d'insieme dei pacchetti degli sviluppatori Un portale web di QA (assicurazione qualità) è disponibile all'indirizzo <url id="&url-ddpo;"> che mostra una tabella che elenca tutti i pacchetti di un singolo sviluppatore (includendo quelli in cui è elencato come co-maintainer). La tabella ti da un buon riepilogo sui pacchetti dello sviluppatore: numero di bug per severità, lista delle versioni disponibili in ogni distribuzione, stato di testing e molto altro inclusi i link a qualunque altra informazione utile. È una buona idea quella di controllare regolarmente i tuoi stessi dati in modo da non dimenticarti di nessun bug aperto e in modo di non dimenticarti quali pacchetti sono sotto la tua responsabilità. <sect id="alioth">Debian *Forge: Alioth Alioth è un servizio Debian abbastanza nuovo, basato su una versione leggermente modificata del software GForge (un evoluzione di SourceForge). Questo software offre agli sviluppatori accesso a strumenti facili da usare come bug tracker, patch manager, project/task manager, servizi di hosting di file, mailing list, archivi CVS ecc. Tutti questi strumenti sono gestiti tramite interfaccia web. È inteso a fornire infrastrutture a progetti di software libero spalleggiati o diretti da Debian, facilitare le contribuzioni da sviluppatori esterni ai progetti iniziati da Debian e aiutare i progetti i cui obiettivi sono la promozione di Debian o dei suoi derivati. Per informazioni aggiuntive visita <url id="&url-alioth;">. <chapt id="pkgs">Gestire i pacchetti Questi capitolo contiene informazioni relativa alla creazione, upload, gestione e "porting" di pacchetti. <sect id="newpackage">Nuovi pacchetti Se vuoi creare un nuovo pacchetto per la distribuzione Debian, dovresti prima consultare la lista dei <url id="&url-wnpp;" name="Pacchetti aventi bisogno di lavoro e futuri"> (WNPP). Controllando tale lista puoi assicurarti che nessuno stia ancora lavorando per fare un pacchetto di quel software, e che non si duplichino gli sforzi. Leggi le <url id="&url-wnpp;" name="pagine web WNPP"> per ulteriori informazioni. Assumendo che nessun'altro stia già lavorando sul tuo futuro pacchetto, devi segnalare un bug (<ref id="submit-bug">) verso il pseudo-pacchetto <package>wnpp</package> descivendo la tua intenzione di creare un nuovo pacchetto includendo, ma non limitandoti a, la descrizione del pacchetto, la sua licenza e l'URL da dove può essere scaricato. Dovresti mettere come soggetto ``ITP: <var>foo</var> -- <var>short description</var>'', sostituendo il nome del nuovo paccheto a <var>foo</var>. La severità del bug dovrebbe essere impostata a wishlist. Se pensi che sia necessario, mandane una copia a &email-debian-devel; impostando l'indirizzo nell'intestazione <tt>X-Debbugs-CC:</tt> del messaggio (no, non usare <tt>CC:</tt>, perchè in quel modo l'oggetto del messaggio non riporterà il numero del bug). Per favore includi un campo <tt>Closes: bug#<var>nnnnn</var></tt> nel changelog nuovo pacchetto in modo da automaticamente chiudere il bug quando il nuovo pacchetto entrerà nell'archivio. (<ref id="upload-bugfix">). Ci sono diverse ragioni per le quali chiediamo ai mantainers di annunciare le loro inenzioni: <list compact> <item> Aiuta i (potenziali nuovi) mantainer di sfruttare l'esperienza delle persone della lista, e fa loro sapere se qualcun'altro ci sta già lavorando sopra. <item> Fa sapere ad altre persone che stanno pensando di lavorare sul pacchetto che esiste già un volontario, quindi gli sforzi possono essere ripartiti. <item> Fa sapere agli altri mantainer di più sul pacchetto alla descrizione di una sola linea e la frase ``Initial release'' del changelog che viene spedita a <tt>debian-devel-changes</tt>. <item> È di aiuto per le persone che usano unstable (e formano la nostra prima linea di tester). Dovremmo incoraggiare queste persone. <item> Gli annunci fanno sapere ai mantainter e alle altre parti interessate cosa sta succedendo e cosa c'è di nuovo all'interno del progetto. </list> <sect id="changelog-entries">Registrare i cambiamenti dei pacchetti Le modifiche che apporti al pacchetto devono essere registrate nel <file>debian/changelog</file>. Le registrazioni devono contenere una descrizione concisa di cosa è cambiato, perchè (se non è chiaro) e specificare se dei bug sono stati chiusi. Registrano anche quando il pacchetto è stato completato. Questo file verrà installato in <file>/usr/share/doc/<var>package</var>/changelog.Debian.gz</file>, o <file>/usr/share/doc/<var>package</var>/changelog.gz</file> per i pacchetti nativi. Il file <file>debian/changelog</file> è conforme a una certa struttura, con diversi campi. Un campo degno di nota, distribution, è descritto in <ref id="distribution">. Ulteriori informazioni sulla struttura di questo file possono essere trovate nella sezione della Policy Debian intitolata "<file>debian/changelog</file>". Le voci nel changelog possono essere usate per chiudere automaticamente dei bug Debian quando il pacchetto verrà installato nell'archivio. Leggi <ref id="upload-bugfix">. È una cosa convenzionale che la voce del changelog di un pacchetto che contiene una nuova versione del software sia: <example> * new upstream version </example> Esistono degli strumenti che ti permettono di creare voci e completare il <file>changelog</file> per il rilascio — leggi <ref id="devscripts"> e <ref id="dpkg-dev-el">. Leggi anche <ref id="bpp-debian-changelog">. <sect id="sanitycheck">Controllare il pacchetto Prima di effettuare l'upload di un pacchetto, dovresti effettuare dei controlli di base su di esso. Dovresti almeno provare a svolgere le seguenti attività di base (avrai bisogno di avere da qualche parte una vecchia versione dello stesso pacchetto): <list> <item> Installa il pacchetto e assicurati che il software funziona, o aggiorna il pacchetto da una vecchia versione alla tua nuova se un pacchetto Debian per esso esiste già. <item> Lancia <prgn>lintian</prgn> sul pacchetto. Puoi lanciare <prgn>lintian</prgn> come segue: <tt>lintian -v <var>package-version</var>.changes</tt>. In questo modo saranno controllati sia il pacchetto sorgente che il pacchetto binario. Se non capisci l'output generato da <prgn>lintian</prgn> prova ad aggiungere lo switch <tt>-i</tt>, che porterà <prgn>lintian</prgn> a riportare una descrizione molto prolissa del problema. Normalmente, non si dovrebbe effettuare l'upload di un pacchetto se lintian segnala degli errori (cominceranno con <tt>E</tt>). Per ulteriori informazioni su <prgn>lintian</prgn>, leggi <ref id="lintian">. <item> Opzionalmente lancia <ref id="debdiff"> per analizzare i cambiamenti dalla versione precedente, se ne esiste una. <item> Effettua un downgrade del pacchetto alla versione precedente (se esiste) — questo mette alla prova gli script <file>postrm</file> e <file>prerm</file>. <item> Rimuovi il pacchetto, poi reinstallalo. </list> <sect id="sourcelayout">Layout del pacchetto sorgente Esistono due tipi di pacchetti Debian sorgenti: <list> <item> i cosiddetti pacchetti nativi, nei quali non c'è distinzione tra i sorgenti originali e le patch applicate per Debian <item> i (più comuni) pacchetti dove esistono i sorgenti originali accompagnati da un altro file che contiene le patch applicate per Debian. </list> Per i pacchetti nativi, il pacchetto sorgente include un file Debian di controllo dei sorgenti (<tt>.dsc</tt>) e il file con i sorgenti (<tt>.tar.gz</tt>). Il pacchetto sorgente di un pacchetto non-nativo include il file Debian di controllo dei sorgenti, il file con i sorgenti originali (<tt>.orig.tar.gz</tt>) e le patch Debian (<tt>.diff.gz</tt>). Se un pacchetto è nativo oppure no viene determinato quando viene costruito da <manref name="dpkg-buildpackage" section="1">. Il resto di questa sezione si riferisce solo ai pacchetti non-nativi. La prima volta che viene effettuato l'upload di una nuova versione corrispondente a una nuova versione upstream, dovrebbe essere effettuato l'upload anche del file tar dei sorgenti originali includendolo nel file <file>.changes</file>. Conseguentemente, quello stesso file tar dovrebbe essere usato per costruire le nuove "diff" e i nuovi file <file>.dsc</file>, senza bisogno di ripeterne l'upload. Per default, <prgn>dpkg-genchanges</prgn> e <prgn>dpkg-buildpackage</prgn> includeranno i sorgenti originali se e solo se la parte realativa alla revisione Debian del numero di versione del sorgente è 0 o 1, indicante una nuova versione upstream. Questo comportamento può essere modificato usando <tt>-sa</tt> per includerlo sempre o <tt>-sd</tt> per lasciarlo sempre da parte. Se nessun sorgente originale viene incluso nell'upload, il file tar dei sorgenti originali usato da <prgn>dpkg-source</prgn> per costruire il file <file>.dsc</file> le diff per farne l'upload deve essere byte-per-byte identico a quello già presente in archivio. <sect id="distribution">Scegliere la distribuzione Ogni upload deve specificare in quale distribuzione deve essere incluso il pacchetto. Il processo di costruzione del pacchetto estrae questa informazione dalla prima linea del file <file>debian/changelog</file> e la pone nel campo <tt>Distribution</tt> del file <tt>.changes</tt>. Ci sono diversi valori possibili per questo campo: `stable', `unstable', `testing-proposed-updates' e `experimental'. Normalmente, al momento dell'upload i pacchetti sono destinati a unstable. Attualmente, ci sono altre due distribuzioni possibili: `stable-security' e `testing-security', ma per queste leggi <ref id="bug-security"> per ulteriori informazioni. Tecnicamente è possibile effettuare l'upload di un pacchetto in più distribuzioni allo stesso tempo ma di solito non ha alcun senso farlo perchè le dipendenze del pacchetto possono cambiare a seconda della distribuzione. In particolare, non ha mai senso combinare la distribuzione experimental con qualunque altra. (vedi <ref id="experimental">). <sect1 id="upload-stable"> <heading>Caso speciale: upload alla distribuzione stable Effetuare un upload alla distribuzione stable implica che il pacchetto verrà posto nella directory <file>stable-proposed-updates</file> dell'archivio Debian per essere ulteriormente testata prima che sia realmente incluso in stable. Bisognerebbe apporre maggiore attenzione quando si effettua un upload per stable. Di base, un pacchetto dovrebbe essere mandato in upload in stable solo se si verifica uno dei seguenti casi: <list> <item>un problema nella funzionalità realmente critico <item>il pacchetto diventa ininstallabile <item>manca il pacchetto in una certa architettura </list> Nel passato, si usava fare upload verso stable anche per problemi relativi alla sicurezza. Comunque, questa pratica è sconsigliata in quanto gli upload usati per gli advisory di sicurezza Debian sono automaticamente copiati nell'archivio <file>proposed-updates</file> appropriato quando l'advisory viene rilasciata. Vedi <ref id="bug-security"> per informazioni dettagliate su come gestire i problemi di sicurezza. Cambiare qualsiasi altra cosa nel pacchetto che non sia importante è sconsigliato, perchè perfino i fix piu' scontati possono in seguito causare dei bug. Pacchetti mandati in upload su stable devono essere compilati in sistemi che girano su stable, in modo che le loro dipendenze siano limitate alle librerie (e altri pacchetti) disponibili in stable; per esempio, un pacchetto di cui si sia effettuato l'upload in stable che dipende da una libreria esistente solo in unstable sarà rifiutato. Effettuare cambiamenti alle dipendenze di altri pacchetti (giocando con <tt>Provides</tt> o file shlibs), rendendo questi altri pacchetti possibilmente ininstallabili, è fortemente sconsigliato. Il "Release Team" (che può essere contattato tramite &email-debian-release;) valuterà regolarmente gli upload in stable-proposed-updates e deciderà se il tuo pacchetto può essere incluso in stable. Per favore sii chiaro (e prolisso se necessario) nelle voci nel tuo changelog per gli upload in stable, in quanto altrimenti il pacchetto non sarà considerato per l'inclusione. <sect1 id="upload-t-p-u"> <heading> Caso speciale: upload a testing-proposed-updates</heading> La distribuzione testing è composta dai pacchetti da unstable in accordo alle regole spiegate in <ref id="testing">. In ogni caso, il release manager può fermare gli script di testing quando ha intenzione di fare un "freeze" della distribuzione. In quel caso, puoi volere effettuare upload a testing-proposed-updates per fornire fix di pacchetti durante il freeze. Tieni a mente che quegli upload non sono processati automaticamente, devono passare per le mani del release manager. Dovresti quindi avere una buona ragione per effettuare upload lì. Per sapere quale sia una buona ragione negli occhi del release manager, dovresti leggere le istruzioni che regolarmente da su &email-debian-devel-announce;. Non dovresti effettuare upload su testing-proposed-updates quando puoi aggiornare i toi pacchetti attraverso unstable. Se non puoi (per esempio perchè hai una nuova versione in sviluppo in unstable), puoi usarlo ma è raccomandato chiedere prima l'autorizzazione al release manager. <sect id="upload">Effetuare un upload <sect1 id="upload-ftp-master">Inviare un upload a <tt>ftp-master</tt> Per inviare un pacchetto in upload, hai bisogno di un account personale su <ftpsite>&ftp-master-host;</ftpsite>, cosa che dovresti avere essendo un mantainer ufficiale. Se usi <prgn>scp</prgn> o <prgn>rsync</prgn> per trasferire i file, posizionali in &us-upload-dir;; se usi FTP anonimo, posizionali in &upload-queue;. Se vuoi usare la funzione descritta in <ref id="delayed-incoming">, dovrai mandare l'upload a <tt>ftp-master</tt>. È l'unico punto di upload che supporta l'immissione ritardata. Per piacere nota che dovresti trasferire il file changes per ultimo. Altrimenti, il tuo upload può essere rifiutato perchè il software di manutenzione dell'archivio scorrerà il file changes e vedrà che non tutti i file sono stati inviati in upload. Se non hai voglia di trasferire il file changes per ultimo, puoi semplicimente copiare i tuoi file in una directory temporanea in <tt>ftp-master</tt> e quindi spostarli in &us-upload-dir;. Nota: Non inviare a <tt>ftp-master</tt> upload di pacchetti crittografici che appartengono a contrib o non-free. Upload di tali software dovrebbero andare a <tt>non-us</tt> (vedi <ref id="upload-non-us">). Inoltre pachetti contenenti codice brevettato da il governo degli Stati Uniti non possono essere inviati in upload a <tt>ftp-master</tt>; dipendentemente dal caso potrebbero essere comunque inviati a <file>non-US/non-free</file> (è in non-free per caratteristiche della distribuzione e non a causa della licenza del software). Se non puoi inviarlo in upload a <tt>ftp-master</tt>, non puoi neanche farlo alle code di upload oltreoceano su <tt>chiark</tt> o <tt>erlangen</tt>. Se non sei sicuro se i controlli sulle licenze o sualla crittografia degli Stati Uniti si applicano al tuo pacchetto, manda un messaggio a &email-debian-devel; e chiedi. Puoi anche trovare utili per l'upload dei pacchetti i pacchetti Debian <ref id="dupload"> o <ref id="dput">. Questi maneggevoli programmi aiutano ad automatizzare il processo dell'upload di pacchetti in Debian. Dopo l'upload del tuo pacchetto, puoi controllare come il software di manutenzione dell'archivio lo processerà facendo girare <prgn>dinstall</prgn> sul tuo file changes: <example>dinstall -n foo.changes</example> Nota che <prgn>dput</prgn> può automaticamente fare questo per te. <sect1 id="upload-non-us">Inviare un upload a <tt>non-US</tt> Come sopra discusso, sofware a esportazione controllata non dovrebbero essere inviati a <tt>ftp-master</tt>. Al suo posto, spedisci il pacchetto a <ftpsite>non-us.debian.org</ftpsite>,ponendo i file in &non-us-upload-dir; (di nuovo, sia <ref id="dupload"> che <ref id="dput">possono fare questo per te se propriamente invocati). Di default, puoi usare gli stessi account/password che usi su <tt>ftp-master</tt>. Se per gli upload usi FTP anonimo, poni i file in &upload-queue;. Puoi controllare i tuoi upload allo stesso modo di come fai su <tt>ftp-master</tt>, con: <example>dinstall -n foo.changes</example> Nota che i cittadini o i residenti negli Stati Uniti sono soggetti a restrizioni sull'esportazione di software crittografico. Al tempo della scrittura di questo documento, i cittadini degli Stati Uniti sono autorizzati a esportare qualche software crittografico, soggetto a regole di notificazione dal Dipartimento sul Commercio degli Stati Uniti. Comunque, questa restrizione è stata posta in deroga per i software già disponibile al di fuori degli Stati Uniti. Di conseguenza, qualsiasi software crittografico che appartiene alla sezione main dell'archivio Debian e che non dipende da nessun pacchetto esterno a main (e.g., non dipende da niente in non-US/main) puo' essere inviato a <tt>ftp-master</tt> o alle sue code, sopra descritte. La policy Debian non previene upload su non-US da cittadini o residenti degli Stati Uniti, ma queste persone dovrebbero fare attenzione nel farlo. È raccomandato che gli sviluppatori intraprendano tutti i passi necessari per assicurarsi che non violino le correnti leggi degli Stati Uniti effettuando un upload su non-US, compreso consultarsi con un avvocato. Per i pacchetti in non-US/main, non-US/contrib, gli sviluppatori dovrebbero almeno seguire le <url id="&url-u.s.-export;" name="procedure specificate dal Governo degli Stati Uniti">. I mantainer di pacchetti in non-US/non-free dovrebbero in aggiunta consultare le <url id="&url-notification-of-export;" name="regole per la notificazione dulle esportazioni"> sul software non libero. Questa sezione è esclusivamente a titolo informativo e non costituisce dei consigli legali. Di nuovo, è fortemente raccomandato che i cittadini e residenti degli Stati Uniti consultino un avvocato prima di effettuare upload a non-US. <sect1>Upload via <tt>chiark</tt> Se hai una connessione di rete lenta verso <tt>ftp-master</tt>, esistono delle alternative. Una è quella di inviare file in upload a <file>Incoming</file> attraverso una coda di upload in Europa su <tt>chiark</tt>. Per dettagli collegati a <url id="&url-chiark-readme;">. Nota: Non inviare in upload pacchetti contenenti software che è a esportazione controllata dal governo degli Stati Uniti sulla coda in <tt>chiark</tt>. Siccome questa coda di upload va in <tt>ftp-master</tt>, le prescrizioni trovate in <ref id="upload-ftp-master"> si applicano anche qua.  Il programma <prgn>dupload</prgn> supporta gli upload a <tt>chiark</tt>; per favore fai riferimento alla documentazione fornita con il programma per i dettagli. <sect1>Upload via <tt>erlangen</tt> Un altra coda di upload è disponibile in Germania: semplicemente invia i file in upload via FTP anonimo a <url id="&url-upload-erlangen;">. L'upload deve essere un upload completo Debian, come lo invieresti a <file>Incoming</file> di <tt>ftp-master</tt>, ovvero dei file <file>.changes</file> insieme agli altri file menzionati nei <file>.changes</file> stessi. Il demone della coda controlla anche che il <file>.changes</file> sia correttamente firmato con GnuPG o OpenPGP da uno sviluppatore Debian, in modo che nessun file fasullo possa intrufolarsi in <tt>ftp-master</tt> attraverso questa coda. PEr favore assicurati anche che il campo <tt>Maintainer</tt> nel <file>.changes</file> contiene il tuo indirizzo e-mail. L'indirizzo lì trovato è usato per tutte le risposte, proprio come in <tt>ftp-master</tt>. Non c'è alcn bisogno di muovere i tuoi file in una directory secondaria dopo l'upload, come su <tt>chiark</tt>. E, in ogni caso, dovresti ricevere una mail di risposta dal demone della coda spiegando cosa è successo al tuo pacchetto. È sperabile che sia stato spostato in <tt>ftp-master</tt>, ma in caso di errori sarai comunque avvisato. Nota: Non inviare in upload pacchetti contenenti software che è a esportazione controllata dal governo degli Stati Uniti sulla coda in <tt>erlangen</tt>. Siccome questa coda di upload va in <tt>ftp-master</tt>, le prescrizioni trovate in <ref id="upload-ftp-master"> si applicano anche qua.  Il programma <prgn>dupload</prgn> supporta gli upload a <tt>erlangen</tt>; per favore fai riferimento alla documentazione fornita con il programma per i dettagli. <sect1>Altre code di upload Un altra coda di upload basata negli Stati Uniti è disponibile, ed è un buon backup nel caso ci siano problemi a raggiungere <tt>ftp-master</tt>. Puoi inviare file in upload, esattamente come in <tt>erlangen</tt>, a <url id="&url-upload-samosa;">. Una coda di upload è disponibile in Giappone: semplicemente invia i file in upload via FTP anonimo a <url id="&url-upload-jp;">. <sect1 id="upload-notification"> <heading>Notificazione che un nuovo pacchetto è stato installato</heading> I mantainer dell'archivio Debian sono responsabili per la gestione degli upload dei pacchetti. Per la maggior parte, gli upload sono giornalmente gestiti automaticamente dagli strumenti di manutenzione dell'archivio, <prgn>katie</prgn>. Specificatamente, gli aggiornamenti di pacchetti esistenti nella distribuzione `unstable' sono gestiti automaticamente. In altri casi, specialmente nei nuovi pacchetti, il posizionamento del pacchetto in upload nella distribuzione è gestito manualmente. Quando gli upload sono gestiti manualmente, il cambiamento all'archivio può prendere fino a un mese di tempo. Per favore sii paziente. In ogni caso, riceverai una email di notifica indicante che il pacchetto è stato aggiunto all'archivio, la quale indica anche quali bug saranno chiusi dall'upload. Per favore esamina con attenzione la notifica, controllando se qualche bug che avevi intenzione di chiudere non è scattato. La notifica di installazione ti informerà anche su in quale sezione il pacchetto è stato inserito. Se esiste disparità, riceverai una email separata per avvisarti di ciò. Continua a leggere sotto. Nota anche che se effettui upload attraverso le code, anche il software demone di coda ti manderà una notifica via email. <sect id="override-file">Specificare sezione, sottosezione e priorità del pacchetto I campi <tt>Section</tt> e <tt>Priority</tt> del file <file>debian/control</file> non specifica in realtà in che luogo il file verrà piazzato nell archivio, e nemmeno la sua priorità. Per conservare l'integrità complessiva dell'archivio, sono i mantainer dell'archivio che hanno il controllo su quei campi. I valori nel file <file>debian/control</file> sono in realtà solo suggerimenti. I mantainer dell'archivio tengono traccia delle sezioni e priorità canoniche per i pacchetti nel file override. Se esiste una disparità tra il file override e i campi indicati nel file <file>debian/control</file>, allora riceverai una email notificante la divergenza quando il pacchetto sarà installati nell'archivio. Puoi o correggere il tuo file <file>debian/control</file> per il tuo prossimo upload, oppure puoi desiderare di apportare una modifica nel file override. Per alterare la sezione reale in cui viene posto un pacchetto, devi prima assicurarti che il <file>debian/control</file> nel tuo pacchetto sia accurato. Dopodichè, manda una email a &email-override; oppure segnala un bug di <package>ftp.debian.org</package> richiedendo che la sezione o la priorità del tuo pacchetto venga modificata dalla vecchia alla nuova. Assicurati di spiegare le tue ragioni. Per ulteriori informazioni circa i file override, vedi <manref name="dpkg-scanpackages" section="8"> e <url id="&url-bts-devel;#maintincorrect">. Nota che il campo <tt>Section</tt> specifica sia la sezione che la sottosezione, descritte in <ref id="archive-sections">. Se la sezione è "main", dovrebbe essere omessa. La lista delle sottosezioni permesse può essere trovata in <url id="&url-debian-policy;ch-archive.html#s-subsections">. <sect id="bug-handling">Gestire i bug Ogni sviluppatore deve essere in grado di lavorare con il <url name="sistema di tracciamento dei bug" id="&url-bts;"> Debian. Questo include sapere come archiviare  propriamente i bug report (vedi <ref id="submit-bug">), come aggiornarli e registrarli, e come processarli e chiuderli. Le caratteristiche  del sistema di tracciamento dei bug interessanti per gli sviluppatori sono descritte nella <url id="&url-bts-devel;" name="documentazione per gli sviluppatori sul BTS">. Questo include chiudere bug, inviare messaggi di followup, assegnare severità e tag, marcare bug come inoltrati e altro. Operazioni come reassegnare bug ad altri pacchetti, unire  bug report separati che riguardano la stessa cosa, o riaprire bug quando sono stati chiusi premeturamente, sono gestite usando il cosiddetto mail server di controllo.  Tutti i comandi disponibili in questo server sono descritti nella <url id="&url-bts-control;" name="documentazione del server di controllo del BTS">.  <sect1 id="bug-monitoring">Monitorare i bug Se vuoi essere un buon mantainer, dovresti cotrollare periodicamente il <url id="&url-bts;" name="sistema di tracciamento dei bug Debian (BTS)"> per i tuoi pacchetti. Il BTS contiene tutti i bug aperti contro i tuoi pacchetti. Puoi controllarli visitando questa pagina: <tt>http://&bugs-host;/<var>latualogin</var>@debian.org</tt>. I mantainer interagiscono con il BTS attraverso l'indirizzo email <tt>&bugs-host;</tt>. La documentazione sui comandi disponibili può essere trovata su <url id="&url-bts;">, oppure, se hai installato il pacchetto <package>doc-debian</package>, puoi dare un'occhiata ai file in locale &file-bts-docs;. Qualcuno trova utile ricevere dei resoconti periodici sui bug aperti. Puoi aggiungere un cron job  come i seguenti se vuoi ricevere settimanalmente una email sottolineante  tutti i bug aperti contro i tuoi pacchetti. <example> # chiedi un resoconto settimanale sui bug nei miei pacchetti &cron-bug-report; </example> Sostituisci <var>address</var> con il tuo indirizzo come mantainer ufficiale Debian. <sect1 id="bug-answering">Rispondere ai bug Quando rispondi ai bug, assicurati che qualunque discussione tu intraprenda circa i bug sia inviata sia a chi ha originalmente inviato il bug che al bug stesso (p.es., <email>123@&bugs-host;</email>). Se stai scrivendo una nuova email e non ricordi l'indirizzo email di chi ha inviato il bug, puoi usare l'indirizzo <email>123-submitter@&bugs-host;</email> per contattarlo e memorizzare la tua email nel log del bug (ciò significa che non hai bisogno di inviare una copia della mail a <email>123@&bugs-host;</email>). Se ricevi un bug recante la dicitura "FTBFS", ciò significa "Fails to build from source" - fallisce durante il build dai sorgenti . I porter usano spesso questo acronimo. Una volta che hai finito con un bug  (p.es. lo hai risolto), marcalo con done (chiudilo) mandando un messaggio esplicativo a <email>123-done@&bugs-host;</email>. Se stai risolvendo un bug cambiando il pacchetto ed effettuandone un upload, puoi automatizzare la chiusura del bug come descritto in <ref id="upload-bugfix">. Non dovresti mai chiudere bug attraverso il comando del bug server <tt>close</tt> inviato a &email-bts-control;. Se fai così, il segnalatore originario non riceverà alcuna informazione sul perchè detto bug è stato chiuso. <sect1 id="bug-housekeeping">Bug housekeeping  Come mantainer, toverai spesso bug in altri pacchetti o ti verranno segnalati bug in tuoi pacchetti che sono in realtà bug di altri pacchetti. Le feature del sistema di tracciamento dei bug interessanti per gli sviluppatori sono descritte nella <url id="&url-bts-devel;" name="Documentazione sul BTS per gli sviluppatori Debian">. Operazioni come reassegnare, fondere e marcare le segnalazioni di bug sono descritte nella <url id="&url-bts-control;" name="documentazione del server di controllo del BTS">. Questa sezione contiene alcune linee guida per la gestione dei tuoi bug, basate sull'esperienza collettiva degli sviluppatori Debian. Segnalare bug per problemi che incontri in altri pacchetti fa parte degli "obblighi civili"  nell'essere un mantainer, vedi <ref id="submit-bug"> per i dettagli. In ogni caso, gestire i bug nei tuoi stessi pacchetti è ancora più importante. Di seguito è riportata una lista di passi che puoi seguire per gestire una segnalazione di bug. <enumlist> <item> Stabilire se la segnalazione corrisponda o meno realmente a un bug. A volte gli utenti stanno solo invocando un programma nel modo sbagliato perchè non hanno letto la documentazione. Se pensi che sia successo in realtà questo, chiudi semplicemente il bug indicando abbastanza informazioni per permettere all'utente di risolvere il problema (indica la giusta documentazione e cose così). Se giungono in continuazione segnalazioni sullo stesso problema potresti chiederti se la documentazione sia adeguata o se il programma non dovrebbe accorgersi del problema e mandare in output un messaggio di errore più informativo.  Questo potrebbe essere un problema da sottoporre all'autore del software. Se il segnalatore originale del bug non è d'accordo con la tua decisione di chiudere il bug, possono riaprirlo finchè non trovate un accordo su come gestirlo. Se non riesci a trovarlo, puoi volere marcare il bug <tt>wontfix</tt> per fare sapere alla gente che il bug esiste ma che non sarà corretto. Se questa situazione è inaccettabile, tu (o il segnalatore) puoi richiedere una "sentenza" della commissione tecnica riassegnando il bug a <package>tech-ctte</package> (puoi usare il comando "clone" del BTS se desideri di tenerlo segnalato sul tuo pacchetto). Prima di farlo, per piacere leggi le <url id="&url-tech-ctte;" name="procedure raccomandate">. <item> Se il bug è reale ma è causato da un altro pacchetto, riassegnalo semplicemente al pacchetto giusto. Se non sai a quale pacchetto dovrebbe essere riassegnato, puoi o chiedere aiuto in &email-debian-devel; o riassegnarlo a <package>debian-policy</package> per fare decidere a loro quale pacchetto sia bacato. A volte puoi avere bisogno di aggiustare la severità del bug in modo che corrisponda alla nostra definizione di severità. Questo perché la gente tende a gonfiare la severità dei bug per assicurarsi che vengano risolti velocemente. Certi bug possono persino venire degradati a `wishlist' quando il cambiamento richiesto è solo cosmetico. <item> Il segnalatore del bug può avere dimenticato di fornire alcune informazioni, in tal caso devi chiedergli le informazioni necessarie. Puoi usare il tag <tt>moreinfo</tt> per marcare il bug di conseguenza. Oltretutto, se non puoi riprodurre il bug, marcalo <tt>unreproducible</tt>. Chiunque sia in grado di riprodurre il bug è quindi invitato a fornire ulteriori informazioni su come fare per riprodurlo. Dopo qualche mese, se nessuno ha mandato informazioni, il bug può essere chiuso. <item> Se il bug è dovuto alla pacchettizzazione, risolvilo semplicemente. Se non sei in grado di risolverlo da solo, marca il bug con <tt>help</tt>. Puoi anche chiedere aiuto su &email-debian-devel; oppure &email-debian-qa;. Se è un problema a livello upstream, devi inoltrarlo all'autore originale. Inoltrare un bug non è abbastanza, devi conrollare a ogni release  se il bug sia stato risolto o meno. In caso affermativo, chiudilo semplicemente, altrimenti devi ricordarne l'esistenza all'autore. Se hai l'abilità necessaria puoi preparare una patch che risolve il bug e spedirla allo stesso tempo all'autore. Assicurati di mandare la patch al BTS e marcare il bug con <tt>patch</tt>. <item> Se hai risolto un bug in locale, o una patch è stata inviata all'archivio CVS, puoi marcare il bug come <tt>pending</tt> per far sapere alla gente che il bug è stato corretto e che verrà chiuso con il prossimo upload (aggiungendo <tt>closes:</tt> nel <file>changelog</file>). Questo è particolarmente utile se ci sono più sviluppatori che lavorano sullo stesso pacchetto. <item> Una volta che un pacchetto corretto è disponibile nella distribuzione unstable, puoi chiudere il bug. Ciò puoò essere fatto automaticamente, vedi <ref id="upload-bugfix">. </enumlist> <sect1 id="upload-bugfix">Quando i bug vengono chiusi da nuovi upload. Intanto che bug e problemi nei tuoi pacchetti vengono risolti, è tua responsabilità come mantainer del pacchetto chiudere il bug. Comunque, non dovresti chiudere il bug finché il pacchetto che lo corregge non sia stato accettato nell'archivio Debian. Di conseguenza, una volta che ricevi la notifica che il tuo pacchetto aggiornato è stato installato nell'archivio, puoi e dovresti chiudere il bug nel BTS. È comunque possibile evitare di dover chiudere manualmente i bug dopo gli upload — elenca semplicemente i bug risolti nel tuo file <file>debian/changelog</file>, rispettando una certa sintassi, e il software di manutenzione dell'archivio chiuderà il bug per te. Per esempio: <example> acme-cannon (3.1415) unstable; urgency=low * Riempito di opzioni (closes: Bug#98339)  * Aggiunta protezione per prevenire la disintegrazione dell'operatore, closes: bug#98765, bug#98713, #98714.  * Aggiunta man page. Closes: #98725.  </example> In termini tecnici, la seguente espressione regolare Perl descrive come sono identificati i changelog che chiudono bug: <example> /closes:\s*(?:bug)?\#\s*\d+(?:,\s*(?:bug)?\#\s*\d+)*/ig </example> Noi preferiamo la sintassi <tt>closes: #<var>XXX</var></tt>, essendo la più concisa e la più facile da integrare con il testo del <file>changelog</file>. Se ti succede di sbagliare a scrivere il numero di un bug o di dimenticare un bug nelle voci del changelog, non esitare ad annullare ogni danno causato dall'errore. Per riaprire bug chiusi per errore, manda un comando <tt>reopen <var>XXX</var></tt> all'indirizzo del controllo del sistema di tracciamento dei bug, &email-bts-control;. Per chiudere i rimanenti bug risolti dal tuo upload, manda il file <file>.changes</file> a <email>XXX-done@&bugs-host;</email>, dove <var>XXX</var> è il numero del tuo bug. Tieni a mente che non è obbligatorio chiudere i bug usando il changelog come descritto sopra. Se vuoi chiudere bug che semplicemente non hanno niente a che fare con gli upload che hai fatto, fallo mandando una email di spiegazione a <email>XXX-done@&bugs-host;</email>. NON chiudere bug nella voce del changelog di una versione se i cambiamenti fatti in quella versione non hanno niente a che fare con il bug. Per informazioni generali su come scrivere le tue voci nel changelog, vedi <ref id="bpp-debian-changelog">. <sect1 id="bug-security">Gestire i bug di sicurezza Per la loro natura sensibile  , i bug di sicurezza devono essere gestiti con molta attenzione. Il Team di sicurezza Debian esiste per coordinare queta attività, tenendo traccia dei problemi di sicurezza esistenti, aiutando i mantainer con problemi di sicurezza o risolvendoli direttamente, mandando advisory di sicurezza e mantenendo  security.debian.org.   Quando vieni a conoscenza dell'esistenza di un bug di sicurezza in un pacchetto Debian, che tu ne sia o meno il mantainer raccogli informazioni pertinenti al problema, e contatta prontamente il team di sicurezza presso &email-security-team; il più presto possibile. Per esempio, sono informazioni utili: <list compact> <item>Quali versioni del pacchetto sono riconosciute essere affette dal bug. Controlla ogni versione presente in una release Debian supportata, così come testing e unstable. <item>La natura del rimedio, se disponibile (le patch sono perticolarmente d'aiuto) <item>Qualunque pacchetto "riparato"  che hai personalmente preparato (manda solo i file <tt>.diff.gz</tt> e <tt>.dsc</tt> e leggi prima <ref id="bug-security-building">) <item>Qualunque assistenza sei in grado di fornire per aiutare il testing (exploit, regression testing, ecc.) <item>Qualunque informazione necessaria per l'advisory (vedi <ref id="bug-security-advisories">) </list> <sect2 id="bug-security-confidentiality">Riservatezza Al contrario della maggior parte delle altre attività in Debian, a volte le informazioni sui problemi di sicurezza devono essere tenute private per un certo tempo. Questo permette ai distributori di software di coordinare il rilascio delle informazioni  in modo da minimizzare l'esposizione dei loro utenti. Questa decisione dipende dalla natura del problema e del rimedio corrispondente, e se sia già di pubblico dominio. Ci sono diversi modi in cui uno sviluppatore può venire a conoscenza di un problema di sicurezza: <list compact> <item>lo nota su un forum pubblico (mailing list, sito web, ecc.) <item>qualcuno manda un bug report <item>qualcuno li informa tramite un'email privata </list> Nei primi due casi, l'informazione è pubblica ed è importante avere un rimedio il più presto possibile. Nell'ultimo caso, comunque, potrebbe non essere un informazione pubblica. In quel caso ci sono poche alternative possibili per gestire il problema: <list> <item>Se l'esposizione di sicurezza è minima, a volte non c'è bisogno di tenere segreto il problema e un rimedio dovrebbe essere creato e rilasciato. <item>Se il problema è grave, è preferibile condividere le informazioni con gli altri produttori e coordinarne il rilascio. Il team di sicurezza mantiene i contatti con le varie organizzazioni e individui e può prendersene cura. </list> In ogni caso, se chi riporta il problema chiede che esso non sia reso pubblico, tale richiesta dovrebbe essere rispettata, con l'ovvia eccezione di informare il team di sicurezza in modo che una fix possa essere prodotta per una release stabile di Debian. Quando si mandano informazioni confidenziali al team di sicurezza, assicurati di menzionare il fatto. Per favore nota che se la segretezza è necessaria non puoi mandare una fix in upload su unstable (o da qualsiasi altra parte, come un archivio CVS pubblico). Non è sufficente offuscare i dettagli delle modifiche, essendo il codice stesso pubblico, e può essere (e sarà) esaminato dal pubblico in generale. Ci sono due ragioni per rilasciare informazioni anche se è richiesto un certo grado di sicurezza: il problema era risaputo da un certo tempo, o il problema o l'exploit è diventato pubblico. <sect2 id="bug-security-advisories">Advisory di sicurezza Le advisory di sicurezza sono rilasciate solo per la corrente, rilasciata distribuzione stabile, e non per testing o unstable. Quando sono rilasciate, le advisory sono inviate alla mailing list &email-debian-security-announce; e postate sulle <url id="&url-debian-security-advisories;" name="pagine web di sicurezza">. Le advisory di sicurezza vengono scritte e postate dal team di sicurezza. Nonostante ciò saranno certamente contenti se un mantainer può fornire qualche informazione per loro, o scrivere parte del testo. Le informazioni che dovrebbero comparire in un advisory includono: <list compact> <item>Una descrizione del problema e della sua portata, includendo: <list> <item>Il tipo del problema (privilege escalation, denial of service, etc.) <item>Quali privilegi possono essere ottenuti, e da chi (se da qualcuno) <item>Come può essere sfruttato <item>Se sia sfruttabile in remoto o in locale <item>Come il problema è stato risolto </list> Questa informazione permette agli utenti di stimare la minaccia ai loro sistemi. <item>Numeri di versione dei pacchetti affetti <item>Numeri di versione dei pacchetti sistemati <item>Informazioni su dove ottenere i pacchetti aggiornati (di solito dall'archivio di sicurezza Debian) <item>Riferimenti alle advisory originali <url id="http://cve.mitre.org" name="CVE">, identificatori, e quant'altro. informazioni utili per stabilire referenze incrociate alla vulnerabilità </list> <sect2 id="bug-security-building"> <heading>Preparare i pacchetti per indirizzare i problemi di sicurezza</heading> Un modo per assistere il team di sicurezza nei loro compiti è di fornirli di pacchetti sistemati adatti per un advisory di sicurezza per il rilascio di Debian stable. Quando viene aggiornata la release stable, bisogna fare attenzione per evitare di cambiare il comportamento del sistema o introdurre nuovi bug. Per fare ciò, fai meno modifiche possibile per sistemare il bug. Gli utenti e gli amministratori si fidano del comportamento esatto di una release una volta che è stata fatta, quindi qualsiasi modifica effettuata potrebbe infrangere il sistema di qualcuno. Ciò è specialmente vero con le librerie: assicurati di non cambiare mai le API o ABI, non importa quanto piccolo sia il cambiamento. Ciò significa che muoversi verso una nuova versione upstream non è una buona soluzione. Invece, i cambiamenti rilevanti dovrebbero essere applicate alla versione presente nella release Debian stabile corrente. Generalmente, i mantainer upstream sono disponibili ad aiutarti in caso di bisogno. Altrimenti, il team di sicurezza Debian può essere in grado di aiutarti. In qualche caso, non è possibile effettuare il back-port di un fix  di sicurezza, per esempio quando una notevole quantità di codice sorgente deve essere modificata o riscritta. Se questo è il caso, potrebbe essere necessario ripiegare su una nuova versione upstream. Comunque, questo succede solo in situazioni estreme, e devi sempre prima coordinarti con il team di sicurezza. Esiste un'altra linea guida importante correlata a questo: prova sempre le tue modifiche. Se hai un exploit disponibile, provalo e guarda se veramente ha successo sul pacchetto vecchio e fallisce su quello sistemato. Prova anche altre, normali azioni, siccome a volte un fix di sicurezza può infrangere altre feature che non hanno apparentemente alcuna relazione in modi molto sottili. NON includere alcuna modifica nel tuo pacchetto che non sia direttamente correlata alla risoluzione della vulnerabilità. Queste avranno solo bisogno di essere ripristinate, causando perdite di tempo. Se ci sono altri bug nel tuo pacchetto che vorresti sistemare, effettua un upload in proposed-updates nel solito modo, dopo il rilascio dell'advisory di sicurezza. Il meccanismo degli aggiornamenti di sicurezza non è un modo per introdurre modifiche nel tuo pacchetto che sarebbero altrimenti rifiutate dalla release stabile, qundi per favore non cercare di farlo. Riesamina e prova le tue modifiche più che puoi. Controlla le differenze con la versione precedente in continuazione (<prgn>interdiff</prgn> dal pacchetto <package>patchutils</package> e <prgn>debdiff</prgn> da <package>devscripts</package> sono strumenti utili per questo, vedi <ref id="debdiff">). Assicurati di verificare le seguenti cose: <list> <item>Assegna al giusta distribuzione nel tuo <file>debian/changelog</file>. Per stable è <tt>stable-security</tt> e per testing è <tt>testing-security</tt>, e per la release stable precedente è <tt>oldstable-security</tt>. Non indicare <var>distribution</var>-proposed-updates o <tt>stable</tt>! <item>Crea delle descrittive e significative voci di changelog. Gli altri si riferiranno su quelle per determinare se un particolare bug è stato risolto. Includi sempre un riferimento esterno, preferabilmente un identificatore CVE, in modo che possa essere referenziato in modo incrociato. Includi le stesse informazioni nel changelog per unstable, in modo che sia chiaro che è stato risolto lo stesso bug, essendo ciò molto di aiuto quando si verifica che il bug è risolto nella prossima release stabile. Se un identificatore CVE non è ancora stato assegnato, il team di sicurezza ne richiederà uno in modo che possa essere incluso nel pacchetto e nell'advisory. <item>Assicurati che il numero di versione sia giusto. Deve essere più alto rispetto al pacchetto corrente, ma più basso rispetto alle versioni dei pacchetti nelle distribuzioni successive. Se sei in dubbio, provalo con <tt>dpkg --compare-versions</tt>. Stai attento a non usare nuovamente un numero di versione che hai già usato per un precedente upload. Per testing, deve esserci una versione più alta in unstable. Se non ne esiste ancora una (per esempio, se sia testing che unstable hanno la stessa versione) devi prima effettuare un upload di una nuova versione in unstable. <item>Non effettuare upload di soli sorgenti se il tuo pacchetto ha qualche pacchetto binary-all (non usare l'opzione <tt>-S</tt> di <prgn>dpkg-buildpackage</prgn>). L'infrastruttura <prgn>buildd</prgn> non ne effettuerà il build. Questo si applica anche agli upload di pacchetti normali. <item>A meno che il sorgente upstream sia stato precedentemente inviato in upload a security.debian.org (da un precedente aggiornamento di sicurezza), costruisci l'upload con tutti i sorgenti upstream (<tt>dpkg-buildpackage -sa</tt>). Se c'è stato un precedente upload a security.debian.org con la stessa versione upstream, puoi inviare l'upload senza il sorgente upstream (<tt>dpkg-buildpackage -sd</tt>). <item>Assicurati di usare esattamente lo stesso <file>*.orig.tar.gz</file> usato nell'archivio normale, altrimenti non sarà in seguito possibile spostare il fix di sicurezza nell'archivio principale. <item>Effettua il build del pacchetto su un sistema pulito che ha pacchetti installati solo dalla distribuzione per cui stai effettuando il build. Se non possiedi un sistema così, puoi usare una macchina debian.org (see <ref id="server-machines">) o impostare un chroot (vedi <ref id="pbuilder"> e <ref id="debootstrap">). </list> <sect2 id="bug-security-upload">Upload del pacchetto sistemato NON effettuare un upload alla coda di upload di sicurezza (oldstable-security, stable-security, ecc.) senza avere precedentemente ottenuto l'autorizzazione dal team di sicurezza. Se il pacchetto non soddisfa pienamente le richieste del team, porterà numerosi problemi e ritardi durante la gestione dell'upload non voluto. NON inviare i tuoi fix a proposed-updates senza ccordinarti con il team di sicurezza. I pacchetti da security.debian.org saranno automaticamente copiati nella directory proposed-updates. Se un pacchetto con lo stesso o più alto numero di versione è già installato all'interno dell'archivio, l'aggiornamento di sicurezza sarà rifiutato dal sistema dell'archivio. In quel modo, invece, la distribuzione stable finirà senza un aggiornamento di sicurezza per questo pacchetto. Una volta che hai creato e controllato il nuovo pacchetto ed è stato approvato dal team di sicurezza, deve essere inviato in upload in modo che possa essere installato negli archivi. Per gli aggiornamenti di sicurezza, il posto in cui inviare l'upload è <tt>ftp://security.debian.org/pub/SecurityUploadQueue/</tt> . Una volta che un upload alla coda di sicurezza è stato accettato, il pacchetto sarà automaticamente ricostruito per tutte le architetture e messo da parte per la verifica dal team di sicurezza. Gli upload in attesa di essere accettati o verificati sono accessibili solo dal team di sicurezza. Questo è necessario siccome ci possono essere dei fix per problemi di sicurezza che non possono ancora essere divulgati. Se un membro del team di sicurezza accetta un pacchetto, questo sarà installato su security.debian.org così come nella giusta <var>distribution</var>-proposed-updates su ftp-master o nell'archivio non-US. <sect id="archive-manip"> <heading>Spostare, rimuovere, rinominare, adottare e abbandonare pacchetti</heading> Alcune operazioni di manipolazione dell'archivio non sono automatizzate nel processo di upload Debian. Queste procedure dovrebbero essere seguite manualmente dai mantainers. Questo capitolo fornisce delle linee guida su cosa fare in questi casi. <sect1 id="moving-pkgs">Spostare pacchetti A volte un pacchetto cambia la propria sezione. Per esempio, un pacchetto dalla sezione `non-free' potrebbe cambiare la propria licenza in GPL in una successiva versione, in qual caso il pacchetto dovrebbe essere spostato in `main' oppure `contrib'. <footnote> Vedi la <url id="&url-debian-policy;" name="Policy Debian"> per le linee guida su a quale sezione appartiene un pacchetto.</footnote> Se devi cambiare la sezione di uno dei tuoi pacchetti, cambia le informazioni di controllo del pacchetto per posizionarlo sella sezione desiderata, e invialo nuovamente in upload (vedi la <url id="&url-debian-policy;" name="Policy Debian"> per i dettagli). Se la tua nuova sezione è valida, sarà spostato automaticamente. Se ciò non accade, contatta gli ftpmasters per comprendere cosa è successo. Se, d'altro canto, devi cambiare la subsection di uno dei tuoi pacchetti (p.es. ``devel'', ``admin''),la procedura è leggermente diversa. Correggi la sottosezione come appare nel file di controllo del pacchetto, e invialo nuovamente in upload. In aggiunta, avrai bisogno di far sì che il file override venga aggiornato, come descritto in <ref id="override-file">. <sect1 id="removing-pkgs">Rimuovere pacchetti Se per qualche ragione vuoi completamente rimuovere un pacchetto (per dire, se è una vecchia libreria di compatibilità che non è più necessaria), devi mandare un bug contro <tt>ftp.debian.org</tt> chiedendo che il pacchetto venga rimosso. Assicurati di indicare da quale distribuzione debba venire rimosso il pacchetto. Normalmente, puoi rimuovere pacchetti solo da unstable ed experimental. I pacchetti non vengono rimossi da testing direttamente. Piuttosto, verranno automaticamente rimossi dopo che il pacchetto sia stato rimosso da unstable e nessun pacchetto dipenda da esso. Devi anche giustificare la richiesta spiegandone in dettaglio i dettagli. Ciò per evitare rimozioni indesiderate e tenere traccia del perchè un pacchetto è stato rimosso. Per esempio, puoi fornire il nome del pacchetto che sostituisce quello da rimuovere. Di solito puoi chiedere la rimozione solo di un pacchetto mantenuto da te stesso. Se vuoi rimuovere un altro pacchetto, devi ottenere l'autorizzazione del suo mantainer. Se sei in dubbio sul fatto che un pacchetto sia disponibile o meno, manda un email a &email-debian-devel; chiedendo altre opinioni. È inoltre interessante il programma <prgn>apt-cache</prgn> del pacchetto <package>apt</package>. Quando viene lanciato come <tt>apt-cache showpkg <var>package</var></tt>, il programma mostrerà i dettagli di <var>package</var>, incluse le dipendenze inverse. La rimozione dei pacchetti abbandonati è discussa su &email-debian-qa;. Una volta che il pacchetto è stato rimosso, bisognerebbe gestirne i bug. Dovrebbero o essere riassegnati a un altro pacchetto nel caso in cui il codice reale si sia evoluto in un altro pacchetto (p.es. <tt>libfoo12</tt> è stato rimosso perchè <tt>libfoo13</tt> lo sostituisce) oppure chiusi se semplicemente il software non fa più parte di Debian. <sect2>Rimuovere pacchetti da <file>Incoming</file> In passato, era possibile rimuovere pacchetti da <file>incoming</file>. Comunque, con l'introduzione del nuovo sistema di incoming, ciò non è più possibile. Piuttosto, devi inviare in upload una nuova revisione del tuo pacchetto con una versione superiore a quella del pacchetto che hai intenzione di sostituire. Entrambe le versioni verranno installate all'interno dell'archivio ma solo la versione più alta sarà realmente disponibile in unstable, siccome la versione precedente sarà immediatamente sostituita dalla più alta. Comunque, se controlli correttamente i tuoi pacchetti, il bisogno di sostituire un pacchetto non dovrebbe succedere troppo spesso. <sect1>Rimpiazzare o rinominare pacchetti Quando sbagli a dare il nome al tuo pacchetto, dovresti seguire un processo composto da due fasi per rinominarlo. Prima di tutto, imposta il tuo file <file>debian/control</file> per sostituire ed essere in conflitto  con il nome obsoleto del pacchetto (vedi la <url id="&url-debian-policy;" name="Policy Debian"> per i dettagli). Una volta che hai effettuato l'upload del pacchetto e che il pacchetto stesso è stato spostato nell'archivio, invia un bug contro <tt>ftp.debian.org</tt> chiedendo di rimuovere il pacchetto con il nome vecchio. Allo stesso tempo non dimenticare di riassegnare propriamente i bug del pacchetto. Altre volte, puoi commettere uno sbaglio mentre costruisci il tuo pacchetto e volerlo sostituire. Il solo modo di farlo è di aumentare il numero di versione è inviare in upload una nuova versione. La vecchia versione scadrà nel solito modo. Nota che questo si applica in ogni parte del tuo pacchetto, sorgenti compresi: se vuoi rimpiazzare la tarball dei sorgenti upstream del tuo pacchetto, dovrai inviarlo in upload con una versione differente. Una semplice possibilità è di sostituire <file>foo_1.00.orig.tar.gz</file> con <file>foo_1.00+0.orig.tar.gz</file>. Questa restrizione dà a ogni file sul sito ftp un nome unico, cosa che aiuta ad assicurare consistenza attraverso la rete dei mirror. <sect1 id="orphaning">Abbandonare un pacchetto Se non sei più in grado di mantenere un pacchetto, devi informare gli altri di questo, e vedere che il pacchetto sia marcato come orphaned.  Dovresti impostare il mantainer del pacchetto a <tt>Debian QA Group &orphan-address;</tt> e inviare un bug report contro il pseudo-pacchetto <package>wnpp</package>. Il bug report dovrebbe essere intitolato <tt>O: <var>package</var> -- <var>short description</var></tt> indicando che il pacchetto è ora abbandonato. La severità del bug dovrebbe essere impostata a normal. Se pensi che sia necessario, mandane una copia a &email-debian-devel; mattendo l'indirizzo nell'header X-Debbugs-CC: del messaggio (no, non usare CC:, in quel modo l'oggetto del messaggio non indicherà il numero del bug). Se il pacchetto è specialmente cruciale per Debian, dovresti invece mandare un bug contro <package>wnpp</package> e intitolarlo: <tt>RFA: <var>package</var> -- <var>short description</var></tt> e impostarne la severità a important. <tt>RFA</tt> sta per Request For Adoption (richiesta di adozione). In questo caso mandane certamente una copia a debian-devel, come descritto poc'anzi. Leggi le istruzioni sulle <url id="&url-wnpp;" name="pagine web WNPP"> per ulteriori informazioni. <sect1 id="adopting">Adottare un pacchetto Una lista dei pacchetti che necessitano un nuovo mantainer è disponibile nella <url name="lista dei pacchetti futuri e in bisogno di lavoro (WNPP)" id="&url-wnpp;">.  Se vuoi prenderti in carica la manutenzione di qualsiasi pacchetto elencato nella WNPP, per favore guarda la succitata pagina per informazioni e conoscere le procedure da seguire. Non è corretto semplicemente rilevare un pacchetto che pensi sia trascurato — questo sarebbe un hijacking di pacchetti. Puoi certamente contattare il mantainer corrente e chiedergli se puoi prendere il pacchetto sotto la tua custodia. Se hai delle ragioni per credere che un mantainer è andato "AWOL" (absent without leave) , vedi <ref id="mia-qa">. Generalmente, non puoi prendere il possesso del pacchetto senza il consenso del mantainer corrente. Anche se ti ignorano, non ci sono lo stesso le basi per rilevare un pacchetto. Le lamentele sui mantainer dovrebbero essere fatte sulla mailing list degli sviluppatori. Se la discussione non si conclude in modo positivo, e il problema è di natura tecnica, considera la possibilità di portarlo all'attenzione del comitato tecnico (vedi la <url name="pagina web del comitato tecnico" id="&url-tech-ctte;"> per ulteriori informazioni). Se rilevi un vecchio pacchetto, probabilmente vuoi essere elencato come il mantainer ufficiale del pacchetto nel sistema dei bug. Questo avverrà automaticamente una volta che effettui un upload di una nuova versione con il campo <tt>Maintainer:</tt> aggiornato, anche se ci vorrà qualche ora dopo che l'upload è stato fatto. Se non ti aspetti di effettuare alcun upload di una nuova versione per un po' di tempo, puoi usare <ref id="pkg-tracking-system"> per ottenere i bug report. Assicurati comunque che il vecchio mantainer non abbia dei problemi a continuare a ricevere i bug durante quel periodo. <sect id="porting">Porting  Debian supporta sempre più architetture. Anche se non sei un porter, e usi una sola architettura, fa parte dei tuoi doveri di mantainer essere conscio dei problemi relativi alla portabilità. Quindi, anche se non sei un porter, dovresti comunque leggere buona parte di questo paragrafo. Il porting è l'atto di costruire pacchetti Debian per architetture diverse da quella originaria del mantainer del pacchetto binario. È un'attività unica ed essenziale. Infatti, i porter effetuano la maggior parte della compilazione reale di pacchetti Debian. Per esempio, per ogni singolo pacchetto binario per i386, deve esserci una ricompilazione per ogni architettura, il che significa &number-of-arches; ulteriori build. <sect1 id="kind-to-porters">Essere cortesi con i porter I porters hanno un compito difficile e unico, dovendo avere a che fare con un grande numero di pacchetti. Idealmente, ogni pacchetto sorgente dovrebbe riuscire nel build al primo colpo. Sfortunatamente ciò spesso non accade. Questa sezione contiene una lista di errori <-- FIXME: era gotchas --> commessi di frequente dai mantainer Debian — problemi comuni che spesso pesano sui porter e rendono il loro lavoro inutilmente difficile. La prima e più importarte cosa è rispondere velocemente ai bug o problemi sollevati dai porter. Per favore sii cortese con i porter, come se fossero co-mantainer del tuo pacchetto (e in un certo senso lo sono). Per favore sii tollerante con bug report succinti o persino non chiari, fa del tuo meglio per ricercare cosa sia il problema. Ad oggi, la maggior parte dei problemi incontrati dai porter sono causati da bug di pacchettizzazione nei pacchetti sorgenti. Ecco una lista di cose che dovresti controllare o esserne a conoscenza. <enumlist> <item> Assicurati che i settaggi <tt>Build-Depends</tt> e <tt>Build-Depends-Indep</tt> nel tuo <file>debian/control</file> siano correttamente impostati. Il miglior modo per assicurarsene è quello di usare il pacchetto <package>debootstrap</package> per creare un ambiente chroot unstable (vedi <ref id="debootstrap">). All'interno di quell'ambiente chroot, installa il pacchetto <package>build-essential</package> e tutte le dipendenze menzionate nei campi <tt>Build-Depends</tt> e/o <tt>Build-Depends-Indep</tt>. Dopodichè prova a fare il build del tuo pacchetto all'interno di quell'ambiente chroot. Questo procedimento può essere automatizzato tramite l'uso del programma <prgn>pbuilder</prgn> il quale è fornito dal pacchetto omonimo (vedi <ref id="pbuilder">). Se non puoi impostare un chroot corretto, <prgn>dpkg-depcheck</prgn> può aiutarti (vedi <ref id="dpkg-depcheck">). Vedi la <url id="&url-debian-policy;" name="Policy Debian"> per istruzioni su come impostare le dipendenze di build. <item> Non impostare ``architecture'' a un valore diverso da ``all'' o ``any'' a meno che tu non sappia cosa stai facendo. In troppi casi i mantainer non seguono le istruzioni della <url id="&url-debian-policy;" name="Policy Debian">. Impostare la tua architettura a ``i386'' è generalmente sbagliato. <item> Assicurati che il tuo pacchetto sorgente sia corretto. Lancia <tt>dpkg-source -x <var>package</var>.dsc</tt> per essere sicuro che il tuo pacchetto sorgente si decomprima correttamente. Dopodichè, da lì, prova a effettuare il build del tuo pacchetto da zero con <prgn>dpkg-buildpackage</prgn>. <item> Assicurati di non inserire nel pacchetto sorgente i file <file>debian/files</file> o <file>debian/substvars</file>. Questi file dovrebbero essere rimossi dal target `clean' di <file>debian/rules</file>. <item> Assicurati di non fare affidamento su programmi installati in locale o su particolari configurazioni. Per esempio, non dovresti mai chiamare programmi in <file>/usr/local/bin</file> o simili. Prova a non fare affidamento a programmi impostati in modo speciale. Prova a fare il build del tuo pacchetto su un altra macchina, anche se della stessa architettura. <item> Non dipendere dal fatto che il pacchetto che stai costruendo sia già installato (un sotto-caso del problema sopra descritto). <item> Non dipendere se possibile dal fatto che il compilatore sia di una certa versione. Se non è possibile, assicurati che le tue dipendenze di build rifletta la restrizione, anche se stai probabilmente cercando dei guai, siccome a volte architetture diverse hanno dei compilatori standard diversi. <item> Assicurati che il tuo debian/rules contenga separatamente i target ``binary-arch'' e ``binary-indep'', come richiede la Policy Debian. Assicurati che i due target lavorino in modo indipendente tra di loro, il che significa che si possa invocarne uno senza prima aver invocato l'altro. Per provarlo, prova a lanciare <tt>dpkg-buildpackage -B</tt>. </enumlist> <sect1 id="porter-guidelines">Linee guida per gli upload dei porter Se il pacchetto effettua il build senza problemi sull'architettura su cui si deve fare il porting, sei fortunato e il tuo lavoro sarà facile. Questa sezione si applica per questi casi; descrive come fare il build e l'upload del tuo pacchetto binario in modo che sia propriamente installato nell'archivio. Se devi apportare delle correzioni al pacchetto per fare in modo che possa essere compilato per l'altra architettura, stai in realtà effettuando un NMU, qundi devi invece consultare <ref id="nmu-guidelines">. Per un upload del porter, non si apporta alcuna modifica al sorgente. Non hai bisogno di toccare nessuno dei file nel pacchetto sorgente. Ciò include anche <file>debian/changelog</file>. Il modo invocare <prgn>dpkg-buildpackage</prgn> è <tt>dpkg-buildpackage -B -m<var>porter-email</var></tt>. Ovviamente imposta <var>porter-email</var> con il tuo indirizzo email. Questo effettuerà il build binario solo per le parti del pacchetto dipendenti dall'architettura, usando il target `binary-arch' in <file>debian/rules</file>. <sect2 id="binary-only-nmu"> <heading>Ricompilazione di NMU esclusivamente binari</heading> A volte l'upload iniziale del porter è problematico in quanto l'ambiente in cui è stato costruito il pacchetto non è abbastanza buono (librerie vecchie o obsolete, cattivo compilatore, ...). In tal caso potresti semplicemente doverlo ricompilare in un ambiente aggiornato. In questo caso, devi incrementare il numero di versione, in modo che il vecchio pacchetto non funzionante possa essere rimpiazzato nell'archivio Debian (<prgn>katie</prgn> si rifiuta di installare nuovi pacchetti se non hanno un numero di versione maggiore rispetto a quello correntemente disponibile). Nonostante le modifiche richieste al changelog, queste sono chiamate NMU solo binari — in questo caso non c'è bisogno di fare scattare tutte le altre architetture per considerarsi superate o richiederne la ricompilazione. Tali ricompilazioni richiedono una speciale ``magica'' numerazione di versione, in modo che gli strumenti di manutenzione dell'archivio riconoscano che, sebbene ci sia una nuova versione Debian, non esiste un corrispondente aggiornamento dei sorgenti. Se sbagli, i mantainer dell'archivio respingeranno il tuo upload (dovuto alla mancanza del corrispondente codice sorgente). La ``magia'' per un NMU solo di ricompilazione viene fatta scattare usando il numero di terzo livello sulla parte Debian del numero di versione. Per esempio, se stai ricompilando la versione ``2.9-3'', il tuo NMU dovrebbe avere versione ``2.9-3.0.1''. Se l'ultima versione era``3.4-2.1'', il tuo NMU dovrebbe avere il numero di versione``3.4-2.1.1''. <sect2 id="source-nmu-when-porter"> <heading>Quando fare un NMU di sorgenti se sei un porter</heading> I porter che effettuano un NMU di sorgenti seguono generalmente le linee guida trovate in <ref id="nmu">, esattamente come gli altri. Comunque, ci si aspetta che il ciclo di attesa per un NMU sorgente di un porter sia minore rispetto per uno normale, siccome i porter devono far fronte a una grande quantità di pacchetti. Di nuovo, la situazione cambia dipendentemente dalla distribuzione su cui si vuole effettuare l'upload.  Comunque, se sei un porter e stai facendo un NMU per `unstable', dovresti seguire le linee guida sopra descritte, con due variazioni. Primo, il tempo di attesa accettabile — il tempo tra quando il bug è inviato al BTS e quando va bene fare un NMU — è di sette giorni per i porter che lavorano sulla distribuzione unstable. Questo periodo può essere accorciato se il problema è critico e ostacola l'attività di porting, a discrezione del gruppo dei porter. (Ricorda, niente di tutto ciò è Policy, ma solo accordi sulle linee guida.) Secondo, i porter che effettuano NMU di sorgenti dovrebbero assicurarsi che il bug che inviano al BTS dovrebbe essere di severità `serious' o maggiore. Ciò assicura che un singolo pacchetto sorgente possa essere compilato su tutte le architetture supportate da Debian al tempo del rilascio. È molto importante il fatto di avere una versione del pacchetto binario e sorgente per tutte le architetture in modo da soddisfare i requisiti di molte licenze. I porter dovrebbero provare a evitare patch che girano semplicemente attorno a bug nella versione corrente dell'ambiente di compilazione, del kernel, o delle libc. A volte questi kludge non si possono evitare. Se devi girare attorno a bug del compilatore e cose simili, assicurati di definire propriamente il tuo lavoro con <tt>#ifdef</tt>; inoltre, documenta i kludge che fai in modo che la gente possa sapere come rimuoverli una volta che il problema esterno è stato risolto. I porter possono anche avere un posto non ufficiale dove riporre i risultati del proprio lavoro durante il periodo di attesa. Ciò aiuta gli altri che usano il port a trarne beneficio anche durante il periodo di attesa. Ovviamente tali locazioni non hanno nessuna 'benedizione' ne riscontro ufficiale, quindi i clienti sono avvisati. <sect1 id="porter-automation"> <heading>Infrastrutture e automazione nel porting</heading> Esiste un'infrastruttura e diversi strumenti per aiutare ad automatizzare il porting dei pacchetti. Questa sezione contiene una breve vista d'insieme di questa automazione e di questi strumenti; leggi la documentazione del pacchetto o altri riferimenti per le informazioni complete. <sect2> <heading>Mailing list e pagine web</heading> Le pagine web contenenti lo stato di ogni port si trovano all'indirizzo <url id="&url-debian-ports;">. Ogni port di Debian ha la propria mailing list. La lista delle mailing list dei porting si trova all'indirizzo <url id="&url-debian-port-lists;">. Queste liste sono usate per coordinare i porter e per mettere in contatto gli utenti di un dato port con i porter. </sect2> <sect2> <heading>Strumenti dei porter</heading> Le descrizioni dei diversi strumenti per il porting si trovano in <ref id="tools-porting">. </sect2> <sect2 id="buildd"> <heading><package>buildd</package></heading> Il sistema <package>buildd</package> è usato come un sistema distribuito client-server di build delle distribuzioni. Di solito è usato insieme a auto-builders, che sono host ``slave'' che semplicemente controllano e cercano di fare il build automatico dei pacchetti dei quali si deve effettuare il porting. Esiste anche un'interfaccia email al sistema, che permette ai porter di controllare un pacchetto sorgente (di solito uno di cui non si puo' ancora fare il build automaticamente) e lavorarci sopra. <package>buildd</package> non è ancora disponibile come pacchetto; comunque, la maggior parte dei porter o lo stanno correntemente usando o pianificando di usarlo in un futuro non lontano. Il builder reale è pacchettizzato come <package>sbuild</package>, vedi la sua descrizione in <ref id="sbuild">. Il sistema <package>buildd</package> completo include anche un certo numero di componenti ancora da pacchettizzare molto utili che vengono usati continuamente, come <prgn>andrea</prgn> e <prgn>wanna-build</prgn>. Una parte delle informazioni prodotte da <package>buildd</package> che sono generalmente utili ai porter sono disponibili sul web all'indirizzo <url id="&url-buildd;">. Queste informazioni includono le informazioni aggiornate giornalmente  da <prgn>andrea</prgn> (dipendenze dei sorgenti) e <package>quinn-diff</package> (pacchetti che necessitano una ricompilazione). Siamo abbastanza fieri di questo sistema, siccome ha tanti usi possibili. Gruppi di sviluppatori indipendenti possono usare il sistema per diverse varianti secondarie di Debian, che possono essere o meno di interesse generale (per esempio, una versione di Debian costruita con il bound-checking di <prgn>gcc</prgn>). Renderà inoltre Debian in grado di ricompilare velocemente intere distribuzioni. </sect2> <sect id="nmu">Non-Maintainer Upload (NMU) In certe circostanze è necessario per qualcuno che non sia il mantainer ufficiale del pacchetto effettuarne una release. Questo è chiamato un non-maintainer upload, in breve NMU. I porter Debian, i quali compilano i pacchetti per differenti architetture, effettuano occasionalmente dei NMU solo binari come parte della loro attività di porter (vedi <ref id="porting">). Un altra ragione per cui vengono fatti dei NMU è quando uno sviluppatore Debian necessita di correggere pacchetti di altri sviluppatori in modo da indirizzare seri problemi di sicurezza o bug paralizzanti, specialmente durante il periodo di freeze, o quando il mantainer del pacchetto non è in grado di risolvere il problema in tempi ragionevoli. Questo capitolo contiene informazioni che forniscono le linee guida su quando e come dovrebbero essere fatti i NMU. Una distinzione fondamentale è fatta tra NMU di sorgenti e solo binari, spiegata nella prossima sezione. <sect1 id="nmu-terms">Terminologia Ci sono due nuovi termini usati all'interno di questa sezioni: ``NMU solo binari'' e ``NMU di sorgenti''. Questi termini vengono usati con dei significati tecnici specifici in tutto questo documento. NMU di sorgenti e solo binari sono simili tra loro, siccome implicano entrambi un upload di un pacchetto da uno sviluppatore che non è il mantainer ufficiale del pacchetto. Ecco perchè è un non-maintainer upload. Un NMU di sorgenti è un upload di un pacchetto fatto da uno sviluppatore che non è il mantainer ufficiale del pacchetto, fatto per risolvere un baco del pacchetto. Gli NMU di sorgenti implicano sempre delle modifiche al sorgente (anche se è solo una modifica al <file>debian/changelog</file>). Cio può essere sia una modifica al sorgente upstream o una modifica alla parte Debian del sorgente. Nota, comunque, che NMU di sorgenti possono anche includere pacchetti dipendenti dall'architettura, così come una diff Debian aggiornata. Un NMU solo binario è una ricompilazione e upload di un pacchetto binario per una certa architettura. Di solito è parte di un lavoro di porting. Un NMU solo binario è un upload, non effettuato dal suo mantainer, della versione binaria del pacchetto, senza che siano richieste modifiche ai sorgenti. Ci sono diversi casi in cui i porter devono risolvere dei problemi nei sorgenti per farli compilare nella loro architettura; questo sarebbe considerato un NMU di sorgenti piuttosto che un NMU solo binario. Come puoi vedere, non facciamo alcuna distinzione nella terminologia tra NMU di porter e NMU non di porter. Entrambe le classi di NMU, di sorgenti e solo binari, possono essere riferite con il termine generico ``NMU''. Ciò nonostante, questo causa spesso confusione, in quanto per molta gente ``NMU'' significa ``NMU di sorgenti'', quindi è meglio fare attenzione. In questo capitolo, se usiamo il termine generico ``NMU'' ci riferiamo a qualunque tipo di non-mantainer upload, che sia di entrambi (sorgenti e binari) o solo di binari. <sect1 id="nmu-who">Chi può fare un NMU Solo i mantainer Debian ufficiali e registrati possono fare NMU binari o di sorgenti, Un mantainer ufficiale è qualcuno che ha la sua chiave nel keyring Debian. I non sviluppatori, comunque, sono incoraggiati a scaricare il pacchetto sorgente e iniziare a lavorarci su per risolvere i problemi; comunque, piutosto che fare un NMU, dovrebbero semplicemente inviare patch al sistema di tracciamento dei bug. I mantainer quasi sempre apprezzano le patch di qualità e i bug report. <sect1 id="nmu-when">Quando fare un NMU di sorgenti Le linee guida su quando fare un NMU di sorgenti dipendono dalla distribuzione bersaglio, ovvero stable, unstable o experimental. I porter hanno delle regole leggermente differenti rispetto ai non-porter, a causa delle loro circostanze uniche (vedi <ref id="source-nmu-when-porter">). Quando viene trovato un bug di sicurezza, il team di sicurezza può effettuare un NMU. Per favore vedi <ref id="bug-security"> per ulteriori informazioni. Durante il ciclo di rilascio (vedi <ref id="sec-dists">), gli NMU che sistemano bug di sicurezza di severità uguale o maggiore a serious sono incoraggiati e accettati. Anche in questo caso dovresti comunque adoperarti per contattare il mantainer del pacchetto; potrebbe stare giusto per inviare in upload un fix per il problema. Come per qualunque NMU di sorgenti, devono essere seguite le linee guida in <ref id="nmu-guidelines">. Si fanno eccezioni speciali per <ref id="qa-bsp">. Upload di fix per bug in unstable dovrebbero essere fatti solo rispettando questo protocollo: <list> <item> Assicurati che i bug a cui è indirizzato a risolvere il NMU sono tutti schedati nel sistema di tracciamento dei bug (BTS). Se non lo sono, inviali immediatamente. <item> Aspetta qualche giorno la risposta dal mantainer. Se non ricevi alcuna risposta, puoi se vuoi aiutarli inviando la patch che sistema il bug. Non dimenticare di marcare il bug con la parola chiave "patch". <item> Aspetta ancora qualche giorno. Se ancora non ricevi risposta dal mantainer, scrivigli una email annunciando la tua intenzione di fare un NMU sul pacchetto. Prepara un NMU come descritto in <ref id="nmu-guidelines">, controllalo attentamente sulla tua macchina (vedi <ref id="sanitycheck">). Controlla doppiamente che la tua patch non abbia alcun inaspettato effetto collaterale. Assicurati che la tua patch sia più piccola e non distruttiva possibile. <item> Invia il pacchetto in upload a incoming in <file>DELAYED/7-day</file> (vedi <ref id="delayed-incoming">), manda la patch definitiva al mantainer via BTS e spiegagli che hanno 7 giorni per reagire se vogliono cancellare l'NMU. <item> Segui quello che accade, sei responsabile per qualsiasi bug tu abbia introdotto con il tuo NMU. Probabilmente dovresti usare <ref id="pkg-tracking-system"> (PTS) per essere informato dello stato del pacchetto dopo il tuo NMU. </list> A volte, il release manager di un gruppo organizzato di sviluppatori può annunciare un certo periodo di tempo in cui le regole sugli NMU vengono rese meno severe. Questo di solito implica l'accorciamento del periodo di attesa che precede l'invio dei fix e del periodo DELAYED. È importante notare che anche durante i cosiddetti "bug squashing party", colui che esegue l'NMU deve prima inviare i bug e contattare lo sviluppatore e poi agire. <sect1 id="nmu-guidelines">Come fare un NMU di sorgenti Ciò che segue si applica ai porter finchè giocano il doppio ruolo di bug-fixer e porter di pacchetti. Se un porter deve modificare l'archivio dei sorgenti Debian, il suo upload è automaticamente un NMU di sorgenti ed è soggetto alle sue regole. Se un porter sta solo inviando in upload un pacchetto binario ricompilato, le regole sono differenti; vedi <ref id="porter-guidelines">. Prima di tutto è essenziale che le patch NMU dovrebbero essere meno distruttive possibile per i sorgenti. Non fare dell'housekeeping di task , non cambiare il nome di moduli o di file, non spostare directory; in generale, non aggiustare niente che non sia rotto. Rendi la patch più piccola possibile. Se ci sono cose che esteticamente non ti piacciono, parlane al mantainer Debian, parlane al mantainer upstream, o riporta un bug. In ogni caso, modifiche estetiche non devono essere fatte in un non-maintainer upload. <sect2 id="nmu-version">Numerazione versioni NMU di sorgenti Ogni volta che fai delle modifiche ad un pacchetto, anche banali, devi cambiare il numero di versione. Questo permette al nostro sistema di funzionare. Se stai facendo un non-maintainer upload (NMU), dovresti aggiungere un nuovo numero di versione minore alla parte <var>debian-revision</var> del numero di versione (la parte dopo l'ultimo trattino). Questo numero extra minore comincerà da `1'. Per esempio, considera il pacchetto `foo', che è alla versione 1.1-3. Nell'archivio, il file di controllo del sorgente del pacchetto sarebbe <file>foo_1.1-3.dsc</file>. La versione upstream è `1.1' e la revisione Debian è `3'. Il successivo NMU aggiungerebbe un nuovo numero minore `.1' alla revisione Debian; il nuovo file di controllo del sorgente sarebbe <file>foo_1.1-3.1.dsc</file>. Il numero minore della revisione Debian serve per evitare di rubare uno dei numeri di versione dei mantainer del pacchetto, che potrebbe distruggere il loro lavoro. Ha anche il vantaggio di rendere visibilmente chiaro che un pacchetto nell'archivio non è stato fatto dal mantainer ufficiale. Se non c'è nessuna componente <var>debian-revision</var> nel numero di versione ne dovrebbe essere creata una, cominciando da `0.1'. Se è assolutamente necessario per qualcuno che non sia il solito mantainer rilasciare una release basata su una nuova versione upstream, questa persona dovrebbe cominciare con il valore <var>debian-revision</var> a `0.1'. Il mantainer ufficiale di un pacchetto dovrebbe cominciare la sua numerazione <var>debian-revision</var> con `1'. <sect2 id="nmu-changelog"> <heading>Gli NMU di sorgenti devono avere una nuova voce di changelog</heading> Un non-mantainer che fa un NMU di sorgenti deve creare una voce di changelog, descrivendo quali bug sono sistemati dal NMU, e generalmente perchè era richiesto un NMU e cosa ha risolto. La voce di changelog avrà l'indirizzo email del non-mantainer nella voce di log e il numero della versione del NMU in essa. Per consuetudine, le voci di changelog degli NMU di sorgenti cominciano con la linea <example> * Non-maintainer upload </example> <sect2 id="nmu-patch">NMU di sorgenti e il sistema di tracciamento dei bug I mantainer diversi dal mantainer ufficiale del pacchetto dovrebbero fare meno modifiche possibili al pacchetto, e dovrebbero sempre mandare una patch nel formato "unified context diff" (<tt>diff -u</tt>) spiegando i dettagli delle loro modifiche al sistema di tracciamento dei bug. E se stai semplicemente ricompilando il pacchetto? Se hai solo bisogno di ricompilarlo per una singola architettura puoi fare un NMU solo binario come descritto in <ref id="binary-only-nmu"> il che non richiede l'invio di alcuna patch. Se vuoi che il pacchetto venga ricompilato per tutte le architetture, fai un NMU di sorgenti come al solito e dovrai spedire una patch. Se il NMU (non-mantainer upload) di sorgenti risolve qualche bug esistente, tali bug piuttosto che essere chiusi dovrebbero essere marcati come fixed nel sistema di tracciamento dei bug. Per convenzione, solo il mantainer ufficiale del pacchetto o chi ha originariamente riportato il bug sono autorizzati a chiudere bug. Fortunatamente il sistema dell'archivio Debian riconosce i NMU e quindi marca appropriatamente i bug sistemati dal NMU se chi lo ha inviato ha elencato tutti i bug nel changelog con la sintassi <tt>Closes: bug#<var>nnnnn</var></tt>(vedi <ref id="upload-bugfix"> per ulteriori informazioni su come chiudere bug attraverso il changelog). Marcare i bug fixed assicura che tutti sappiano che il bug è stato risolto in un NMU; comunque il bug è lasciato aperto finche le modifiche fatte nel NMU non siano ufficialmente incorporate nel pacchetto dal suo mantainer ufficiale. Inoltre, dopo aver fatto un NMU, devi aprire un nuovo bug e includere una patch mostrando tutte le modifiche che hai apportato. In alternativa puoi mandare quelle informazioni ai bug esistenti che sono stati sistemati dal tuo NMU. Il mantainer normale o applicherà la patch o impiegherà un metodo alternativo per risolvere il problema. A volte i bug sono sistemati a monte in modo indipendente, che è un altra buona ragione per annullare le modifiche fatte dalla patch NMU. Se il mantainer decide di non applicare la patch NMU ma di rilasciare una nuova versione, egli deve assicurarsi che la nuova versione upstream risolva sul serio ogni problema che è stato sistemato nella release del non-mantainer. In aggiunta, il mantainer normale dovrebbe sempre conservare la voce nel changelog che documenta il non-mantainer upload. <sect2 id="nmu-build">Costruire NMU di sorgenti I NMU di sorgenti dei pacchetti sono costruiti normalmente. Scegli una distribuzione usando le stesse regole trovate in <ref id="distribution">, segui le altre prescrizioni in <ref id="upload">. Assicurati di non cambiare il valore del mantainer nel file <file>debian/control</file>. Il tuo nome come dato nella voce del NMU del file <file>debian/changelog</file> sarà usato per firmare il file changes. <sect1 id="ack-nmu">Riconoscere un NMU Se viene effettuato un NMU su uno dei tuoi pacchetti, devi incorporare le modifiche nella tua copia dei sorgenti. Questo è facile, devi solo applicare la patch che ti è stata spedita. Una volta che l'hai fatto, devi chiudere i bug che sono stati marcati come fixed dal NMU. Puoi chiuderli o manualmente mandando le mail richieste al BTS o aggiungendo le richieste <tt>closes: #nnnn</tt> nella voce del changelog del tuo prossimo upload. In ogni caso, non dovresti essere arrabbiato per il NMU. Un NMU non è un attacco personale nei confronti del mantainer, è una prova che qualcuno tiene abbastanza al pacchetto da volerti aiutare nel tuo lavoro, quindi dovresti esserne grato. Potresti anche volergli chiedere se sarebbero interessati ad aiutarti più frequentemente come co-mantainer o mantainer di riserva (vedi <ref id="collaborative-maint">). <sect id="collaborative-maint"> <heading>Manutenzione collaborativa</heading> "Manutenzione collaborativa" è un termine che descrive la condivisione dei compiti di manutenzione di pacchetti da parte di più persone. Questa collaborazione è quasi sempre una buona idea, siccome porta a una maggiore qualità e velocizza i tempi di sistemazione dei bug. È fortemente raccomandato che i pacchetti con una priorità <tt>Standard</tt> o che fanno parte del sistema base abbiano dei co-mantainer. Generalmente c'è un mantainer principale e uno o più co-mantainer. Il mantainer principale è la persona il cui nome è elencato nel campo <tt>Maintainer</tt> del file <file>debian/control</file>. I co-mantainer sono tutti gli altri. Nella sua forma di base, il processo di aggiungere un nuovo co-mantainer è abbastanza semplice: <list> <item> Dai al co-mantainer accesso ai sorgenti da cui costruisci il pacchetto. Generalmente questo implica l'uso di un sistema di controllo di versione network-capable, come <prgn>CVS</prgn> o <prgn>Subversion</prgn>. </item> <item> Aggiungi il nome e l'indirizzo corretti del maintainer al campo <tt>Uploaders</tt> nella sezione globale del file <file>debian/control</file>. <example> Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org> </example> </item> <item> Usando il PTS (<ref id="pkg-tracking-system">), i co-maintainer dovrebbero iscriversi all'appropriato pacchetto sorgente. </item> </list> La manutenzione collaborativa spesso può essere ulteriormente facilitata con l'uso degli strumenti su Alioth (vedi <ref id="alioth">). </sect> <chapt id="best-pkging-practices"> <heading>Procedimenti di pacchetizzazione consigliati</heading> La qualità di Debian è in gran parte dovuta alla <url id="&url-debian-policy;" name="policy Debian">, che definisce degli espliciti requisiti di base a cui tutti i pacchetti Debian devono conformarsi. C'è anche ormai un passato di esperienze condivise che vanno oltre la policy Debian, un accumulo di anni di esperienza nella pacchettizzazione. Molta gente di grande talento ha creato strumenti grandiosi, strumenti che aiutano te, il mantainer Debian, a creare e mantenere pacchetti eccellenti. Questo capitolo indica alcuni procedimenti consigliati per sviluppatori Debian. Tutti queste raccomandazioni sono da considerarsi tali, non sono requisiti. Questi sono solo consigli soggettivi, avvisi e puntatori collezionati da sviluppatori Debian. Sentiti libero di scegliere ciò che ritieni opportuno. <sect id="bpp-debian-rules"> <heading>Procedimenti consigliati per <file>debian/rules</file></heading> Le seguenti raccomandazioni riguardano il file <file>debian/rules</file>. Considerando che il file <file>debian/rules</file> controlla il processo di build del pacchetto e seleziona i file che debbono andare nel pacchetto (direttamente o indirettamente), è solitamente il file su cui i maintainer passano più tempo. <sect1 id="helper-scripts">Script helper La ragione per cui utilizzare gli script helper in <file>debian/rules</file> è che permettono ai maintainer di usare e condividere una logica comune tra più pacchetti. Si prenda per esempio il problema di installare degli elementi di menu: è necessario mettere il file in <file>/usr/lib/menu</file>, e aggiungere comandi ai maintainer script per registrare e eliminare elementi dal menu. Visto che si tratta di una cosa molto comune che i pacchetti fanno, perchè ogni maintainer dovrebbe riscrivere tutto ciò da solo, a volte con dei bug? Inoltre, supponendo che la directory dei menu cambi, ogni pacchetto dovrebbe essere modificato. Gli script helper si occupano di queste problematiche. Rispettando le convenzioni, gli script helper si prendono cura di tutti i dettagli. I cambiamenti della policy possono essere introdotti negli script helper; in questo modo è suffigiente ricostruire i pacchetti con la nuova version degli helper e nessun altro cambiamento. <ref id="tools"> contiene un paio di diversi helper. Il sistema (a nostro parere) migliore e più comune è <package>debhelper</package>. I precedenti sistemi, come <package>debmake</package>, erano "monolitici": non era possibile scegliere la parte desiderata del sistema ed utilizzarla, si doveva utilizzare il sistema intero per fare tutto. <package>debhelper</package>, invece, è una raccolta di piccoli programmi <prgn>dh_*</prgn>. Per esempio, <prgn>dh_installman</prgn> installa e comprime le pagine di manuale, <prgn>dh_installmenu</prgn> installa i file menu e via dicendo. Offre quindi abbastanza flessibilità da essere in grado di utilizzare i piccoli script helper, quando servono, insieme ad altri comandi in <file>debian/rules</file>. Si può iniziare con <package>debhelper</package> leggendo <manref name="debhelper" section="1">, e seguendo gli esempi forniti con il pacchetto. <prgn>dh_make</prgn>, dal pacchetto <package>dh-make</package> (si veda <ref id="dh-make">), può essere usato per convertire un pacchetto sorgente "vanilla" in uno che fa uso di <package>debhelper</package>. Questa scorciatoia, comunque, non dovrebbe convincerti che non hai bisogno di disturbarti a capire i singoli script <prgn>dh_*</prgn>. Se userai un helper, hai bisogno di impararlo, per comprenderne il comportamento. Alcuni sono convinti che i normali file <file>debian/rules</files> siano meglio, visto che non c'è bisogno di imparare nessun sistema di helper. La scelta dipende completamente da te. Usa il metodo che preferisci. Molti esempi di <file>debian/rules</file> vanilla sono disponibili su <url id="&url-rules-files;">. <sect1 id="multiple-patches"> <heading>Separare le patch in file multipli</heading> Pacchetti grandi e complessi possono avere molti bug su cui lavorare. Correggendo un bug direttamente nei sorgenti, può diventare difficile differenziare le varie patch applicate. Può diventare un bel problema quando è necessario aggiornare il pacchetto ad un nuovo rilascio upstream che integra alcune delle modifiche (ma non tutte). Non è possibile prendere l'insieme totale dei diff (per esempio, da <file>.diff.gz</file>) e trovare in maniera unitaria le patch che risolvono bug chiusi dall'upstream. Sfortunatamente, al momento il sistema di pacchettizzazione non fornisce il supporto per separare le patch in più file. Comunque, ci sono modi per separare le patch: i file che le contengono sono inclusi nel file patch Debian (<file>.diff.gz</file>), solitamente nella directory <file>debian/</file>. L'unica differenza è che non vengono applicate immediatamente da dpkg-source, ma dalla regola <tt>build</tt> di <file>debian/rules</file>. La regola <tt>clean</tt> si occupa di invertire questo comportamento. <prgn>dbs</prgn> è uno degli approcci più comuni a questo problema. Consente di fare tutto quello che è stato spiegato precedentemente e agevola la creazione e l'aggiornamento di vecchie patch. Si veda il pacchetto <package>dbs</package> per ulteriori informazioni e <package>hello-dbs</package> come esempio. Anche <prgn>dpatch</prgn> ha queste caratteristiche, ma è pensato per essere ancora più facile da usare. Si faccia riferimento al pacchetto <package>dpatch</package> come fonte di documentazione ed esempi (in <file>/usr/share/doc/dpatch</file>). <sect1 id="multiple-binary">Pacchetti binari multipli Un singolo pacchetto sorgente costruisce spesso più di un pacchetto binario, sia per fornire più versioni dello stesso software (es., il pacchetto sorgente di <package>vim</package>) o per dividere un grosso pacchetto in pacchetti più piccoli (es., se l'utente può installare solo il sottoinsieme di pacchetti di cui ha bisogno, risparmiando un po' di spazio disco). La seconda situazione può essere trattata facilmente in <file>debian/rules</file>. Semplicemente, è necessario spostare i file appropriati dalla directory di build negli alberi temporanei dei pacchetti. Per farlo si possono usare <prgn>install</prgn> oppure <prgn>dh_install</prgn>, dal pacchetto <package>debhelper</package>. Ci si assicuri di controllare come interagiscono i vari pacchetti, assicurandosi di avere le corrette dipendenze tra pacchetti in <file>debian/control</file>. Il primo caso è un pochino più difficile visto che coinvolge ricompilazioni multiple dello stesso software ma con opzioni di configurazione differenti. Il pacchetto sorgente di <package>vim</vim> è un esempio di come gestire questa situazione usando un file <file>debian/rules</files> scritto a mano.  </sect1> </sect> <sect id="bpp-debian-control"> <heading>Procedimenti consigliati per <file>debian/control</file></heading> I consigli seguenti sono relativi al file <file>debian/control</file>. Sono un supplemento alla <url id="&url-debian-policy;ch-binary.html#s-descriptions" name="Policy on package descriptions">. La descrizione del pacchetto, definita dal campo corrispondente del file <file>control</file>, contiene sia la descrizione breve (synopsis) che quella lunga del pacchetto. <ref id="bpp-desc-basics"> descrive alcune linee guida applicabili ad entrambe. <ref id="bpp-pkg-synopsis"> fornisce consigli specifici alla descrizione breve, mentre <ref id="bpp-pkg-desc"> contiene consigli relativi alla descrizione lunga. <sect1 id="bpp-desc-basics"> <heading>General guidelines for package descriptions</heading> The package description should be written for the average likely user, the average person who will use and benefit from the package. For instance, development packages are for developers, and can be technical in their language. More general-purpose applications, such as editors, should be written for a less technical user. Our review of package descriptions lead us to conclude that most package descriptions are technical, that is, are not written to make sense for non-technical users. Unless your package really is only for technical users, this is a problem. How do you write for non-technical users? Avoid jargon. Avoid referring to other applications or frameworks that the user might not be familiar with — "GNOME" or "KDE" is fine, since users are probably familiar with these terms, but "GTK+" is probably not. Try not to assume any knowledge at all. If you must use technical terms, introduce them. Be objective. Package descriptions are not the place for advocating your package, no matter how much you love it. Remember that the reader may not care about the same things you care about. References to the names of any other software packages, protocol names, standards, or specifications should use their canonical forms, if one exists. For example, use "X Window System", "X11", or "X"; not "X Windows", "X-Windows", or "X Window". Use "GTK+", not "GTK" or "gtk". Use "GNOME", not "Gnome". Use "PostScript", not "Postscript" or "postscript". If you are having problems writing your description, you may wish to send it along to &email-debian-l10n-english; and request feedback. </sect1> <sect1 id="bpp-pkg-synopsis"> <heading>The package synopsis, or short description</heading> The synopsis line (the short description) should be concise. It must not repeat the package's name (this is policy). It's a good idea to think of the synopsis as an appositive clause, not a full sentence. An appositive clause is defined in WordNet as a grammatical relation between a word and a noun phrase that follows, e.g., "Rudolph the red-nosed reindeer". The appositive clause here is "red-nosed reindeer". Since the synopsis is a clause, rather than a full sentence, we recommend that it neither start with a capital nor end with a full stop (period). It should also not begin with an article, either definite ("the") or indefinite ("a" or "an"). It might help to imagine that the synopsis is combined with the package name in the following way: <example><var>package-name</var> is a <var>synopsis</var>.</example> Alternatively, it might make sense to think of it as <example><var>package-name</var> is <var>synopsis</var>.</example> or, if the package name itself is a plural (such as "developers-tools") <example><var>package-name</var> are <var>synopsis</var>.</example> This way of forming a sentence from the package name and synopsis should be considered as a heuristic and not a strict rule. There are some cases where it doesn't make sense to try to form a sentence. </sect1> <sect1 id="bpp-pkg-desc"> <heading>The long description</heading> The long description is the primary information available to the user about a package before they install it. It should provide all the information needed to let the user decide whether to install the package. Assume that the user has already read the package synopsis. The long description should consist of full and complete sentences. The first paragraph of the long description should answer the following questions: what does the package do? what task does it help the user accomplish? It is important to describe this in a non-technical way, unless of course the audience for the package is necessarily technical. The following paragraphs should answer the following questions: Why do I as a user need this package? What other features does the package have? What outstanding features and deficiencies are there compared to other packages (e.g., "if you need X, use Y instead")? Is this package related to other packages in some way that is not handled by the package manager (e.g., "this is the client to the foo server")? Be careful to avoid spelling and grammar mistakes. Ensure that you spell-check it. <prgn>ispell</prgn> has a special <tt>-g</tt> option for <file>debian/control</file> files: <example>ispell -d american -g debian/control</example> </sect1> <sect1 id="bpp-upstream-info"> <heading>Upstream home page</heading> We recommend that you add the URL for the package's home page to the package description in <file>debian/control</file>. This information should be added at the end of description, using the following format: <example> . Homepage: http://some-project.some-place.org/</example> Note the spaces prepending the line, which serves to break the lines correctly. To see an example of how this displays, see <url id="&url-eg-desc-upstream-info;">. If there is no home page for the software, this should naturally be left out. Note that we expect this field will eventually be replaced by a proper <file>debian/control</file> field understood by <prgn>dpkg</prgn> and <tt>&packages-host;</tt>. If you don't want to bother migrating the home page from the description to this field, you should probably wait until that is available. </sect1> </sect> <sect id="bpp-debian-changelog"> <heading>Best practices for <file>debian/changelog</file></heading> The following practices supplement the <url name="Policy on changelog files" id="&url-debian-policy;ch-docs.html#s-changelogs">. <sect1 id="bpp-changelog-do"> <heading>Writing useful changelog entries</heading> The changelog entry for a package revision documents changes in that revision, and only them. Concentrate on describing significant and user-visible changes that were made since the last version. Focus on what was changed — who, how and when are usually less important. Having said that, remember to politely attribute people who have provided notable help in making the package (e.g., those who have sent in patches). There's no need to elaborate the trivial and obvious changes. You can also aggregate several changes in one entry. On the other hand, don't be overly terse if you have undertaken a major change. Be especially clear if there are changes that affect the behaviour of the program. For further explanations, use the <file>README.Debian</file> file. Use common English so that the majority of readers can comprehend it. Avoid abbreviations, "tech-speak" and jargon when explaining changes that close bugs, especially for bugs filed by users that did not strike you as particularly technically savvy. Be polite, don't swear. It is sometimes desirable to prefix changelog entries with the names of the files that were changed. However, there's no need to explicitly list each and every last one of the changed files, especially if the change was small or repetitive. You may use wildcards. When referring to bugs, don't assume anything. Say what the problem was, how it was fixed, and append the "closes: #nnnnn" string. See <ref id="upload-bugfix"> for more information. <sect1 id="bpp-changelog-misconceptions"> <heading>Common misconceptions about changelog entries</heading> The changelog entries should not document generic packaging issues ("Hey, if you're looking for foo.conf, it's in /etc/blah/."), since administrators and users are supposed to be at least remotely acquainted with how such things are generally arranged on Debian systems. Do, however, mention if you change the location of a configuration file. The only bugs closed with a changelog entry should be those that are actually fixed in the same package revision. Closing unrelated bugs in the changelog is bad practice. See <ref id="upload-bugfix">. The changelog entries should not be used for random discussion with bug reporters ("I don't see segfaults when starting foo with option bar; send in more info"), general statements on life, the universe and everything ("sorry this upload took me so long, but I caught the flu"), or pleas for help ("the bug list on this package is huge, please lend me a hand"). Such things usually won't be noticed by their target audience, but may annoy people who wish to read information about actual changes in the package. See <ref id="bug-answering"> for more information on how to use the bug tracking system. It is an old tradition to acknowledge bugs fixed in non-maintainer uploads in the first changelog entry of the proper maintainer upload, for instance, in a changelog entry like this: <example> * Maintainer upload, closes: #42345, #44484, #42444. </example> This will close the NMU bugs tagged "fixed" when the package makes it into the archive. The bug for the fact that an NMU was done can be closed the same way. Of course, it's also perfectly acceptable to close NMU-fixed bugs by other means; see <ref id="bug-answering">. </sect1> <sect1 id="bpp-changelog-errors"> <heading>Common errors in changelog entries</heading> The following examples demonstrate some common errors or example of bad style in changelog entries. <example> * Fixed all outstanding bugs. </example> This doesn't tell readers anything too useful, obviously. <example> * Applied patch from Jane Random. </example> What was the patch about? <example> * Late night install target overhaul. </example> Overhaul which accomplished what? Is the mention of late night supposed to remind us that we shouldn't trust that code? <example> * Fix vsync FU w/ ancient CRTs. </example> Too many acronyms, and it's not overly clear what the, uh, fsckup (oops, a curse word!) was actually about, or how it was fixed. <example> * This is not a bug, closes: #nnnnnn. </example> First of all, there's absolutely no need to upload the package to convey this information; instead, use the bug tracking system. Secondly, there's no explanation as to why the report is not a bug. <example> * Has been fixed for ages, but I forgot to close; closes: #54321. </example> If for some reason you didn't mention the bug number in a previous changelog entry, there's no problem, just close the bug normally in the BTS. There's no need to touch the changelog file, presuming the description of the fix is already in (this applies to the fixes by the upstream authors/maintainers as well, you don't have to track bugs that they fixed ages ago in your changelog). <example> * Closes: #12345, #12346, #15432 </example> Where's the description? If you can't think of a descriptive message, start by inserting the title of each different bug. </sect1> </sect>  <sect id="bpp-debian-maint-scripts"> <heading>Best practices for maintainer scripts</heading> Maintainer scripts include the files <file>debian/postinst</file>, <file>debian/preinst</file>, <file>debian/prerm</file> and <file>debian/postrm</file>. These scripts take care of any package installation or deinstallation setup which isn't handled merely by the creation or removal of files and directories. The following instructions supplement the <url id="&url-debian-policy;" name="Debian Policy">. Maintainer scripts must be idempotent. That means that you need to make sure nothing bad will happen if the script is called twice where it would usually be called once. Standard input and output may be redirected (e.g. into pipes) for logging purposes, so don't rely on them being a tty. All prompting or interactive configuration should be kept to a minimum. When it is necessary, you should use the <package>debconf</package> package for the interface. Remember that prompting in any case can only be in the <tt>configure</tt> stage of the <file>postinst</file> script. Keep the maintainer scripts as simple as possible. We suggest you use pure POSIX shell scripts. Remember, if you do need any bash features, the maintainer script must have a bash sh-bang line. POSIX shell or Bash are preferred to Perl, since they enable <package>debhelper</package> to easily add bits to the scripts. If you change your maintainer scripts, be sure to test package removal, double installation, and purging. Be sure that a purged package is completely gone, that is, it must remove any files created, directly or indirectly, in any maintainer script. If you need to check for the existence of a command, you should use something like <example>if [ -x /usr/sbin/install-docs ]; then ...</example> If you don't wish to hard-code the path of the command in your maintainer script, the following POSIX-compliant shell function may help: &example-pathfind; You can use this function to search <tt>$PATH</tt> for a command name, passed as an argument. It returns true (zero) if the command was found, and false if not. This is really the most portable way, since <tt>command -v</tt>, <prgn>type</prgn>, and <prgn>which</prgn> are not POSIX. While <prgn>which</prgn> is an acceptable alternative, since it is from the required <package>debianutils</package> package, it's not on the root partition. That is, it's in <file>/usr/bin</file> rather than <file>/bin</file>, so one can't use it in scripts which are run before the <file>/usr</file> partition is mounted. Most scripts won't have this problem, though. </sect> <sect id="bpp-config-mgmt"> <heading>Configuration management with <package>debconf</package></heading> <package>Debconf</package> is a configuration management system which can be used by all the various packaging scripts (<file>postinst</file> mainly) to request feedback from the user concerning how to configure the package. Direct user interactions must now be avoided in favor of <package>debconf</package> interaction. This will enable non-interactive installations in the future. Debconf is a great tool but it is often poorly used. Many common mistakes are listed in the <manref name="debconf-devel" section="7"> man page. It is something that you must read if you decide to use debconf. </sect> <sect id="bpp-i18n"> <heading>Internationalization</heading> <sect1 id="bpp-i18n-debconf"> <heading>Handling debconf translations</heading> Like porters, translators have a difficult task. They work on many packages and must collaborate with many different maintainers. Moreover, most of the time, they are not native English speakers, so you may need to be particularly patient with them. The goal of <package>debconf</package> was to make packages configuration easier for maintainers and for users. Originally, translation of debconf templates was handled with <prgn>debconf-mergetemplate</prgn>. However, that technique is now deprecated; the best way to accomplish <package>debconf</package> internationalization is by using the <package>po-debconf</package> package. This method is easier both for maintainer and translators; transition scripts are provided. Using <package>po-debconf</package>, the translation is stored in <file>po</file> files (drawing from <prgn>gettext</prgn> translation techniques). Special template files contain the original messages and mark which fields are translatable. When you change the value of a translatable field, by calling <prgn>debconf-updatepo</prgn>, the translation is marked as needing attention from the translators. Then, at build time, the <prgn>dh_installdebconf</prgn> program takes care of all the needed magic to add the template along with the up-to-date translations into the binary packages. Refer to the <manref name="po-debconf" section="7"> manual page for details. </sect1> <sect1 id="bpp-i18n-docs"> <heading>Internationalized documentation</heading> Internationalizing documentation is crucial for users, but a lot of labor. There's no way to eliminate all that work, but you can make things easier for translators. If you maintain documentation of any size, its easier for translators if they have access to a source control system. That lets translators see the differences between two versions of the documentation, so, for instance, they can see what needs to be retranslated. It is recommended that the translated documentation maintain a note about what source control revision the translation is based on. An interesting system is provided by <url id="&url-i18n-doc-check;" name="doc-check"> in the <package>boot-floppies</package> package, which shows an overview of the translation status for any given language, using structured comments for the current revision of the file to be translated and, for a translated file, the revision of the original file the translation is based on. You might wish to adapt and provide that in your CVS area. If you maintain XML or SGML documentation, we suggest that you isolate any language-independent information and define those as entities in a separate file which is included by all the different translations. This makes it much easier, for instance, to keep URLs up-to-date across multiple files. </sect1> </sect> <sect id="bpp-common-situations"> <heading>Common packaging situations</heading>  <sect1 id="bpp-autotools"> <heading>Packages using <prgn>autoconf</prgn>/<prgn>automake</prgn></heading> Keeping <prgn>autoconf</prgn>'s <file>config.sub</file> and <file>config.guess</file> files up-to-date is critical for porters, especially on more volatile architectures. Some very good packaging practices for any package using <prgn>autoconf</prgn> and/or <prgn>automake</prgn> have been synthesized in &file-bpp-autotools; from the <package>autotools-dev</package> package. You're strongly encouraged to read this file and to follow the given recommendations. <sect1 id="bpp-libraries">Libraries Libraries are always difficult to package for various reasons. The policy imposes many constraints to ease their maintenance and to make sure upgrades are as simple as possible when a new upstream version comes out. A breakage in a library can result in dozens of dependent packages breaking. Good practices for library packaging have been grouped in <url id="&url-libpkg-guide;" name="the library packaging guide">. <sect1 id="bpp-docs">Documentation Be sure to follow the <url id="&url-debian-policy;ch-docs.html" name="Policy on documentation">. If your package contains documentation built from XML or SGML, we recommend you not ship the XML or SGML source in the binary package(s). If users want the source of the documentation, they should retrieve the source package. Policy specifies that documentation should be shipped in HTML format. We also recommend shipping documentation in PDF and plain text format if convenient and quality output is possible. However, it is generally not appropriate to ship plain text versions of documentation whose source format is HTML. Major shipped manuals should register themselves with <package>doc-base</package> on installation. See the <package>doc-base</package> package documentation for more information. <sect1 id="bpp-other">Specific types of packages Several specific types of packages have special sub-policies and corresponding packaging rules and practices: <list> <item> Perl related packages have a <url name="Perl policy" id="&url-perl-policy;">, some examples of packages following that policy are <package>libdbd-pg-perl</package> (binary perl module) or <package>libmldbm-perl</package> (arch independent perl module). <item> Python related packages have their python policy; see &file-python-policy; in the <package>python</package> package. <item> Emacs related packages have the <url id="&url-emacs-policy;" name="emacs policy">. <item> Java related packages have their <url id="&url-java-policy;" name="java policy">. <item> Ocaml related packages have their own policy, found in &file-ocaml-policy; from the <package>ocaml</package> package. A good example is the <package>camlzip</package> source package. <item> Packages providing XML or SGML DTDs should conform to the recommendations found in the <package>sgml-base-doc</package> package. <item> Lisp packages should register themselves with <package>common-lisp-controller</package>, about which see &file-lisp-controller;. </list> </sect1>  <sect1 id="bpp-archindepdata"> <heading>Architecture-independent data</heading> It is not uncommon to have a large amount of architecture-independent data packaged with a program. For example, audio files, a collection of icons, wallpaper patterns, or other graphic files. If the size of this data is negligible compared to the size of the rest of the package, it's probably best to keep it all in a single package. However, if the size of the data is considerable, consider splitting it out into a separate, architecture-independent package ("_all.deb"). By doing this, you avoid needless duplication of the same data into eleven or more .debs, one per each architecture. While this adds some extra overhead into the <file>Packages</file> files, it saves a lot of disk space on Debian mirrors. Separating out architecture-independent data also reduces processing time of <prgn>lintian</prgn> or <prgn>linda</prgn> (see <ref id="tools-lint">) when run over the entire Debian archive. </sect1> </sect> </chapt> <chapt id="beyond-pkging"> <heading>Beyond Packaging</heading> Debian is about a lot more than just packaging software and maintaining those packages. This chapter contains information about ways, often really critical ways, to contribute to Debian beyond simply creating and maintaining packages. As a volunteer organization, Debian relies on the discretion of its members in choosing what they want to work on and in choosing the most critical thing to spend their time on. <sect id="submit-bug"> <heading>Bug reporting</heading> We encourage you to file bugs as you find them in Debian packages. In fact, Debian developers are often the first line testers. Finding and reporting bugs in other developers' packages improves the quality of Debian. Read the <url name="instructions for reporting bugs" id="&url-bts-report;"> in the Debian <url name="bug tracking system" id="&url-bts;">. Try to submit the bug from a normal user account at which you are likely to receive mail, so that people can reach you if they need further information about the bug. Do not submit bugs as root. You can use a tool like <manref name="reportbug" section="1"> to submit bugs. It can automate and generally ease the process. Make sure the bug is not already filed against a package. Each package has a bug list easily reachable at <tt>http://&bugs-host;/<var>packagename</var></tt> Utilities like <manref name="querybts" section="1"> can also provide you with this information (and <prgn>reportbug</prgn> will usually invoke <prgn>querybts</prgn> before sending, too). Try to direct your bugs to the proper location. When for example your bug is about a package that overwrites files from another package, check the bug lists for both of those packages in order to avoid filing duplicate bug reports. For extra credit, you can go through other packages, merging bugs which are reported more than once, or tagging bugs `fixed' when they have already been fixed. Note that when you are neither the bug submitter nor the package maintainer, you should not actually close the bug (unless you secure permission from the maintainer). From time to time you may want to check what has been going on with the bug reports that you submitted. Take this opportunity to close those that you can't reproduce anymore. To find out all the bugs you submitted, you just have to visit <tt>http://&bugs-host;/from:<var><your-email-addr></var></tt>. <sect1 id="submit-many-bugs">Reporting lots of bugs at once Reporting a great number of bugs for the same problem on a great number of different packages — i.e., more than 10 — is a deprecated practice. Take all possible steps to avoid submitting bulk bugs at all. For instance, if checking for the problem can be automated, add a new check to <package>lintian</package> so that an error or warning is emitted. If you report more than 10 bugs on the same topic at once, it is recommended that you send a message to &email-debian-devel; describing your intention before submitting the report. This will allow other developers to verify that the bug is a real problem. In addition, it will help prevent a situation in which several maintainers start filing the same bug report simultaneously. Note that when sending lots of bugs on the same subject, you should send the bug report to <email>maintonly@&bugs-host;</email> so that the bug report is not forwarded to the bug distribution mailing list. <sect id="qa-effort">Quality Assurance effort <sect1 id="qa-daily-work">Daily work Even though there is a dedicated group of people for Quality Assurance, QA duties are not reserved solely for them. You can participate in this effort by keeping your packages as bug-free as possible, and as lintian-clean (see <ref id="lintian">) as possible. If you do not find that possible, then you should consider orphaning some of your packages (see <ref id="orphaning">). Alternatively, you may ask the help of other people in order to catch up the backlog of bugs that you have (you can ask for help on &email-debian-qa; or &email-debian-devel;). At the same time, you can look for co-maintainers (see <ref id="collaborative-maint">). <sect1 id="qa-bsp">Bug squashing parties From time to time the QA group organizes bug squashing parties to get rid of as many problems as possible. They are announced on &email-debian-devel-announce; and the announce explains what area will be focused on during the party: usually they focus on release critical bugs but it may happen that they decide to help finish a major upgrade going on (like a new perl version which requires recompilation of all the binary modules). The rules for non-maintainer uploads differ during the parties because the announce of the party is considered like a prior notice for NMU. If you have packages that may be affected by the party (because they have release critical bugs for example), you should send an update to each of the corresponding bug to explain their current status and what you expect from the party. If you don't want an NMU, or if you're only interested in a patch, or if you will deal yourself with the bug, please explain that in the BTS. People participating in the party have special rules for NMU, they can NMU without prior notice if they upload their NMU to DELAYED/3-day at least. All other NMU rules applies as usually, they should send the patch of the NMU in the BTS (in one of the open bugs fixed by the NMU or in a new bug tagged fixed). They should also respect the maintainer's wishes if he expressed some. If someone doesn't feel confident with an NMU, he should just send a patch to the BTS. It's far better than a broken NMU. <sect id="contacting-maintainers">Contacting other maintainers During your lifetime within Debian, you will have to contact other maintainers for various reasons. You may want to discuss a new way of cooperating between a set of related packages, or you may simply remind someone that a new upstream version is available and that you need it. Looking up the email address of the maintainer for the package can be distracting. Fortunately, there is a simple email alias, <tt><package>@&packages-host;</tt>, which provides a way to email the maintainer, whatever their individual email address (or addresses) may be. Replace <tt><package></tt> with the name of a source or a binary package. You may also be interested in contacting the persons who are subscribed to a given source package via <ref id="pkg-tracking-system">. You can do so by using the <tt><package-name>@&pts-host;</tt> email address. <sect id="mia-qa">Dealing with inactive and/or unreachable maintainers If you notice that a package is lacking maintenance, you should make sure that the maintainer is active and will continue to work on their packages. It is possible that they are not active any more, but haven't registered out of the system, so to speak. On the other hand, it is also possible that they just need a reminder. The first step is to politely contact the maintainer, and wait for a response, for a reasonable time. It is quite hard to define "reasonable time", but it is important to take into account that real life is sometimes very hectic. One way to handle this would be send a reminder after two weeks. If the maintainer doesn't reply within four weeks (a month), one can assume that a response will probably not happen. If that happens, you should investigate further, and try to gather as much useful information about the maintainer in question as possible. This includes: <list> <item>The "echelon" information available through the <url id="&url-debian-db;" name="developers' LDAP database">, which indicates when's the last time a developer has posted to a Debian mailing list. (This includes uploads via debian-*-changes lists.) Also, remember to check whether the maintainer is marked as "on vacation" in the database. <item>The number of packages this maintainer is responsible for, and the condition of those packages. In particular, are there any RC bugs that have been open for ages? Furthermore, how many bugs are there in general? Another important piece of information is whether the packages have been NMUed, and if so, by whom? <item>Is there any activity of the maintainer outside of Debian? For example, they might have posted something recently to non-Debian mailing lists or news groups. </list> One big problem are packages which were sponsored -- the maintainer is not an official Debian developer. The echelon information is not available for sponsored people, for example, so you need to find and contact the Debian developer who has actually uploaded the package. Given that they signed the package, they're responsible for the upload anyhow, and should know what happened to the person they sponsored. It is also allowed to post a query to &email-debian-devel;, asking if anyone is aware of the whereabouts of the missing maintainer. Once you have gathered all of this, you can contact &email-debian-qa;. People on this alias will use the information you provided in order to decide how to proceed. For example, they might orphan one or all of the packages of the maintainer. If a packages has been NMUed, they might prefer to contact the NMUer before orphaning the package -- perhaps the person who has done the NMU is interested in the package. One last word: please remember to be polite. We are all volunteers and cannot dedicate all of our time to Debian. Also, you are not aware of the circumstances of the person who is involved. Perhaps they might be seriously ill or might even had died -- you do not know who may be on the receiving side -- imagine how a relative will feel if they read the e-mail of the deceased and find a very impolite, angry and accusing message!) On the other hand, although we are volunteers, we do have a responsibility. So you can stress the importance of the greater good -- if a maintainer does not have the time or interest anymore, they should "let go" and give the package to someone with more time. <sect id="newmaint"> <heading>Interacting with prospective Debian developers</heading> Debian's success depends on its ability to attract and retain new and talented volunteers. If you are an experienced developer, we recommend that you get involved with the process of bringing in new developers. This section describes how to help new prospective developers. <sect1 id="sponsoring">Sponsoring packages Sponsoring a package means uploading a package for a maintainer who is not able to do it on their own, a new maintainer applicant. Sponsoring a package also means accepting responsibility for it. If you wish to volunteer as a sponsor, you can sign up at <url id="&url-sponsors;">. New maintainers usually have certain difficulties creating Debian packages — this is quite understandable. That is why the sponsor is there, to check the package and verify that it is good enough for inclusion in Debian. (Note that if the sponsored package is new, the ftpmasters will also have to inspect it before letting it in.) Sponsoring merely by signing the upload or just recompiling is definitely not recommended. You need to build the source package just like you would build a package of your own. Remember that it doesn't matter that you left the prospective developer's name both in the changelog and the control file, the upload can still be traced to you. If you are an application manager for a prospective developer, you can also be their sponsor. That way you can also verify how the applicant is handling the 'Tasks and Skills' part of their application. <sect1>Managing sponsored packages By uploading a sponsored package to Debian, you are certifying that the package meets minimum Debian standards. That implies that you must build and test the package on your own system before uploading. You can not simply upload a binary <file>.deb</file> from the sponsoree. In theory, you should only ask for the diff file and the location of the original source tarball, and then you should download the source and apply the diff yourself. In practice, you may want to use the source package built by your sponsoree. In that case, you have to check that they haven't altered the upstream files in the <file>.orig.tar.gz</file> file that they're providing. Do not be afraid to write the sponsoree back and point out changes that need to be made. It often takes several rounds of back-and-forth email before the package is in acceptable shape. Being a sponsor means being a mentor. Once the package meets Debian standards, build and sign it with <example>dpkg-buildpackage -k<var>KEY-ID</var></example> before uploading it to the incoming directory. The Maintainer field of the <file>control</file> file and the <file>changelog</file> should list the person who did the packaging, i.e., the sponsoree. The sponsoree will therefore get all the BTS mail about the package. If you prefer to leave a more evident trace of your sponsorship job, you can add a line stating it in the most recent changelog entry. You are encouraged to keep tabs on the package you sponsor using <ref id="pkg-tracking-system">. <sect1>Advocating new developers See the page about <url id="&url-newmaint-advocate;" name="advocating a prospective developer"> at the Debian web site. <sect1>Handling new maintainer applications Please see <url id="&url-newmaint-amchecklist;" name="Checklist for Application Managers"> at the Debian web site. <appendix id="tools">Overview of Debian Maintainer Tools This section contains a rough overview of the tools available to maintainers. The following is by no means complete or definitive, but just a guide to some of the more popular tools. Debian maintainer tools are meant to help convenience developers and free their time for critical tasks. As Larry Wall says, there's more than one way to do it. Some people prefer to use high-level package maintenance tools and some do not. Debian is officially agnostic on this issue; any tool which gets the job done is fine. Therefore, this section is not meant to stipulate to anyone which tools they should use or how they should go about with their duties of maintainership. Nor is it meant to endorse any particular tool to the exclusion of a competing tool. Most of the descriptions of these packages come from the actual package descriptions themselves. Further information can be found in the package documentation itself. You can also see more info with the command <tt>apt-cache show <package-name></tt>. <sect id="tools-core"> <heading>Core tools</heading> The following tools are pretty much required for any maintainer. <sect1 id="dpkg-dev"> <heading><package>dpkg-dev</package> <package>dpkg-dev</package> contains the tools (including <prgn>dpkg-source</prgn>) required to unpack, build and upload Debian source packages. These utilities contain the fundamental, low-level functionality required to create and manipulated packages; as such, they are required for any Debian maintainer. <sect1 id="debconf"> <heading><package>debconf</package></heading> <package>debconf</package> provides a consistent interface to configuring packages interactively. It is user interface independent, allowing end-users to configure packages with a text-only interface, an HTML interface, or a dialog interface. New interfaces can be added modularly. You can find documentation for this package in the <package>debconf-doc</package> package. Many feel that this system should be used for all packages requiring interactive configuration; see <ref id="bpp-config-mgmt">. <package>debconf</package> is not currently required by Debian Policy, but that may change in the future. </sect1> <sect1 id="fakeroot"> <heading><package>fakeroot</package> <package>fakeroot</package> simulates root privileges. This enables you to build packages without being root (packages usually want to install files with root ownership). If you have <package>fakeroot</package> installed, you can build packages as a user: <tt>dpkg-buildpackage -rfakeroot</tt>. </sect1> </sect> <sect id="tools-lint"> <heading>Package lint tools</heading> According to the Free On-line Dictionary of Computing (FOLDOC), `lint' is "a Unix C language processor which carries out more thorough checks on the code than is usual with C compilers." Package lint tools help package maintainers by automatically finding common problems and policy violations with their packages. <sect1 id="lintian"> <heading><package>lintian</package></heading> <package>lintian</package> dissects Debian packages and emits information on bugs and policy violations. It contains automated checks for many aspects of Debian policy as well as some checks for common errors. You should periodically get the newest <package>lintian</package> from `unstable' and check over all your packages. Notice that the <tt>-i</tt> option provides detailed explanations of what each error or warning means, what is its basis in Policy, and commonly how you can fix the problem. Refer to <ref id="sanitycheck"> for more information on how and when to use Lintian. You can also see a summary of all problems reported by Lintian on your packages at <url id="&url-lintian;">. Those reports contain the latest <prgn>lintian</prgn> output on the whole development distribution ("unstable"). </sect1> <sect1 id="linda"> <heading><package>linda</package></heading> <package>linda</package> is another package linter. It is similar to <package>lintian</package> but has a different set of checks. Its written in Python rather than Perl. </sect1> <sect1 id="debdiff"> <heading><package>debdiff</package></heading> <prgn>debdiff</prgn> (from the <package>devscripts</package> package, <ref id="devscripts">) compares file lists and control files of two packages. It is a simple regression test, as it will help you notice if the number of binary packages has changed since the last upload, or if something's changed in the control file. Of course, some of the changes it reports will be all right, but it can help you prevent various accidents. You can run it over a pair of binary packages: <example> debdiff package_1-1_arch.deb package_2-1_arch.deb </example> Or even a pair of changes files: <example> debdiff package_1-1_arch.changes package_2-1_arch.changes </example> For more information please see <manref name="debdiff" section="1">. </sect1> </sect> <sect id="tools-helpers"> <heading>Helpers for <file>debian/rules</file></heading> Package building tools make the process of writing <file>debian/rules</file> files easier. See <ref id="helper-scripts"> for more information on why these might or might not be desired. <sect1 id="debhelper"> <heading><package>debhelper</package></heading> <package>debhelper</package> is a collection of programs that can be used in <file>debian/rules</file> to automate common tasks related to building binary Debian packages. Programs are included to install various files into your package, compress files, fix file permissions, integrate your package with the Debian menu system. Unlike some approaches, <package>debhelper</package> is broken into several small, granular commands which act in a consistent manner. As such, it allows a greater granularity of control than some of the other "debian/rules tools". There are a number of little <package>debhelper</package> add-on packages, too transient to document. You can see the list of most of them by doing <tt>apt-cache search ^dh-</tt>. </sect1> <sect1 id="debmake"> <heading><package>debmake</package> <package>debmake</package>, a pre-cursor to <package>debhelper</package>, is a less granular <file>debian/rules</file> assistant. It includes two main programs: <prgn>deb-make</prgn>, which can be used to help a maintainer convert a regular (non-Debian) source archive into a Debian source package; and <prgn>debstd</prgn>, which incorporates in one big shot the same sort of automated functions that one finds in <package>debhelper</package>. The consensus is that <package>debmake</package> is now deprecated in favor of <package>debhelper</package>. However, it's not a bug to use <package>debmake</package>. </sect1> <sect1 id="dh-make"> <heading><package>dh-make</package> The <package/dh-make/ package contains <prgn/dh_make/, a program that creates a skeleton of files necessary to build a Debian package out of a source tree. As the name suggests, <prgn/dh_make/ is a rewrite of <package/debmake/ and its template files use dh_* programs from <package/debhelper/. While the rules files generated by <prgn/dh_make/ are in general a sufficient basis for a working package, they are still just the groundwork: the burden still lies on the maintainer to finely tune the generated files and make the package entirely functional and Policy-compliant. </sect1> <sect1 id="yada"> <heading><package>yada</package> <package>yada</package> is another packaging helper tool. It uses a <file>debian/packages</file> file to auto-generate <file>debian/rules</file> and other necessary files in the <file>debian/</file> subdirectory. Note that <package>yada</package> is called "essentially unmaintained" by it's own maintainer, Charles Briscoe-Smith. As such, it can be considered deprecated. </sect1> <sect1 id="equivs"> <heading><package>equivs</package> <package>equivs</package> is another package for making packages. It is often suggested for local use if you need to make a package simply to fulfill dependencies. It is also sometimes used when making ``meta-packages'', which are packages whose only purpose is to depend on other packages. </sect1> </sect> <sect id="tools-builders"> <heading>Package builders</heading> The following packages help with the package building process, general driving <prgn>dpkg-buildpackage</prgn> as well as handling supporting tasks. <sect1 id="cvs-buildpackage"> <heading><package>cvs-buildpackage</package> <package>cvs-buildpackage</package> provides the capability to inject or import Debian source packages into a CVS repository, build a Debian package from the CVS repository, and helps in integrating upstream changes into the repository. These utilities provide an infrastructure to facilitate the use of CVS by Debian maintainers. This allows one to keep separate CVS branches of a package for stable, unstable and possibly experimental distributions, along with the other benefits of a version control system. </sect1> <sect1 id="debootstrap"> <heading><package>debootstrap</package></heading> The <package>debootstrap</package> package and script allows you to "bootstrap" a Debian base system into any part of your file-system. By "base system", we mean the bare minimum of packages required to operate and install the rest of the system. Having a system like this can be useful in many ways. For instance, you can <prgn>chroot</prgn> into it if you want to test your build depends. Or, you can test how your package behaves when installed into a bare base system. Chroot builders use this package, see below. </sect1> <sect1 id="pbuilder"> <heading><package>pbuilder</package></heading> <package>pbuilder</package> constructs a chrooted system, and builds a package inside the chroot. It is very useful to check that a package's build-dependencies are correct, and to be sure that unnecessary and wrong build dependencies will not exist in the resulting package. A related package is <package>pbuilder-uml</package>, which goes even further build doing the build within User-mode-linux. </sect1> <sect1 id="sbuild"> <heading><package>sbuild</package></heading> <package>sbuild</package> is another automated builder. It can use chrooted environments as well. It can be used stand-alone, or as part of a networked, distributed build environment. As the latter, it is part of the system used by porters to build binary packages for all the available architectures. See <ref id="buildd"> for more information, and <url id="&url-buildd;"> to see the system in action. </sect1> </sect> <sect id="uploaders"> <heading>Package uploaders</heading> The following packages help automate or simplify the process of uploading packages into the official archive. <sect1 id="dupload"> <heading><package>dupload</package></heading> <package>dupload</package> is a package and a script to automatically upload Debian packages to the Debian archive, to log the upload, and to send mail about the upload of a package. You can configure it for new upload locations or methods. </sect1> <sect1 id="dput"> <heading><package>dput</package></heading> The <package>dput</package> package and script does much the same thing as <package>dupload</package>, but in a different way. It has some features over <package>dupload</package>, such as the ability to check the GnuPG signature and checksums before uploading, and the possibility of running <prgn>dinstall</prgn> in dry-run mode after the upload. </sect1> </sect> <sect id="tools-maint-automate"> <heading>Maintenance automation</heading> The following tools help automate different maintenance tasks, from adding changelog entries or signature lines, looking up bugs in Emacs, to making use of the newest and official use of <file>config.sub</file>. <sect1 id="devscripts"> <heading><package>devscripts</package></heading> <package>devscripts</package> is a package containing wrappers and tools which are very helpful for maintaining your Debian packages. Example scripts include <prgn>debchange</prgn> and <prgn>dch</prgn>, which manipulate your <file>debian/changelog</file> file from the command-line, and <prgn>debuild</prgn>, which is a wrapper around <prgn>dpkg-buildpackage</prgn>. The <prgn>bts</prgn> utility is also very helpful to update the state of bug reports on the command line. <prgn>uscan</prgn> can be used to watch for new upstream versions of your packages. The <prgn>debrsign</prgn> can be used to remotely sign a package prior to upload, which is nice when the machine you build the package on is different from where your GPG keys are. See the <manref name="devscripts" section="1"> manual page for a complete list of available scripts. </sect1> <sect1 id="autotools-dev"> <heading><package>autotools-dev</package></heading> Contains best practices for people maintaining packages that use <prgn>autoconf</prgn> and/or <prgn>automake</prgn>. Also contains canonical <file>config.sub</file> and <file>config.guess</file> files which are known to work on all Debian ports. </sect1> <sect1 id="dpkg-repack"> <heading><package>dpkg-repack</package></heading> <prgn>dpkg-repack</prgn> creates Debian package file out of a package that has already been installed. If any changes have been made to the package while it was unpacked (e.g., files in <file>/etc</file> were modified), the new package will inherit the changes. This utility can make it easy to copy packages from one computer to another, or to recreate packages that are installed on your system but no longer available elsewhere, or to store the current state of a package before you upgrade it. </sect1> <sect1 id="alien"> <heading><package>alien</package></heading> <prgn>alien</prgn> converts binary packages between various packaging formats, including Debian, RPM (RedHat), LSB (Linux Standard Base), Solaris and Slackware packages. </sect1> <sect1 id="debsums"> <heading><package>debsums</package></heading> <prgn>debsums</prgn> checks installed packages against their MD5 sums. Note that not all packages have MD5 sums, since they aren't required by Policy. </sect1> <sect1 id="dpkg-dev-el"> <heading><package>dpkg-dev-el</package></heading> <package>dpkg-dev-el</package> is an Emacs lisp package which provides assistance when editing some of the files in the <file>debian</file> directory of your package. For instance, when editing <file>debian/changelog</file>, there are handy functions for finalizing a version and listing the package's current bugs. </sect1> <sect1 id="dpkg-depcheck"> <heading><package>dpkg-depcheck</package></heading> <prgn>dpkg-depcheck</prgn> (from the <package>devscripts</package> package, <ref id="devscripts">) runs a command under <prgn>strace</prgn> to determine all the packages that were used by the said command. For Debian packages, this is useful when you have to compose a <tt>Build-Depends</tt> line for your new package: running the build process through <prgn>dpkg-depcheck</prgn> will provide you with a good first approximation of the build-dependencies. For example: <example> dpkg-depcheck -b debian/rules build </example> <prgn>dpkg-depcheck</prgn> can also be used to check for run-time dependencies, especially if your package uses exec(2) to run other programs. For more information please see <manref name="dpkg-depcheck" section="1">. </sect1> </sect> <sect id="tools-porting"> <heading>Porting tools</heading> The following tools are helpful for porters and for cross-compilation. <sect1 id="quinn-diff"> <heading><package>quinn-diff</package> <package>quinn-diff</package> is used to locate the differences from one architecture to another. For instance, it could tell you which packages need to be ported for architecture <var>Y</var>, based on architecture <var>X</var>. <sect1 id="dpkg-cross"> <heading><package>dpkg-cross</package> <package>dpkg-cross</package> is a tool for installing libraries and headers for cross-compiling in a way similar to <package>dpkg</package>. Furthermore, the functionality of <prgn>dpkg-buildpackage</prgn> and <prgn>dpkg-shlibdeps</prgn> is enhanced to support cross-compiling. </sect1> <sect id="tools-doc"> <heading>Documentation and information</heading> The following packages provide information for maintainers or help with building documentation. <sect1 id="debiandoc-sgml"> <heading><package>debiandoc-sgml</package></heading> <package>debiandoc-sgml</package> provides the DebianDoc SGML DTD, which is commonly used for Debian documentation. This manual, for instance, is written in DebianDoc. It also provides scripts for building and styling the source to various output formats. Documentation for the DTD can be found in the <package>debiandoc-sgml-doc</package> package. </sect1> <sect1 id="debian-keyring"> <heading><package>debian-keyring</package></heading> Contains the public GPG and PGP keys of Debian developers. See <ref id="key-maint"> and the package documentation for more information. </sect1> <sect1 id="debview"> <heading><package>debview</package></heading> <package>debview</package> provides an Emacs mode for viewing Debian binary packages. This lets you examine a package without unpacking it. </sect1> </sect>  </appendix> </book> </debiandoc>