Guida di riferimento per lo sviluppatore Debian

Transcript

Guida di riferimento per lo sviluppatore
Debian
Developer’s Reference Team
<[email protected]>
Adam Di Carlo, editor
Raphaël Hertzog
Christian Schwarz
Ian Jackson
Traduzione:
Francesco Donadon <[email protected]>
Emanuele Rocca <[email protected]>
ver. 3.3.4, 29 February 2004
Avviso di Copyright
copyright © 1998—2003 Adam Di Carlo
copyright © 2002—2003 Raphaël Hertzog
copyright © 1997, 1998 Christian Schwarz
Questo manuale è considerato free software; puoi redistribuirlo e/omodificarlo sotto le condizioni della GNU General Public Licenserilasciata dalla Free Software Foundation; versione 2 o
(a tuadiscrezione) qualunque versione successiva.
Questo manuale è distribuito nella speranza che sia utile, masenza alcuna garanzia; senza neanche la garanzia implicitache sia commerciabile o utile per un particolare scopo. Leggi la
GNUGeneral Public License per ulteriori dettagli.
Una copia della GNU General Public License è disponibile nel file/usr/share
/common-licenses/GPL all’interno della distribuzione Debian GNU/Linux o in retesu il
sito web GNU (http://www.gnu.org/copyleft/gpl.html). Puoi anche ottenerneuna
copia scrivendo a Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
02111-1307, USA.
i
Indice
1
Scopo Di Questo Documento
1
2
Applying per diventare un maintainer
3
2.1
Iniziare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.2
Registrarsi come sviluppatore Debian . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.3
Debian mentor e sponsor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
3
4
Compiti dello sviluppatore Debian
7
3.1
Aggiornare le tue informazioni in Debian . . . . . . . . . . . . . . . . . . . . . . .
7
3.2
Mantenere la tua chiave privata . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.3
Votare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.4
Andare in vacanza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
3.5
Cooperazione con gli sviluppatori upstream . . . . . . . . . . . . . . . . . . . . .
8
3.6
Gestire i bug release-critical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.7
Ritirarsi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
Risorse per gli sviluppatori Debian
4.1
11
Mailing list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.1
Regole di base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.2
Principali mailing list di sviluppo . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.3
Liste speciali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.4
Richiedere nuove liste relative allo sviluppo. . . . . . . . . . . . . . . . . . 12
4.2
Canali IRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3
Documentazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.4
Macchine Debian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
INDICE
ii
4.4.1
Il server bugs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.4.2
Il server ftp-master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.4.3
Il server non-US . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.4.4
Il server www-master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.4.5
Il server web people . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.4.6
Il server CVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.5
Il database degli sviluppatori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.6
L’archivio Debian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.6.1
Sezioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.6.2
Architetture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.6.3
Pacchetti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.6.4
Distribuzioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.6.5
Nomi in codice delle release . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.7
Mirror Debian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.8
Il sistema incoming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.8.1
4.9
Incoming ritardato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Informazioni sui pacchetti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.9.1
Sul web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.9.2
L’utility madison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.10 Il sistema di tracciamento dei pacchetti . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.10.1 L’interfaccia email del PTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.10.2 Filtrare le mail del PTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.10.3 Inoltrare i commit CVS nel PTS . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.10.4 L’interfaccia web del PTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.11 Vista d’insieme dei pacchetti degli sviluppatori . . . . . . . . . . . . . . . . . . . . 30
4.12 Debian *Forge: Alioth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5
Gestire i pacchetti
33
5.1
Nuovi pacchetti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.2
Registrare i cambiamenti dei pacchetti . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.3
Controllare il pacchetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
INDICE
iii
5.4
Layout del pacchetto sorgente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.5
Scegliere la distribuzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.6
5.5.1
Caso speciale: upload alla distribuzione stable . . . . . . . . . . . . . . . . 36
5.5.2
Caso speciale: upload a testing-proposed-updates . . . . . . . . . . . . . . . . 37
Effetuare un upload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.6.1
Inviare un upload a ftp-master . . . . . . . . . . . . . . . . . . . . . . . 37
5.6.2
Inviare un upload a non-US . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.6.3
Upload via chiark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.6.4
Upload via erlangen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.6.5
Altre code di upload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.6.6
Notificazione che un nuovo pacchetto è stato installato . . . . . . . . . . . 40
5.7
Specificare sezione, sottosezione e priorità del pacchetto . . . . . . . . . . . . . . 40
5.8
Gestire i bug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.9
5.8.1
Monitorare i bug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.8.2
Rispondere ai bug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.8.3
Bug housekeeping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.8.4
Quando i bug vengono chiusi da nuovi upload. . . . . . . . . . . . . . . . 44
5.8.5
Gestire i bug di sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Spostare, rimuovere, rinominare, adottare e abbandonare pacchetti . . . . . . . . 49
5.9.1
Spostare pacchetti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.9.2
Rimuovere pacchetti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.9.3
Rimpiazzare o rinominare pacchetti . . . . . . . . . . . . . . . . . . . . . . 50
5.9.4
Abbandonare un pacchetto . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.9.5
Adottare un pacchetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.10 Porting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.10.1 Essere cortesi con i porter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.10.2 Linee guida per gli upload dei porter . . . . . . . . . . . . . . . . . . . . . 53
5.10.3 Infrastrutture e automazione nel porting . . . . . . . . . . . . . . . . . . . 54
5.11 Non-Maintainer Upload (NMU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.11.1 Terminologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.11.2 Chi può fare un NMU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
INDICE
iv
5.11.3 Quando fare un NMU di sorgenti . . . . . . . . . . . . . . . . . . . . . . . 57
5.11.4 Come fare un NMU di sorgenti . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.11.5 Riconoscere un NMU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.12 Manutenzione collaborativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6
Procedimenti di pacchetizzazione consigliati
6.1
6.2
6.3
61
Procedimenti consigliati per debian/rules . . . . . . . . . . . . . . . . . . . . . 61
6.1.1
Script helper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.1.2
Separare le patch in file multipli . . . . . . . . . . . . . . . . . . . . . . . . 62
6.1.3
Pacchetti binari multipli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Procedimenti consigliati per debian/control . . . . . . . . . . . . . . . . . . . 63
6.2.1
Linee guida generiche per le descrizioni dei pacchetti . . . . . . . . . . . . 63
6.2.2
La sinossi del pacchetto, o descrizione breve . . . . . . . . . . . . . . . . . 64
6.2.3
La descrizione lunga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.2.4
Home page upstream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Procedimenti consigliati per debian/changelog . . . . . . . . . . . . . . . . . . 65
6.3.1
Scrivere voci di changelog utili . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.3.2
Concetti comunemente sbagliati sulle voci di changelog . . . . . . . . . . 66
6.3.3
Errori comuni nelle voci di changelog . . . . . . . . . . . . . . . . . . . . . 67
6.4
Procedimenti consigliati per gli script del mantainer . . . . . . . . . . . . . . . . . 68
6.5
Gestione della configurazione con debconf . . . . . . . . . . . . . . . . . . . . . 69
6.6
Internazionalizzazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.7
6.6.1
Gestire le traduzioni di debconf . . . . . . . . . . . . . . . . . . . . . . . . 69
6.6.2
Documentazione internazionalizzata. . . . . . . . . . . . . . . . . . . . . . 70
Situazioni comuni di pacchettizzazione . . . . . . . . . . . . . . . . . . . . . . . . 70
6.7.1
Pacchetti che usano autoconf/automake . . . . . . . . . . . . . . . . . . 70
6.7.2
Librerie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.7.3
Documentazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.7.4
Tipologie specifiche di pacchetti . . . . . . . . . . . . . . . . . . . . . . . . 71
6.7.5
Dati indipendenti dall’architettura . . . . . . . . . . . . . . . . . . . . . . . 72
INDICE
7
v
Oltre la pacchettizzazione
7.1
Riportare bug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
7.1.1
7.2
73
Riportare un gran numero di bug in una volta sola . . . . . . . . . . . . . 74
Opere di assicurazione qualità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
7.2.1
Lavori giornalieri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
7.2.2
Bug squashing party . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
7.3
Contattare altri mantainer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
7.4
Trattare con mantainer inattivi e/o irraggiungibili . . . . . . . . . . . . . . . . . . 75
7.5
Interazione con futuri sviluppatori Debian . . . . . . . . . . . . . . . . . . . . . . 77
7.5.1
Sponsorizzare pacchetti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
7.5.2
Gestire i pacchetti sponsorizzati . . . . . . . . . . . . . . . . . . . . . . . . 77
7.5.3
Advocating new developers . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
7.5.4
Handling new maintainer applications . . . . . . . . . . . . . . . . . . . . 78
A Overview of Debian Maintainer Tools
79
A.1 Core tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
A.1.1 dpkg-dev . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
A.1.2 debconf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
A.1.3 fakeroot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
A.2 Package lint tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
A.2.1 lintian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
A.2.2 linda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
A.2.3 debdiff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
A.3 Helpers for debian/rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
A.3.1 debhelper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
A.3.2 debmake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
A.3.3 dh-make . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
A.3.4 yada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
A.3.5 equivs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
A.4 Package builders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
A.4.1 cvs-buildpackage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
INDICE
vi
A.4.2 debootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
A.4.3 pbuilder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
A.4.4 sbuild . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
A.5 Package uploaders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
A.5.1 dupload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
A.5.2 dput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
A.6 Maintenance automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
A.6.1 devscripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
A.6.2 autotools-dev . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
A.6.3 dpkg-repack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
A.6.4 alien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
A.6.5 debsums . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
A.6.6 dpkg-dev-el . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
A.6.7 dpkg-depcheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
A.7 Porting tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
A.7.1 quinn-diff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
A.7.2 dpkg-cross . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
A.8 Documentation and information . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
A.8.1 debiandoc-sgml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
A.8.2 debian-keyring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
A.8.3 debview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
1
Capitolo 1
Scopo Di Questo Documento
L’obiettivo di questo documento è di fornire una vista d’insieme delleprocedure raccomandate
e le risorse disponibili agli sviluppatoriDebian.
Le procedure qui discusse includono come diventare un mantainer(‘Applying per diventare
un maintainer’ a pagina 3); come creare nuovi pachetti(‘Nuovi pacchetti’ a pagina 33) e come
effettuarne l’upload (‘Effetuare un upload’ a pagina 37);come gestire i bug reports (‘Gestire
i bug’ a pagina 41); come muovere,rimuovere, o abbandonare pacchetti (‘Spostare, rimuovere, rinominare, adottare e abbandonare pacchetti’ a pagina 49); come fareil port di pacchetti
(‘Porting’ a pagina 51); e come e quando rilasciareversioni temporanee di pacchetti di altri
mantainers (‘Non-Maintainer Upload (NMU)’ a pagina 55).
Le risorse qui discusse includono le mailing list (‘Mailing list’ a pagina 11) X.YZWe i server
(‘Macchine Debian’ a pagina 14); unadiscussione sulla struttura dell’archivio Debian (‘L’archivio Debian’ a pagina 17);spiegazione sui diversi server che accettano l’upload di pacchetti(‘Inviare un upload a ftp-master’ a pagina 37); e una discussione sulle risorse chepossono
aiutare i mantainer a curare la qualità dei propri pacchetti.(‘Overview of Debian Maintainer
Tools’ a pagina 79).
Dovrebbe essere chiaro che questo documento non scende nei dettaglitecnici dei pacchetti Debian e neppure su come generare dettipacchetti. Questa guida non spiega nemmeno in dettaglio gli standard acui i pacchetti Debian devono sottostare. Tutte queste informazionipossono
essere trovate nella Debian Policy (http://www.debian.org/doc/debian-policy/).
Inoltre, questo documento non è espressione formale della politicaDebian. Contiene la documentazione per il sistema Debian ei -generalmente convenuti- migliori metodi operativi. Quindi, è
ciò che èchiamato un documento “normativo”.
Capitolo 1. Scopo Di Questo Documento
2
3
Capitolo 2
Applying per diventare un maintainer
2.1
Iniziare
Hai letto tutta la documentazione, sei gone through la Debian New Maintainers’ Guide (http:
//www.debian.org/doc/maint-guide/),hai capito a cosa serve ogni parte del pacchetto
di esempiohello e stai per Debianizzare il tuo softwarepreferito. Ma come diventare uno
sviluppatore Debian in modo da incorporareil tuo lavoro nel Progetto?
Innanzitutto, iscriviti alla lista <[email protected]> se non l’hai ancora fatto.Invia la parola subscribe nelSubject di una emaila <debian-devel-REQUEST@
lists.debian.org>.
In caso di problemi, contatta l’amministratoredelle liste a
<[email protected]>. Altre informazioni sulle mailing listdisponibili possono essere trovate in ‘Mailing list’ a pagina 11.<debian-devel-announce@lists.
debian.org> è un’altra lista essenzialeper chiunque voglia seguire lo sviluppo di Debian.
Dovresti iscriverti e “lurkare” (leggere senza inviare messaggi) per unpò prima di iniziare a
sviluppare e dovresti post la tua intenzione dilavorare su qualcosa per evitare di duplicare gli
sforzi.
Un’ altra buona lista cui iscriversi è <[email protected]>. Vedi ‘Debian mentor e sponsor’ a pagina 5 per i dettagoi. Il canale IRC #debian può ancheesserre
d’aiuto.
Quando hai deciso come vuoi contribuire a Debian GNU/Linux,dovresti metterti in contatto con dei maintainer Debian che lavorano sutasks simili. In questo modo puoi imparare da sviluppatori esperti.Per esempio, se sei interessato a pacchettizzare software esistente perDebian dovresti provare a trovare uno sponsor. Uno sponsor lavoreràcon te sul tuo
pacchetto e ne effettuerà l’upload nell’archivio Debian unavolta che sarà soddisfatto del tuo
lavoro di pacchetizzazione. Puoi trovareuno sponsor inviando una mail alla mailing list
<[email protected]>,descrivendo il tuo pacchetto and yourself (vedi ‘Sponsorizzare pacchetti’ a pagina 77per maggiori informazioni sullo sponsoring). D’altro
canto, se sei interessatonel port di Debian ad architetture alternative o kernel non ancora supportatipuoi iscriverti alle mailinglist relative al tuo port e chiedere da dove iniziare.Infine, se
Capitolo 2. Applying per diventare un maintainer
4
sei interessato a lavorare sulla documentazione o alla QualityAssurance (QA) puoi unirti agli
sviluppatori che lavorano in questi campied inviare patch e miglioramenti.
2.2
Registrarsi come sviluppatore Debian
Prima di decidere di unirti a Debian GNU/Linux, hai bisogno di leggeretutte le informazioni disponibili nell’ Angolo del nuovo manutentore (http://www.debian.org/devel/
join/newmaint). Esso descrive esattamentela preparazione che devi seguire prima di
poterti registrare per diventareuno sviluppatore Debian.Per esempio, prima di iniziare la
procedura devi leggere ilContratto sociale Debian (http://www.debian.org/social_
contract).Diventare sviluppatore significa essere d’accordo con il Contratto socialeDebian
ed impegnarsi a sostenerlo; è molto importante che glisviluppatori siano d’accordo con le
idee essenziali che stanno dietroDebian GNU/Linux. Anche il ManifestoGNU (http://www.
gnu.org/gnu/manifesto.html) può essere una buona lettura.
Il processo per diventare sviluppatore consiste nella verifica dellatua identità e delle tue intenzioni, nonchè il controllo delle tue capacitàtecniche. Considerando che il numero di persone
che lavorano suDebian GNU/Linux è cresciuto a più di 800 personee che i nostri sistemi sono
usati in posti molto importanti dobbiamo stareattenti a non essere compromessi.Quindi, dobbiamo verificare i nuovi manutentori prima di fornire lorodegli accessi sui nostri server e di
permettergli di effettuare degli uploaddi pacchetti.
Prima di registrarti dovresti aver dimostrato che puoi fare del lavorocompetente e contribuire
positivamente. Puoi dimostrarlo inviando dellepatch tramite il Bug Tracking System o avendo
un pacchetto sponsorizzatoda uno sviluppatore Debian per un pò di tempo. Inoltre ci aspettiamoche chi contribuisce sia interessato al Progetto intero e non solo al mantenereil proprio
software. Se puoi aiutare gli altri manutentori inviando maggioriinformazioni su un bug o
magari una patch, fallo!
La registrazione richiede che tu abbia familiarità con la filosofia Debiane la documentazione tecnica. Inoltre, hai bisogno di una chiave GnuPGfirmata da un manutentore. Se la tua
chiave GnuPG non è firmatadovresti provare ad incontrare uno sviluppatore Debian di persona per averela sua firma sulla tua chiave. C’è una Pagina di coordinamento per la firma
delle chiavi GnuPG Key (http://nm.debian.org/gpg.php) chedovrebbe aiutarti a trovare un manutentore vicino a te (se non riesci atrovarlo c’è un modo alternativo per passare il controllo dell’identità puoiinviare un photo ID firmato con la tua chiave GnuPG. Avere la tua chiaveGnuPG firmata è il modo migliore, comunque.Vedi la identification page
(http://www.debian.org/devel/join/nm-step2) per maggioriinformazioni su queste
due opzioni).
Se non hai ancora una chiave OpenPGP, generane una. Ogni sviluppatorene ha bisogno per firmare e verificare gli upload di pacchetti.Dovresti leggere la documentazione del software che
stai usando vistoche vi sono molte informazioni critiche dal punto di vista della sicurezza.Sono
più i problemi di sicurezza dovuti ad errori umani rispetto a quelliimputabili a problemi nel
software or high-powered spy techniques. Vedi‘Mantenere la tua chiave privata’ a pagina 7
per maggiori informazioni sul mantenimento dellatua chiave pubblica.
5
Debian utilizza GNU Privacy Guard (pacchettognupg, versione 1 o superiore) come standard.Puoi comunque usare altre implementazioni di OpenPGP. Nota che OpenPGPè uno
standard aperto basato sull’ RFC2440 (http://www.gnupg.org/rfc2440.html).
L’algoritmo di chiave pubblica raccomandato per lo sviluppo in Debian è il DSA (a volte chiamato “DSS” o “DH/ElGamal”). Comunque possonoessere usati altri tipi di chiavi. La tua
chiave deve essere lunga al meno1024 bit; non c’è motivo di usare una chiave più piccola e
farlo implicaun livello di sicurezza molto più basso. La tua chiave deve essere firmataalmeno
dai tuoi user ID; questo previene lo “user ID tampering”.gpg lo fa automaticamente.
Se la tua chiave pubblica non è su keyserver pubblici come pgp5.ai.mit.edu,leggi la
documentazione disponibile localmente in /usr/share/doc/pgp/keyserv.doc.Quel documento contiene istruzioni su come mettere la tua chiave suikeyserver pubblici. Il New
Maintainer Group metterà la tua chiave pubblicasui 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 perl’autenticazione, piuttosto che per la crittazione.Debian GNU/Linux
non richiede l’uso della crittografia quain alcun modo. Se vivi in un paese dove l’uso della crittografia è proibitoanche per scopi di autenticazione sei pregato di contattarci così chepossiamo
trovare special arrangements.
Per apply as a new maintainer, hai bisogno di un maintainer Debian cheverifichi la tua application (un advocate). Dopo che haicontribuito a Debian per un pò di tempo, e vuoi apply per
diventare unosviluppatore registrato, uno sviluppatore esistente con cui hai lavoratonei mesi
precedenti deve express their belief che puoi contribuire aDebian con successo.
Quando hai trovato un advocate, hai la tua chiave GnuPG firmata e haicontribuito a Debian
per un periodo, sei pronto ad apply.Puoi semplicemente registrarti sulla nostrapagina di application (http://nm.debian.org/newnm.php). Dopo che ti sei registrato, un advocatedeve
confermare la tua application. Quando il tuo advocate ha completatoquesto passo ti verrà assegnato un Application Manager che effettuerà conte i passi del New Maintainer process.Puoi
sempre controllare lo stato sull’applications status board (http://nm.debian.org/).
Per ulteriori dettagli, consulta L’angolodel nuovo manutentore (http://www.debian.org/
devel/join/newmaint) sul sito web Debian. Assicurati di avere familiaritàcoi passi necessari del the New Maintainer process prima di effettuareapplying. Se sei ben preparato, puoi
risparmiare molto tempo dopo.
2.3
Debian mentor e sponsor
La mailing list <[email protected]> è stata creata per novelli manutentorialla ricerca di aiuto sulla pacchettizzazione iniziale ed altri problemi dasviluppatore.
Ogni nuovo sviluppatore è invitato ad iscriversi a questa lista(vedi ‘Mailing list’ a pagina 11
per i dettagli).
Quelli che preferiscono aiuto uno-ad-uno (via email private) dovrebberoscrivere a questa lista
ed uno sviluppatore esperto potrebbe offrire ilsuo aiuto.
6
Inoltre, se hai dei pacchetti pronti per l’inclusione in Debian, ma staiaspettando di finire la
tua new maintainer application potresti riuscire atrovare degli sponsor che effettuino l’upload dei pacchetti per te. Glisponsor sono persone che sono manutentori Debian ufficiali
e cheare willing to criticize ed effettuare l’upload dei pacchetti per te. Coloroi quali cerchino uno sponsor possono richiederne uno a http://www.internatif.org/bortzmeyer/
debian/sponsor/.
Se vuoi essere un mentor e/o uno sponsor, ulteriori informazioni sonodisponibili in
‘Interazione con futuri sviluppatori Debian’ a pagina 77.
7
Capitolo 3
Compiti dello sviluppatore Debian
3.1
Aggiornare le tue informazioni in Debian
Esiste un database LDAP contenente informazioni sugli sviluppatori Debianall’indirizzo
https://db.debian.org/. Qui dovresti inserire le tueinformazioni aggiornarle non appena cambiano. La cosa piu’ importante èdi assicurarsi che l’indirizzo dove la tua email
debian.org vieneinoltrata sia sempre aggiornato, così come l’indirizzo dove impostare latua
sottoscrizione a debian-private, se decidi di iscriverti.
Per ulteriori informazioni circa il database, visitare ‘Il database degli sviluppatori’ a pagina 16.
3.2
Mantenere la tua chiave privata
Sii molto accorto con le tue chiavi private. Non metterle in nessunserver pubblico o macchine
multi-utente, come ad esempio i serverDebian (leggi ‘Macchine Debian’ a pagina 14). Fai una
copia delle tuechiavi; tienine una copia offline. Leggi la documentazione fornitainsieme al
software, leggi le PGP FAQ (http://www.cam.ac.uk.pgp.net/pgpnet/pgp-faq/).
Se aggiungi firme alla tua chiave pubblica, o aggiungi altre identità,puoi aggiornare il server Debian mandando la chiave al server keyring.debian.org Se hai bisogno di aggiungere una chiavecompletamente nuova, o di rimuoverne una vecchia, manda una e-mail
a<[email protected]>. Si applicano le stesse procedure di estrazionechiavi
discusse in ‘Registrarsi come sviluppatore Debian’ a pagina 4.
Puoi trovare una discussione dettagliata sulla manutenzione dellechiavi Debian nella
documentazione del pacchetto debian-keyring.
3.3
Votare
Anche se Debian non è realmente una democrazia, noi usiamo un procedimentodemocratico
per eleggere i nostri leaders e per approvare risoluzionigenerali. Questi procedimenti sono
Capitolo 3. Compiti dello sviluppatore Debian
8
definiti dallaCostituzione Debian (http://www.debian.org/devel/constitution).
A parte l’elezione annuale del leader, le votazioni non sono sistematiche,e non sono svolte alla leggera. Ogni proposta e’ prima discussa sullamailing list <debian-vote@lists.
debian.org> e richiede svariate approvazioni primache il segretario del progetto dia l’inizio
alla procedura di voto.
Non sei obbligato a seguire le discussioni pre-voto, il segretarioannuncerà le votazioni diverse
volte su <[email protected]>(tutti gli sviluppatori dovrebbero essere iscritti a tale lista). Lademocrazia 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 sullapagina di Informazioni sulle votazioni Debian (http://www.debian.org/vote/),insieme alle informazioni su come
fare, sostenere e votare proposte.
3.4
Andare in vacanza
È comune per gli sviluppatori avere periodi di assenza, sia che sianovacanze pianificate o semplicemente essere oberati dal lavoro. La cosaimportante da capire è che gli altri sviluppatori
hanno bisogno disapere se sei in vacanza in modo che possano fare ciò che devono seaccade
un problema con i tuoi pacchetti o altri compiti nel progetto.
Solitamente ciò significa che altri sviluppatori sono autorizzati afare un NMU (vedi ‘NonMaintainer Upload (NMU)’ a pagina 55) del tuo pacchetto se un grossoproblema (bug releasecritical, 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 protected]> mettendo “[VAC] ”all’inizio
del subject del messaggio1 indicando il periodo in cui non sarai raggiungibile. Puoi anche
dareistruzioni speciali su cosa fare se succede un problema.
L’altra cosa da fare è quella di marcarti “in vacanza” nel database LDAP degli sviluppatori Debian (questainformazione è accessibile soltanto dagli sviluppatori Debian). Non dimenticarti
di togliere la flag “in vacanza” quando torni!
3.5
Cooperazione con gli sviluppatori upstream
Una grossa parte del tuo lavoro come mantainer Debian sarà di stare incontatto con gli sviluppatori upstream. Gli utenti Debian a voltesegnaleranno dei bug non specifici di Debian al nostro sistema ditracciamento dei bug. Devi inoltrare queste segnalazioni di bug aglisviluppatori
upstream in modo che possano essere risolti in un futurorilascio upstream.
1
Questo in modo che chi nonvolesse leggere tali messaggi possa filtrarli facilmente.
9
Anche se non è il tuo lavoro risolvere bug non specifici Debian, puoiliberamente farlo se ne
sei capace. Quando lo fai, assicurati di mandarela patch anche agli sviluppatori upstream.
Gli utenti e sviluppatoriDebian 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 pacchettosia conforme ai requisiti della
politica Debian, dovresti proporre talimodifiche agli sviluppatori upstream in modo che quando rilascerannouna nuova versione, tu non dovrai modificarne i sorgenti. Qualunquemodifica
tu debba fare, cerca sempre di non separarti dai sorgentiupstream.
3.6
Gestire i bug release-critical
Generalmente dovresti gestire le segnalazioni di bug sui tuoi pacchetticome descritto nella
sezione ‘Gestire i bug’ a pagina 41. Nonostante ciò,esiste una speciale categoria di bug di cui
devi prenderti cura – icosiddetti release-critical bugs (RC bugs). Tutti le segnalazioni di bugcon
severità critica, grave o seria hanno unimpatto sulla possibilità che il pacchetto venga incluso
nel prossimorilascio stabile di Debian.Questi bug possono ritardare il rilascio e/o giustificarne
la rimozionedurante il periodo di “freeze”. Ecco perchè questi bug devono esserechiusi prima
possibile.
Gli sviluppatori che fanno parte del gruppo di Assicurazione Qualità (http://qa.debian.
org/) seguono tutti quei bug e tentano ad aiutarequando possibile. Se per qualche ragione
non riesci a risolvere un bug RCin un tuo pacchetto entro 2 settimane, dovresti o chiedere
aiuto mandandouna e-mail al gruppo di Assicurazione Qualità (QA) <debian-qa@lists.
debian.org>oppure spiegare le tue difficoltà e presentare un piano per risolverlemandando
una e-mail alla segnalazione del bug. Altrimenti, qualcuno delgruppo QA potrebbe avere
intenzione di effettuare un Non-Mantainer Upload(vedi ‘Non-Maintainer Upload (NMU)’ a
pagina 55) dopo aver provato a contattarti (potrebbero nonaspettare tanto quanto fanno di
solito prima di fare il loro NMU se nonvedono nessuna tua recente attività nel BTS).
3.7
Ritirarsi
Se scegli di abbandonare il progetto Debian, dovresti assicurarti dicompiere i seguenti
passaggi:
1 Abbandonare tutti i tuoi pacchetti, come descritto in ‘Abbandonare un pacchetto’ a
pagina 50.
2 Mandare una e-mail spiegando perchè lasci il progetto a <debian-private@lists.
debian.org>.
3 Fare sapere a chi mantiene le chiavi Debian (<[email protected]>)che
lasciil progetto.
10
11
Capitolo 4
Risorse per gli sviluppatori Debian
In questo capitolo troverai una road map molto concisa delle mailinglist Debian, le macchine
Debian che potrebbero essere disponibili perte come sviluppatore e tutte le altre risorse che
sono disponibiliper aiutarti nel tuo lavoro di mantainer.
4.1
Mailing list
Gran parte delle conversazioni tra sviluppatori (e utenti) Debian sonogestite attraverso un
grande numero di mailing list che ospitiamo all’indirizzolists.debian.org (http://
lists.debian.org/).Per ulteriori informazioni su come sottoscriversi o togliersi, come
postaree come non postare, dove trovare i vecchi post e come cercarli, comecontattare i
mantainer delle liste e vedere varie altre informazioni circa lemailing list, per favore vedi
http://www.debian.org/MailingLists/.Questa sezione coprirà solo gli aspetti delle
mailing list che sono diparticolare interesse per gli sviluppatori.
4.1.1
Regole di base
Quando rispondi ai messaggi sulla mailing list, per favore non mandareuna copia carbone
(CC) al mittente originario a meno che nonlo richiedano esplicitamente. Chiunque mandi un
messaggio a una mailinglist 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 cuistai rispondendo. In generale, per favore rispetta
le convenzioniusuali per mandare messaggi.
Per favore leggi il codice di condotta (http://www.debian.org/MailingLists/
#codeofconduct) per ulteriori informazioni.
4.1.2
Principali mailing list di sviluppo
Le mailing list Debian di base che gli sviluppatori dovrebbero usare sono:
Capitolo 4. Risorse per gli sviluppatori Debian
12
• <[email protected]>, usata per annunciare cose importanti agli sviluppatori. Ci si aspetta che tutti gli sviluppatori siano iscritti a questa
lista.
• <[email protected]>, usata per discussioni tecniche riguardanti lo
sviluppo.
• <[email protected]>, dove la policy Debian viene discussa e
votata.
• <[email protected]>, usate per discutere questioni non tecniche
riguardanti il progetto.
Sono disponibili altre mailing list per una varietà di argomenti speciali,vedi http://lists.
debian.org/ per una lista.
4.1.3
Liste speciali
<[email protected]> è una mailing list speciale per discussioni privatetra gli sviluppatori Debian. È intesa per essere usata per post che perqualunque ragione
non dovrebbero essere apertamente pubblicati. Per questo,è una lista a basso traffico, e gli
utenti sono pregati di non usare<[email protected]> a meno che non
sia assolutamente necessario.Inoltre, non inoltrare email da questa lista a nessuno. Gliarchivi
di questa lista non sono disponibili sul web per ovvie ragioni,ma puoi consultarli usando il
tuo account di shell su lists.debian.orge guardando nella directory ~debian/archive
/debian-private.
<[email protected]> è una mailing list speciale usata per conservare lacorrispondenza legata a Debian, come quando si contattano gli autoriupstream circa licenze, bug, ecc. o si discute il progetto con altre personedove potrebbe essere utile avere la
discussione archiviata da qualche parte.
4.1.4
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 considerase sia più appropriato usare un alias (via un
file .forward-aliasname sumaster.debian.org, che si traduce in un ragionevole [email protected]) o una mailing list autogestita suAlioth.
Se decidi che una mailing list regolare su lists.debian.org è realmente quelloche vuoi, vai avanti
e compila una richiesta, seguendo l’HOWTO (http://www.debian.org/MailingLists/
HOWTO_start_list).
4.2
13
Canali IRC
Diversi canali IRC sono dedicati allo sviluppo di Debian. Sono principalmenteospitati sulla rete freenode (http://www.freenode.net/)(precedentemente nota come Open Projects
Network). La voce di DNSirc.debian.orgè un alias di irc.freenode.net.
Il canale principale per Debian in generale è #debian. Questo èun grosso canale “generalpurpose” dove gli utenti possono trovare notizierecenti nel topic e servite dai bot. #debian è
per gli utentiche parlano inglese; ci sono anche #debian.de, #debian-fr,#debian-br e altri canali
chiamati in modo simile per gli utentiche 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 150persone 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 suotopic è comunemente pieno di informazioni interessanti per
glisviluppatori.
Siccome #debian-devel è un canale aperto, non dovresti parlarequi di questioni che sono discusse in <[email protected]>.Esiste un altro canale per questo scopo,
è chiamato #debian-privateed è protetto da una chiave. La chiave è disponibile negli archivi didebian-private in master.debian.org:~debian/archive/debian-private/,usa
sempilcemente zgrep cercando #debian-private intutti 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 floppydi
boot (ovvero l’installer). #debian-doc è usato occasionalmenteper 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, peresempio #debian-devel-fr per
le persone che parlano Franceseinteressate allo sviluppo di Debian.
Esistono canali dedicati a Debian anche su altri network IRC, in particolaresul network IRC
Open and free technology community (OFTC) (http://www.oftc.net/).
4.3
Documentazione
Questo documento contiene molte informazioni molto utili agli sviluppatoriDebian, ma non
può contenere tutto. Per la maggior parte degli altri documentiinteressanti è presente il link
dall’Angolo degli sviluppatori (http://www.debian.org/devel/). Prenditi il tempo di
consultare tuttii collegamenti, imparerai molte più cose.
4.4
14
Macchine Debian
Debian possiede diversi computer che fungono da server, la maggiorparte dei quali hanno
funzioni critiche nel pregetto Debian. La maggiorparte delle macchine sono usate per attività
di porting, e hanno tutteuna connessione permanente a Internet.
La maggior parte delle macchine sono disponibili per essere usatedagli sviluppatori, finchè
si attengano alle regole imposte nellaPolicy di utilizzo delle macchine Debian (http://www.
debian.org/devel/dmup).
In generale, puoi usare queste macchine a tua discrezione per scopicorrelati a Debian. Per favore sii cortese con gli amministratori disistema, e non usare tonnellate di spazio disco, banda o
CPU senzaaver 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 chiaviSSH installate su
macchine Debian. Evita metodi di login o di upload chemandano le password su Internet in
chiaro, come telnet, FTP, POP ecc.
Per favore non mettere nessun materiale non correlato a Debian sui serverDebian, a meno che
tu non ne abbia il permesso.
La lista aggiornata delle macchine Debian è disponibile all’indirizzohttp://db.debian.
org/machines.cgi. Quella pagina web contiene i nomi dellemacchine, informazioni sui
contatti, informazioni su chi può entrarci,le chiavi SSH ecc.
Se hai un problema con il funzionamento di un server Debian, e pensiche gli operatori di sistema debbano esserne informati, il team degliamministratori di sistema Debian è raggiungibile
a <[email protected]>.
Se hai un problema con un certo servizio non correlato all’amministrazionedi sistema (come
pacchetti da rimuovere dall’archivio, suggerimenti peril sito web, ecc.), generalmente riporterai un bug su uno“pseudo-pacchetto”. Vedi ‘Riportare bug’ a pagina 73 per informazioni su
comeriportare i bug.
4.4.1
Il server bugs
bugs.debian.org è la locazione canonica del sistema di tracciamentodei bug (BTS). Se stai
pianificando di fare qualche analisi statisticao di processare i bug Debian, questo sarebbe il posto per farlo.Per favore esplica le tue intenzioni su <[email protected]>
primadi implementare qualsiasi cosa, comunque, per non duplicare inutilmentegli sforzi o
sprecare del tempo.
Tutti gli sviluppatori Debian hanno un account su bugs.debian.org.
4.4.2
15
Il server ftp-master
Il server ftp-master.debian.org mantiene la canonica copiadell’archivio Debian (a parte i pacchetti non-US). Generalmente,gli upload di pacchetti vanno su questo server; vedi
‘Effetuare un upload’ a pagina 37.
I problemi con l’archivio FTP Debian devono generalmente essere riportaticome bug sullo pseudo-pacchetto ftp.debian.org o un’emaila <[email protected]>, ma vedi
anche le procedure in ‘Spostare, rimuovere, rinominare, adottare e abbandonare pacchetti’ a
pagina 49.
4.4.3
Il server non-US
Il server non-US, non-us.debian.org, mantiene la canonica copiadella parte non-US dell’archivio Debian. Se devi effettuare l’upload diun pacchetto in una delle sezioni non-US, fallo
su questo server; vedi‘Inviare un upload a non-US’ a pagina 38.
I problemi con l’archivio dei pacchetti non-US generalmente dovrebberoessere riportati come
bug sullo pseudo-pacchettononus.debian.org (nota la mancanza del trattino tra“non” e
“us” nel nome dello pseudo-pacchetto — questo percompatibilità all’indietro). Ricorda di controllare se qualcun’altro abbiao meno già riportato il problema sul sistema di tracciamento dei
bug (http://bugs.debian.org/nonus.debian.org).
4.4.4
Il server www-master
Il server web principale è www-master.debian.org.Tiene le pagine web ufficiali, la facciata
di Debian per moltinewbie.
Se scovi un problema nel server web Debian, generalmente dovresti riportareun bug contro lo
pseudo-pacchetto www.debian.org.Ricorda di controllare se qualcun’altro abbia o meno già
riportato ilproblema sul sistema di tracciamento dei bug (http://bugs.debian.org/www.
debian.org).
4.4.5
Il server web people
people.debian.org è il server usato per le pagine webpersonali degli sviluppatori su
qualunque cosa correlata a Debian.
Se hai delle informazioni su Debian che vuoi mettere a disposizionesul web,
puoi farlo mettendo il materiale nella directorypublic_html sotto la tua home directory supeople.debian.org,
che sarà quindi disponibileall’indirizzo
http://people.debian.org/~your-user-id/.
Dovresti usare questa particolare locazione solo perchè ne verranno fattedelle copie di backup,
mentre in altri host no.
16
Di solito l’unica ragione per cui potresti voler usare un host diverso èquando hai bisogno di pubblicare materiale soggetto alle restrizioni diesportazione degli U.S.A., in
qual caso puoi usare uno degli altri serversituati fuori dagli Stati Uniti, come il già
menzionatonon-us.debian.org.
Se hai qualche domanda manda un’email a <[email protected]>.
4.4.6
Il server CVS
Il nostro server CVS è situato su cvs.debian.org.
Se hai bisogno di usare un server CVS che sia pubblicamente accessibile,per esempio, per
aiutarti a coordinare il lavoro su un pacchetto tramolti sviluppatori diversi, puoi richiedere
un’area CVS sul server.
Generalmente, cvs.debian.org offre una combinazione di accessoCVS locale, accesso
client-server anonimo a sola lettura e pieno accessoclient-server attraverso ssh. Inoltre, si
può accedereall’area CVS in sola lettura via web all’indirizzo http://cvs.debian.org/.
Per richiedere un’area CVS, manda una richiesta via email a<[email protected]>.
Includi nella richiesta il nome dell’areaCVS richiesta, l’account Debian che dovrebbe detenere
la root dell’areaCVS e perchè ne hai bisogno.
4.5
Il database degli sviluppatori
Il database degli sviluppatori, all’indirizzo https://db.debian.org/,è una directory
LDAP per gestire gli attributi degli sviluppatoriDebian. Puoi usare questa risorsa per cercare la lista deglisviluppatori Debian. Una parte di queste informazioni è accessibileattraverso
il servizio finger sui server Debian, provafinger [email protected] per vedere
che cosa riporta.
Gli sviluppatori possono effettuare il login nel database (https://db.debian.org/login.
html) per cambiare diverse informazioni su diloro, come:
• indirizzo di inoltro per la tua email debian.org
• iscrizione a debian-private
• se sei assente
• informazioni personali come il tuo indirizzo, nazione, latitudine e longitudine del posto
dove vivi per usarli nella mappa mondiale degli sviluppatori Debian (http://www.
debian.org/devel/developers.loc), numero di telefono e di fax, nickname IRC e
pagina web.
• password e shell preferita sulle macchine del progetto Debian
17
Naturalmente, la maggior parte delle informazioni non sono accessibili alpubblico. Per ulteriori informazioni per favore leggi la documentazioneonline che puoi trovare all’indirizzo
http://db.debian.org/doc-general.html.
Uno può anche inviare le sue chiavi SSH perchè siano usate perl’autenticazione sulle macchine
ufficiali Debian, e persino aggiungerenuove voci DNS *.debian.net. Queste funzionalità sono
documentateall’indirizzo http://db.debian.org/doc-mail.html.
4.6
L’archivio Debian
La distribuzione Debian GNU/Linux contiene un grande numero di pacchetti(.deb, correntemente sono circa 9000) e pochialtri file aggiuntivi (come la documentazione e le immagini dei
dischidi installazione).
Ecco un albero di directory di esempio di un archivio Debian completo:
dists/stable/main/
dists/stable/main/binary-i386/
dists/stable/main/binary-m68k/
dists/stable/main/binary-alpha/
...
dists/stable/main/source/
...
dists/stable/main/disks-i386/
dists/stable/main/disks-m68k/
dists/stable/main/disks-alpha/
...
dists/stable/contrib/
dists/stable/contrib/binary-i386/
dists/stable/contrib/binary-m68k/
dists/stable/contrib/binary-alpha/
...
dists/stable/contrib/source/
dists/stable/non-free/
dists/stable/non-free/binary-i386/
dists/stable/non-free/binary-m68k/
dists/stable/non-free/binary-alpha/
...
dists/stable/non-free/source/
dists/testing/
dists/testing/main/
...
18
dists/testing/contrib/
...
dists/testing/non-free/
...
dists/unstable
dists/unstable/main/
...
dists/unstable/contrib/
...
dists/unstable/non-free/
...
pool/
pool/main/a/
pool/main/a/apt/
...
pool/main/b/
pool/main/b/bash/
...
pool/main/liba/
pool/main/liba/libalias-perl/
...
pool/main/m/
pool/main/m/mailx/
...
pool/non-free/n/
pool/non-free/n/netscape/
...
Come puoi vedere, la directory di più alto livello contiene duedirectory,dists/ e pool/. L’ultima èuna “pool” nella quale i pacchetti ci sono veramente,e che è gestita dal database di manutenzione dell’archivio e irelativi programmi. La prima contiene le distribuzioni, stable,testing
e unstable. I file Packages eSources nelle sottodirectory delle distribuzioni possonoreferenziare file nella directory pool/. L’albero delledirectory sotto ognuna delle distribuzioni
è arrangiato in manieraidentica agli altri. Ciò che sotto descriviamo per stableè ugualmente
applicabile alle distribuzioni unstable etesting.
dists/stable contiene tre directory, chiamate main,contrib e non-free.
In ciascuna di queste aree c’è una directory per i pacchetti sorgente(source) e una directory
per ogni architettura supportata(binary-i386, binary-m68k, ecc.).
L’area main contiene delle directory addizionali chetengono le immagini disco e frammenti
essenziali di documentazionerichiesti per installare la distribuzione Debian suuna specifica
architettura (disks-i386,disks-m68k, ecc.).
4.6.1
19
Sezioni
La sezione main dell’archivio Debian è quella che formala ditribuzione Debian GNU/Linux
ufficiale. Lasezione main è ufficiale perchè è pienamente conformea tutte le linee guida.
Le altre sezioni no, con gradualità diverse;perciò non fanno ufficialmente parte di Debian
GNU/Linux.
Ogni pacchetto nella sezione main deve essere pienamente conformealle Linee guida Debian sul software libero (http://www.debian.org/social_contract#
guidelines)(DFSG)e a tutti gli altri requisiti della policy come descritto nellaPolicy
Debian (http://www.debian.org/doc/debian-policy/). Le DFSG sono lanostra
definizione di “software libero.” controlla lapolicy Debian per i dettagli.
I pacchetti nella sezione contrib devono conformarsi alleDFSG, ma possono non soddisfare altri
requisiti. Per esempio,possono dipendere da pacchetti non-free.
I pacchetti che non sono conformi alla DFSG sono posti nellasezione non-free. Questi pacchetti
non sono consideratiparte della distribuzione Debian, anche se diamo supporto perl’utilizzo
e forniamo infrastrutture (come il nostro sistema ditracciamento dei bug e mailing list) per i
pacchetti di softwarenon-free.
La Policy Debian (http://www.debian.org/doc/debian-policy/) contieneuna definizione più esatta delle tre sezioni. La discussionesoprastante è 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: distribuendosolo le sezioni main e contrib, uno può evitarequalunque rischio di tipo legale. Alcuni
pacchetti nella sezionenon-free non ammettono per esempio la distibuzionecommerciale.
D’altra parte, un commerciante di CD-ROM potrebbe facilmente controllare le licenze di ogni
singolo pacchettoin non-free e includere tutti quelli che può nel CD-ROM.(Siccome questo
varia enormemente da un commerciante all’altro, questolavoro non può essere svolto dagli
sviluppatori Debian.)
Nota anche che il termine “sezione” è usato anche per riferirsi allecategorie che simplificano l’organizzazione e la consultazione deipacchetti disponibili, p. es. admin, net, utilsecc.
Una volta queste sezioni (più che altro sottosezioni) esistevanonella forma di sottodirectory
nell’archivio Debian. Oggi queste esistonosolo nel campo “Section” degli header dei pacchetti.
4.6.2
Architetture
Nei primi tempi, il kernel Linux era disponibile solo per le piattaformeIntel i386 (o maggiori),
e così anche Debian. Ma quando Linux divennesempre più popolare, il kernel fu portato anche
su altre architetture.
Il kernel Linux 2.0 supporta Intel x86, DEC Alpha, SPARC, Motorola680x0 (come Atari, Amiga
e i Macintosh), MIPS, e PowerPC. Il kernelLinux 2.2 supporta ancora più architetture, incluse
ARM e UltraSPARC.Siccome Linux supporta quelle piattaforme, Debian decise che anch’essaavrebbe dovuto farlo. Quindi, Debian sta sviluppando dei porting; ineffetti, abbiamo anche
20
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 GNU/Linux 1.3 è disponibile solo per i386. Debian 2.0uscì per architetture i386 e m68k.
Debian 2.1supporta architetture i386, m68k, alpha,e sparc. Debian 2.2 aggiunse il supporto per
architetturepowerpc e arm. Debian 3.0 aggiunge il supporto acinque nuove architetture: ia64,
hppa, s390,mips and mipsel.
Informazioni per sviluppatori e utenti circa specifici port sonodisponibili nelle pagine web dei
portDebian (http://www.debian.org/ports/).
4.6.3
Pacchetti
Ci sono due tipi di pacchetti Debian, nominalmente pacchettisorgenti e binari.
I pacchetti sorgenti consistono di due o tre file: un file.dsce o un file .tar.gz o sia
un.orig.tar.gz che un file .diff.gz.
Se un pacchetto è sviluppato specialmente per Debian e non è distribuitoal di fuori di Debian,
c’è solo un file .tar.gz checontiene i sorgenti del programma. Se un pacchetto è distribuitoanche altrove, il file .orig.tar.gz contiene il cosiddetto codice sorgente upstream, che è il
codicesorgente che è distribuito dal mantainer upstream(spesso l’autore del software). In questo
caso, il.diff.gz contiene le modifiche effettuate dalmantainer Debian.
Il file .dsc elenca tutti i file nel pacchettosorgente insieme ai checksum (md5sums) e
qualcheinformazione addizionale sul pacchetto (mantainer, versione, ecc.).
4.6.4
Distribuzioni
Il sistema di directory descritto nel capitolo precedente è a suavolta contenuto nelle directory
delle distribuzioni.Ogni distribuzione è in realtà contenuta nella directorypool al livello più alto
dello stesso archivio Debian.
Per riepilogare, l’archivio Debian ha una directory di root in unserver FTP. Per esempio, nel
sito mirrorftp.us.debian.org, l’archivio Debian stesso ècontenuto in /debian, che è una
locazione comune(un altra è /pub/debian).
Una distribuzione comprende pacchetti Debian sorgenti e binarie i rispettivi file indice
Sources e Packages,contenenti le informazioni degli header da tutti quei pacchetti.I primi
sono contenuti nella directory pool/, mentrei secondi sono contenuti nella directory dists
/dell’archivio (per compatibilità all’indietro).
Stable, testing e unstable
Ci sono sempre distribuzioni chiamate stable (residente indists/stable), una chianata testing (residente indists/testing) e una chiamata unstable (residente indists/unstable).
Questo riflette il processo di sviluppo delprogetto Debian.
21
Lo sviluppo attivo viene fatto nella distrubuzione unstable(ecco perchè questa distribuzione viene a volte chiamata ladistribuzione 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 tuttofunzioni propriamente in questa distribuzione, a volte è
letteralmenteinstabile.
“testing” è generata automaticamente prendendoi pacchetti da unstable se questi soddisfano
certi criteri. Questicriteri dovrebbero assicurare una buona qualità per i pacchetti intesting.
L’aggiornamento a testing è lanciato ogni giorno dopo chei nuovi pacchetti vengano installati.
Vedi ‘Ulteriori informazioni sulla distribuzione testing’ in questa pagina.
Dopo un periodo di sviluppo, una volta che il release manager lo ritieneopportuno, la distribuzione testing viene “congelata”, il chesignifica che le regole che controllano come i pacchetti
sono spostatida unstable a testing vengono ristrette. I pacchettitroppo bacati sono rimossi. Nessun cambiamento è ammesso intesting a eccezione dei fix dei bug. Dopo che è passato un po’di
tempo, dipendentemente dai progressi, la distribuzione testingva in uno stato di ‘deep freeze’,
durante il quale non viene fatta alcunamodifica su di essa a eccezione di quelle necessarie per il
sistema diinstallazione. Questo è chiamato un “ciclo di test”,e può durare fino a due settimane.
Ci possono essere diversi ciclidi test, finchè la distribuzione è pronta per il rilascio, comedeciso
dal release manager. Alla fine dell’ultimo ciclo di test,la distribuzione testing è rinominata stable,rimpiazzando la vecchia distribuzione stable, che a quelpunto viene rimossa (anche se può
essere sempre trovata all’indirizzoarchive.debian.org).
Questo ciclo di sviluppo è basato sulla supposizione che la distribuzioneunstable diventa stable
dopo che è passata un periodo ditempo in testing. Persino una volta che una distribuzione
vieneconsiderata stabile, inevitabilmente rimangono ancora dei bug —ecco perchè la distribuzione stable viene ogni tanto aggiornata. Comunque,questi aggiornamenti sono controllati molto attentamente e devono essereintrodotti nell’archivio individualmente, per ridurre
il rischio di introdurrenuovi bug. Puoi trovare le aggiunte proposte per stable nelladirectory
proposed-updates. Questi pacchetti inproposed-updates che passano l’ispezione sono
periodicamentespostati in blocco nella distribuzionestable 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 duranteil periodo di “freeze”, siccome la
distribuzione unstablerimane al suo posto in parallelo con testing.
Ulteriori informazioni sulla distribuzione testing
Gli script che aggiornano la distribuzione testing vengonolanciati ogni giorno dopo l’installazione dei pacchetti aggiornati.Generano i file Packages per la distribuzione testing,ma lo
fanno in modo intelligente cercando di evitare qualsiasi inconsistenzae cercando di usare solo
pacchetti non bacati.
L’inclusione di un paccchetto da unstable è soggetta alle seguenticondizioni:
• Il pacchetto deve essere stato disponibile in unstable per diversigiorni; il numero preciso
dipende dal campo “urgency” dell’upload. È 10 giorniper urgenza bassa, 5 giorni per
22
urgenza media e 2 giorni per urgenza elevata.Questi periodi possono essere raddoppiati
durante un freeze.
• Deve avere meno bug release-critical rispetto alla versione disponibile intesting;
• Deve essere disponibile per tutte le architetture per cui è statoprecedentemente fatto il build. ‘L’utility madison’ a pagina 26 può essere interessanteper controllare
quell’informazione.
• Non deve infrangere alcuna dipendenza di un pacchetto che è già disponibilein testing;
• I pacchetti sui quali dipende devono o essere disponibili in testingo essere accettati in
testing contemporaneamente (e lo saranno serispettano tutti i criteri necessari);
Per scoprire se un pacchetto stia o meno progredendo in testing vedil’output dello script
di testing sulla pagina web delladistribuzione testing (http://www.debian.org/devel/
testing), oppure usa ilprogramma grep-excuses che è nel pacchettodevscripts. Questa utility può essere facilmenteusata in un crontab(5) per tenere le personeinformate sul
progresso dei loro pacchetti in testing.
Il file update_excuses non fornisce sempre la ragione precisaper la quale il pacchetto è stato rifiutato, uno può dovere trovarlaper proprio conto cercando cosa potrebbe impedire l’inclusione del pacchetto.La pagina web testing (http://www.debian.org/devel/testing)
forniscequalche altra informazione circa i problemi comuni che possono causareguai 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 ilrelease
manager che forzerà l’inclusione dei pacchetti.
In generale, per favore riferisciti alla pagina web testing (http://www.debian.org/
devel/testing) per ulteriori informazioni. Include ancherisposte a qualcuna delle domande
poste più di frequente.
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 temporaneaper 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 distribuzioneunstable (ma nonostante ciò esiste una ragione perfarne un pacchetto). Gli utenti che
scaricano e installano pacchettida experimental ci si aspetta che siano stati debitamenteavvisati.
In breve, dalla distribuzione experimental nonci si può aspettare nulla.
Queste sono le linee di sources.list(5) perexperimental:
deb http://ftp.xy.debian.org/debian/ ../project/experimental
maindeb-src http://ftp.xy.debian.org/debian/ ../project/experimental main
23
Se esiste una possibilità che il software possa fare gravi danni a unsistema, è altamente probabile che sia meglio metterlo in experimental.Per esempio, un file system compresso sperimentale
dovrebbe probabilmenteandare in experimental.
Ogni volta che c’è una nuova versione upstream di un pacchetto che introducenuove features ma ne infrange un gran numero di vecchie, o non si dovrebbefarne l’upload o si dovrebbe farlo in experimental.Una nuova versione beta di qualche software che usa una configurazionecompletamente differenrte può andare in experimental, adiscrezione del mantainer. Se
stai lavorando su una situazione in cuil’aggiornamento è incompatibile o complesso puoi anche usareexperimental come un’area di stasi, in modo che i testerpossano ottenerne un accesso
rapido.
Qualche software sperimentale può lo stesso andare in unstable,con qualche avviso nella descrizione, ma non è raccomandato in quanto ipacchetti da unstable ci si aspetta che si propaghino
intesting e quindi in stable. Non dovresti temere diusare experimental siccome non causa alcun
dolore agliftpmaster, i pacchetti in experimental vengono rimossi automaticamenteuna volta
che effettui l’upload del pacchetto in unstablecon un numero di versione più alto.
Nuovi software che probabilmente non danneggeranno il tuo sistema possonoandare
direttamente in unstable.
Un alternativa a experimental è di usare il tuo spazio webpersonale su people.debian.org.
4.6.5
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 pacchettivengono spostati da ‘unstable’ a ‘testing’ come si
avvicinano a unacondizione di stabilità, ‘sid’ stessa non viene mai rilasciata.Così come i soliti
contenuti di una distibuzione Debian, ‘sid’ contienepacchetti per architetture che non sono
ancora ufficialmente supportate orilasciate da Debian. Queste architetture sono pianificate a
essereintegrate 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 serverFTP e HTTP Debian. Quindi, se avessimo chiamato ‘testing’ la directoryche contiene la versione candidata alla release, avremmo dovutorinominarla ‘stable’ quando
la versione fosse stata rilasciata, laqual cosa avrebbe forzato tutti i mirror FTP a riscaricarsi
l’interadistribuzione (che è abbastanza grossa).
D’altro canto, se avessimo chiamato sin dall’inizio le directory delledistribuzioni Debian-x.y, La
gente penserebbe che la releaseDebian x.y è disponibile. (Ciò è successo in passato, unvenditore di CD-ROM costruì un cdrom Debian 1.0 basato su una versionedi sviluppo pre-1.0. Questa
è la ragione per cui la prima releaseufficiale Debian fu la 1.1 e non la 1.0.)
Quindi, i nomi delle directory delle distribuzioni nell’archiviosono determinate dai loro nomi in codice e non dal loro stato direlease (p.es. ‘slink’). Questi nomi rimangono sempre gli
24
stessidurante il periodo di sviluppo e dopo il rilascio; linksimbolici, che possono essere facilmente cambiati, indicano larelease corrente della distribuzione stabile. Ecco perchéle directory
reali delle distribuzioni usano i nomi incodice, mentre link simbolici per stable,testing, e unstable
puntano alle directoryappropriate delle distribuzioni.
4.7
Mirror Debian
I vari archivi per i download e il sito web hanno diversi mirrordisponibili in modo da non
sottoporre i nostri server a carichidi lavoro troppo pesanti. In effetti, alcuni nostri server nonsono pubblici — al loro posto, una prima serie di mirrorsi bilanciano il carico. In questo modo
gli utenti accedono sempreai mirror e si abituano ad usarli, la qual cosa permette a Debiandi
distribuire meglio i propri requisiti di banda su diversiserver e network, e di base fa in modo
che gli utenti evitino diaccanirsi su una locazione primaria. Nota che la prima serie dimirror è
sempre aggiornata in quanto si aggiornano al comandodei siti interni (chiamiamo questa cosa
“push mirroring”).
Tutte le informazioni sui mirror Debian, inclusa una lista dei serverFTP/HTTP pubblici disponibili, possono essere trovate all’indirizzohttp://www.debian.org/mirror/. Questa utile
pagina include ancheinformazioni e strumenti che possono esserti d’aiuto se sei interessatoa
impostare un mirror tuo, sia per uso interno o di pubblico accesso.
Nota che i mirror sono generalmente gestiti da terze parti che sonointeressate ad aiutare
Debian, perciò gli sviluppatori generalmentenon hanno un account su quelle macchine.
4.8
Il sistema incoming
Il sistema incoming è responsabile di collezionare pacchetti aggiornatie installarli nell’archivio Debian. Consiste in un insieme di directorye script che sono installati sia su
ftp-master.debian.org sia sunon-us.debian.org.
I pacchetti vengono inviati in upload da tutti i mantainer in unadirectory chiamata
unchecked. Questa directory vienescandita ogni 15 minuti dallo script katie, cheverifica
l’integrità dei pacchetti inviati in upload e le lorofirme crittografiche. Se il pacchetto viene considerato prontoper essere installato, è spostato nella directory accepted.Se questo è il primo
upload del pacchetto, esso viene spostato nelladirectory new, dove aspetta l’approvazione dei
ftpmaster.Se il pacchetto contiene file che devono essere installati a mano vienespostato nella
directory byhand, dove aspetta l’installazionemanuale da parte dei ftpmaster. Altrimenti, se
viene scovato un qualsiasierrore, il pacchetto viene rifiutato e spostato nella directoryreject.
Una volta che il pacchetto viene accettato il sistema manda una mail diconferma al mantainer, chiude tutti i bug marcati come risoltidall’upload e gli auto-builder possono cominciare
a ricompilarlo. Il pacchettoè ora pubblicamente accessibile all’indirizzo http://incoming.
debian.org/ (nonesiste nessun URL del genere per i pacchetti nell’archivio non-US) finchènon viene realmente installato nell’archivio Debian. Questo accade solouna volta al giorno,
25
il pacchetto viene poi rimosso da incoming e installatonella pool con tutti gli altri pacchetti. Una volta che tutti gli altriaggiornamenti (per esempio la generazione dei nuovi file indicePackages e Sources) vengono completati, vieneinvocato uno script speciale per chiedere
a tutti i mirror primari diaggiornarsi.
Il software di manutenzione dell’archivio manderà inoltre i file.changes firmati con OpenPGP/GnuPG che hai inviato inupload alle mailing list appropriate. Se un pacchetto viene rilasciato conDistribution: impostato a ‘stable’, l’annuncio è inviato a<debian-changes@
lists.debian.org>. Invece, se il pacchetto viene rilasciato conDistribution: impostato a ‘unstable’ oppure ‘experimental’,l’annuncio verrà inviato a <debian-devel-changes@
lists.debian.org>.
Tutti gli sviluppatori Debian hanno accesso in scrittura alla directoryunchecked in modo da
inviare in upload i loro pacchetti,hanno anche tale accesso alla directory reject in mododa rimuovere i loro upload non validi o per spostare qualche file dinuovo nella directory
unchecked. Ma tutte le altre directorysono scrivibili solo dagli ftpmaster, ecco perchè non
puoi rimuovereun upload una volta che è stato accettato.
4.8.1
Incoming ritardato
La directory unchecked ha una speciale sottodirectoryDELAYED. Essa stessa è suddivisa in
nove directorychiamate da 1-day a 9-day. I pacchettiche vengono inviati in upload in una
di queste directory verrannospostati nella directory unchecked reale dopo il corrispondentenumero di giorni. Questo viene fatto da uno script che è lanciatoogni giorno e che sposta i
pacchetti tra le varie directory.Quelli che sono in “1-day” sono installati in uncheckedmentre
gli altri vengono spostati nelle directory adiacenti (peresempio, un pacchetto in 5-day sarà
spostato in4-day). Questa feature è particolarmente utile allepersone che stanno facendo dei
non-maintainer uploads. Inveceche aspettare prima di fare l’upload di un NMU, è inviato
inupload appena è pronto in una di quelle directory DELAYED/x-day.Questo lascia il corrispondente numero di giorni al mantainerper reagire e fare loro stessi l’upload di un altro fix se
nonsono completamente soddisfatti dal NMU. In alternativa possonorimuovere il NMU.
L’uso della feature delayed può essere semplificato con un pocodi integrazione nel tuo
strumento di upload. Per esempio, seusi dupload (vedi ‘dupload’ a pagina 83), puoi
aggiungerequesto pezzetto al tuo file di configurazione:
$delay = ($ENV{DELAY} || 7);$cfg{’delayed’} = {
fqdn => "ftp-master.debian.org", login => "iltuologindebian",
=> "scpb"};
incoming => "/org
Una volta che hai fatto tale modifica, dupload può essereusato per effettuare facilmente
l’upload di un pacchetto in una delledirectory delayed:
DELAY=5 dupload --to delayed <changes-file>
4.9
4.9.1
26
Informazioni sui pacchetti
Sul web
Ciascun pacchetto ha diverse pagine web dedicate.http://packages.debian.org/package-namevisual
ogni versione del pacchetto disponibile nellevarie distribuzioni. Ogni versione si collega a
una paginache 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 perogni pacchetto. Puoi vedere i bug
di un certo pacchetto all’indirizzo http://bugs.debian.org/package-name.
4.9.2
L’utility madison
madison è un’utility a linea di comando che è disponibilesu entrambi
ftp-master.debian.org e non-us.debian.org.Usa un singolo argomento corrispondente al nome di un pacchetto. Comerisultato visualizza quale versione del pacchetto
è disponibile perogni combinazione di architettura e distribuzione. Un esempio lospiegherà
meglio.
$ madison libdbd-mysql-perllibdbd-mysql-perl |
1.2202-4 |
stable | source, alpha,arm, i386, m68k, powerpc, sparclibdbd-mysql-perl |
1.221
testing | alphalibdbd-mysql-perl |
1.2219-1 |
unstable | source, alpha,arm
In questo esempio, puoi vedere che la versione in unstable è diversada quella in testing e che
c’è stato un NMU solo binario del pacchettoper l’architettura alpha. Ogni volta il pacchetto è
stato ricompilato sullamaggior parte delle architetture.
4.10
Il sistema di tracciamento dei pacchetti
Il sistema di tracciamento dei pacchetti (PTS) è uno strumentobasato su e-mail atto a tenere
traccia dell’attività di un pacchettosorgente. Questo significa in realtà che puoi ricevere le
stesseemail che riceve il mantainer, semplicemente sottoscrivendoti alpacchetto nel PTS.
Ogni email inviata attraverso il PTS viene classificata con unadelle parole chiave sotto elencate.
Questo ti permetterà di selezionarele email che vuoi ricevere.
Di default riceverai:
bts Tutti i bug report e le conseguenti discussioni.
bts-control Le notifiche email da <[email protected]>circa i cambiamenti di
stato dei bug report.
upload-source Le notifiche email da katie quando un upload vieneaccettato.
27
katie-other Altre email di avvertimento ed errore da katie (comeuna disparità di
override per il campo sezione e/o priorità).
default Qualunque email non automatica inviata al PTS da persone che volevanocontattare i sottoscritti al pacchetto. Questo può essere fatto inviandouna mail a
[email protected]. Per prevenire lospam, tutti i messaggi
inviati a quegli indirizzi devono contenere l’headerX-PTS-Approved con un valore non
vuoto.
summary (Questa è un’espansione pianificata.)Le email regolari di riepilogo circa lo stato del
pacchetto (statistichesui bug, una vista d’insieme sul porting, il progresso in testing, . . . ).
Puoi anche decidere di ricevere delle informazioni addizionali:
upload-binary La notifica email da katie quando viene accettato un uploaddi un pacchetto binario. In altre parole, ogni volta che un demone di buildo un porter effettua un
upload del tuo pacchetto per un’altra architettura,puoi ricevere una email per tracciare
come il tuo pacchetto venga ricompilatoper tutte le architetture.
cvs Notifiche di commit CVS, se il pacchetto ha un archivio CVS e il mantainerha impostato
l’inoltro delle notifiche di commit al PTS.
ddtp Traduzioni di descrizioni o di template di debconf inviate alprogetto di traduzione delle
descrizioni Debian.
4.10.1
L’interfaccia email del PTS
Puoi controllare le tue sottoscrizioni al PTS mandando varicomandi a <[email protected].
org>.
subscribe <sourcepackage> [<email>] Sottoscrive email alle comunicazioni relative
al pacchetto sorgente sourcepackage. Se il secondo argomento non è presente viene usato
l’indirizzo del mittente. Se sourcepackage non è un valido pacchetto sorgente, riceverai
un avvertimento. Comunque se è un pacchetto binario valido, il PTS ti sottoscriverà al
pacchetto sorgente corrispondente.
unsubscribe <sourcepackage> [<email>] Rimuove una precedente sottoscrizione al
pacchetto sorgente sourcepackage usando l’indirizzo email specificato oppure l’indirizzo
del mittente se il secondo argomento non è specificato.
which [<email>] Lista tutte le sottoscrizioni per il mittente o l’indirizzo email
opzionalmente specificato.
keyword [<email>] Ti dice le parole chiave che stai accettando. Per una spiegazione sulle
parole chiave, vedi sopra. Ecco un veloce riepilogo:
• bts: mail provenienti dal sistema di tracciamento dei bug Debian
28
• bts-control: risposte alle mail inviate a <[email protected]>
• summary: mail automatiche di repilogo sullo stato di un pacchetto
• cvs: notifiche di commit CVS
• ddtp: traduzioni di descrizioni e template di debconf
• upload-source: annuncio dell’avvenuta accettazione di un nuovo upload di
sorgenti
• upload-binary: annuncio di un nuovo upload solo binario (porting)
• katie-other: altre mail dagli ftpmaster (disparità di override, ecc.)
• default: tutte le altre mail (quelle che non sono “automatiche”)
keyword <sourcepackage> [<email>] Come il precededente ma per il dato pacchetto sorgente, siccome puoi selezionare un set di keyword differenti per ogni pacchetto
sorgente.
keyword [<email>] {+|-|=} <lista di keyword> Accetta (+) o rifiuta (-) le mail
classificate sotto le date parole chiave. Definisce la lista (=) delle parole chiave accettate.
keyword <sourcepackage> [<email>] {+|-|=} <lista di keyword> Come
il
precedente ma sovrascrive la lista delle parole chiave per il pacchetto sorgente indicato.
quit | thanks | -- Ferma l’analisi dei comandi. Tutte le linee successive sono ignorate
dal bot.
4.10.2
Filtrare le mail del PTS
Una volta che sei sottoscritto a un pacchetto, riceverai le mail speditaa
[email protected]. Queste mailhanno appesi degli header
speciali per lasciartele filtrare in una mailboxspeciale (p.es. con procmail). Gli header
aggiunti sonoX-Loop, X-PTS-Package, X-PTS-Keyword eX-Unsubscribe.
Ecco un esempio di header aggiunti per una notifica di upload disorgenti del pacchetto dpkg:
X-Loop: [email protected]: dpkgX-PTS-Keyword: upload-so
4.10.3
Inoltrare i commit CVS nel PTS
Se usi un archivio CVS pubblicamente accessibile per mantenere iltuo pacchetto Debian puoi
volere inoltrare le notifiche di commit alPTS 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 notifichedi commit, devi semplicemente assicurarti che mandi una copia di questeemail a
[email protected].
Solo le personeche accettano la
keyword cvs riceveranno queste notifiche.
4.10.4
29
L’interfaccia web del PTS
Il PTS ha un’interfaccia web all’indirizzo http://packages.qa.debian.org/che mette
insieme un grande numero di informazioni su ogni pacchettosorgente. 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 vocidi changelog, stato
di testing, . . . ). È uno strumento molto utilese vuoi conoscere cosa sta succedendo su uno
specifico pacchetto sorgente.Oltretutto c’è una form che permette di sottoscriversi facilmente
al PTSvia email.
Puoi saltare direttamente alla pagina web di uno specifico pacchetto sorgentecon un URL tipo
http://packages.qa.debian.org/sourcepackage.
Questa interfaccia web è stata designata come un portale per lo sviluppo dipacchetti: puoi
aggiungere contenuti personalizzati sulle pagine dei tuoipacchetti. Puoi aggiungere “informazioni statiche” (notizie che devonoessere disponibili per un tempo indefinito) e notizie nella
sezione“latest news” (ultime notizie).
Notizie statiche possono essere usate per indicare:
• la disponibilità di un progetto ospitato su Aliothper co-mantenere il pacchetto
• un link per il sito web upstream
• un link al bug tracker upstream
• l’esistenza di un canale IRC dedicato al software
• qualunque altra risorsa disponibile che può essere utile per la manutenzionedel
pacchetto
Notizie classiche possono essere usate per annunciare che:
• pacchetti beta sono disponibili per il testing
• si aspettano pacchetti finali per la prossima settimana
• la pacchettizazione sta per essere rifatta da zero
• sono disponibili dei backport
• il mantainer è “in vacanza” (se vogliono pubblicare questa informazione)
• si sta lavorando per un NMU
• qualcosa di importante sta per essere fatto al pacchetto
Entrambi i tipi di news sono generati in maniera simile: devi solo mandareuna email a
<[email protected]> oppure a<[email protected]>. La mail
30
dovrebbe indicare a quale pacchettoconcerne mettendo il nome del pacchetto sorgente nell’header X-PTS-Packagedella email o in un pseudo-header Package (come nei report del
BTS). Seun URL è disponibile nell’header X-PTS-Url della email o nel pseudo-headerUrl,
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 nellasezione “informazioni statiche”:
From: Raphael Hertzog <[email protected]>To: [email protected]
debian-cd CVS repository with cvswebPackage: debian-cdUrl: http://cvs.debian.org/
Il secondo è un annuncio spedito a una mailing list che è anche mandato alPTS in modo che
venga pubblicato sulla pagina web PTS del pacchetto. Notal’uso del campo BCC per evitare
risposte inviate per errore al PTS.
From: Raphael Hertzog <[email protected]>To: [email protected]
2.0 backported for woodyX-PTS-Package: galeonHello gnomers!I’m glad to announce t
You’ll findeverything here:...
Pensaci due volte prima di aggiungere una news al PTS perchè dopo non saraipiù in grado di
rimuoverla e nemmeno di modificarla. L’unica cosa che puoifare è mandare un’altra news che
renderà obsolete le informazioni contenutenella precedente.
4.11
Vista d’insieme dei pacchetti degli sviluppatori
Un portale web di QA (assicurazione qualità) è disponibile all’indirizzohttp://qa.debian.
org/developer.php che mostra una tabella che elenca tutti i pacchettidi un singolo sviluppatore (includendo quelli in cui è elencato comeco-maintainer). La tabella ti da un buon riepilogo sui pacchetti dellosviluppatore: numero di bug per severità, lista delle versioni disponibiliin
ogni distribuzione, stato di testing e molto altro inclusi i link aqualunque altra informazione
utile.
È una buona idea quella di controllare regolarmente i tuoistessi dati in modo da non dimenticarti di nessun bug aperto e inmodo di non dimenticarti quali pacchetti sono sotto la tua
responsabilità.
4.12
Debian *Forge: Alioth
Alioth è un servizio Debian abbastanza nuovo, basato su una versione leggermentemodificata del software GForge (un evoluzione di SourceForge). Questosoftware offre agli sviluppatori accesso a strumenti facili da usare comebug tracker, patch manager, project/task manager, servizi di hosting di file,mailing list, archivi CVS ecc. Tutti questi strumenti sono gestiti
tramiteinterfaccia web.
31
È inteso a fornire infrastrutture a progetti di software liberospalleggiati o diretti da Debian, facilitare le contribuzioni da sviluppatoriesterni ai progetti iniziati da Debian e aiutare i progetti
i cui obiettivisono la promozione di Debian o dei suoi derivati.
Per informazioni aggiuntive visita http://alioth.debian.org/.
32
33
Capitolo 5
Gestire i pacchetti
Questi capitolo contiene informazioni relativa alla creazione, upload,gestione e “porting” di
pacchetti.
5.1
Nuovi pacchetti
Se vuoi creare un nuovo pacchetto per la distribuzione Debian, dovrestiprima consultare
la lista dei Pacchetti aventibisogno di lavoro e futuri (http://www.debian.org/devel/
wnpp/) (WNPP). Controllando tale lista puoiassicurarti che nessuno stia ancora lavorando per
fare un pacchetto diquel software, e che non si duplichino gli sforzi. Leggi le pagine web
WNPP (http://www.debian.org/devel/wnpp/) per ulteriori informazioni.
Assumendo che nessun’altro stia già lavorando sul tuo futuro pacchetto,devi segnalare un bug
(‘Riportare bug’ a pagina 73) verso il pseudo-pacchettownpp descivendo la tua intenzione di
creare un nuovopacchetto 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: foo– short description”, sostituendo il nome del nuovopaccheto a foo. La severità del bug dovrebbe essere impostataa wishlist. Se pensi che sia necessario, mandane una copia a<[email protected]> impostando l’indirizzo nell’intestazioneX-Debbugs-CC: del messaggio (no, non usare CC:,perchè in quel modo
l’oggetto del messaggio non riporterà il numerodel bug).
Per favore includi un campo Closes: bug#nnnnnnel changelog nuovo pacchetto in modo
daautomaticamente chiudere il bug quando il nuovo pacchetto entrerànell’archivio. (‘Quando
i bug vengono chiusi da nuovi upload.’ a pagina 44).
Ci sono diverse ragioni per le quali chiediamo ai mantainersdi annunciare le loro inenzioni:
• Aiuta i (potenziali nuovi) mantainer di sfruttarel’esperienza delle persone della lista, e fa
loro sapere se qualcun’altroci sta già lavorando sopra.
• Fa sapere ad altre persone che stanno pensando di lavorare sul pacchettoche esiste già
un volontario, quindi gli sforzi possono essere ripartiti.
Capitolo 5. Gestire i pacchetti
34
• Fa sapere agli altri mantainer di più sul pacchetto alla descrizionedi una sola linea e la
frase “Initial release” del changelog che vienespedita a debian-devel-changes.
• È di aiuto per le persone che usano unstable (e formano la nostra prima linea di
tester).Dovremmo incoraggiare queste persone.
• Gli annunci fanno sapere ai mantainter e alle altre parti interessatecosa sta succedendo e
cosa c’è di nuovo all’interno del progetto.
5.2
Registrare i cambiamenti dei pacchetti
Le modifiche che apporti al pacchetto devono essere registrate neldebian/changelog.
Le registrazioni devono contenere unadescrizione concisa di cosa è cambiato, perchè
(se non è chiaro) especificare se dei bug sono stati chiusi. Registrano anche quando ilpacchetto è stato completato.
Questo file verrà installato in/usr/share/doc
/package/changelog.Debian.gz, o/usr/share/doc/package/changelog.gz per i
pacchettinativi.
Il file debian/changelog è conforme a una certa struttura,con diversi campi. Un campo
degno di nota, distribution,è descritto in ‘Scegliere la distribuzione’ a pagina 36. Ulteriori informazioni sullastruttura di questo file possono essere trovate nella sezione dellaPolicy Debian
intitolata “debian/changelog”.
Le voci nel changelog possono essere usate per chiudere automaticamentedei bug Debian
quando il pacchetto verrà installato nell’archivio.Leggi ‘Quando i bug vengono chiusi da nuovi
upload.’ a pagina 44.
È una cosa convenzionale che la voce del changelog di un pacchettoche contiene una nuova
versione del software sia:
* new upstream version
Esistono degli strumenti che ti permettono di creare vocie completare il changelog per il
rilascio— leggi ‘devscripts’ a pagina 84 e ‘dpkg-dev-el’ a pagina 85.
Leggi anche ‘Procedimenti consigliati per debian/changelog’ a pagina 65.
5.3
Controllare il pacchetto
Prima di effettuare l’upload di un pacchetto, dovresti effettuare deicontrolli di base su di esso. Dovresti almeno provare a svolgere leseguenti attività di base (avrai bisogno di avere da
qualche parteuna vecchia versione dello stesso pacchetto):
• Installa il pacchetto e assicurati che il software funziona, oaggiorna il pacchetto da una
vecchia versione alla tua nuova seun pacchetto Debian per esso esiste già.
35
• Lancia lintian sul pacchetto. Puoi lanciare lintian come segue: lintian
-vpackage-version.changes. In questo modo saranno controllati sia il pacchetto
sorgente cheil pacchetto binario. Se non capisci l’output generato da lintian prova ad
aggiungere lo switch -i,che porterà lintian a riportare una descrizione moltoprolissa
del problema.
Normalmente, non si dovrebbe effettuare l’upload di un pacchettose lintian segnala degli
errori (cominceranno con E).
Per ulteriori informazioni su lintian, leggi ‘lintian’ a pagina 80.
• Opzionalmente lancia ‘debdiff’ a pagina 81 per analizzare i cambiamenti dallaversione
precedente, se ne esiste una.
• Effettua un downgrade del pacchetto alla versione precedente (se esiste)— questo mette
alla prova gli script postrm eprerm.
• Rimuovi il pacchetto, poi reinstallalo.
5.4
Layout del pacchetto sorgente
Esistono due tipi di pacchetti Debian sorgenti:
• i cosiddetti pacchetti nativi, nei quali non c’è distinzione tra i sorgenti originali e le patch
applicate per Debian
• i (più comuni) pacchetti dove esistono i sorgenti originali accompagnati da un altro file
che contiene le patch applicate per Debian.
Per i pacchetti nativi, il pacchetto sorgente include un file Debian di controllo dei sorgenti
(.dsc) e il file con i sorgenti (.tar.gz).Il pacchetto sorgente di un pacchetto non-nativo include il file Debian dicontrollo dei sorgenti, il file con i sorgenti originali (.orig.tar.gz)e le
patch Debian (.diff.gz).
Se un pacchetto è nativo oppure no viene determinato quando vienecostruito da
dpkg-buildpackage(1). Il resto di questasezione si riferisce solo ai pacchetti non-nativi.
La prima volta che viene effettuato l’upload di una nuova versionecorrispondente a una nuova
versione upstream, dovrebbe essere effettuatol’upload anche del file tar dei sorgenti originali includendolo nel file.changes. Conseguentemente, quello stesso file tardovrebbe essere
usato per costruire le nuove “diff” e i nuovi file.dsc, senza bisogno di ripeterne l’upload.
Per default, dpkg-genchanges edpkg-buildpackage includeranno i sorgenti originalise
e solo se la parte realativa alla revisione Debian del numero diversione del sorgente è 0 o 1,
indicante una nuova versione upstream.Questo comportamento può essere modificato usando
-sa perincluderlo sempre o -sd per lasciarlo sempre da parte.
Se nessun sorgente originale viene incluso nell’upload, il file tardei sorgenti originali usato
da dpkg-source percostruire il file .dsc le diff per farne l’uploaddeve essere byte-per-byte
identico a quello già presente inarchivio.
5.5
36
Scegliere la distribuzione
Ogni upload deve specificare in quale distribuzione deveessere incluso il pacchetto. Il processo di costruzione del pacchettoestrae questa informazione dalla prima linea del filedebian
/changelog e la pone nel campo Distributiondel file .changes.
Ci sono diversi valori possibili per questo campo: ‘stable’, ‘unstable’,‘testing-proposedupdates’ e ‘experimental’. Normalmente, al momentodell’upload i pacchetti sono destinati
a unstable.
Attualmente, ci sono altre due distribuzioni possibili: ‘stable-security’e ‘testing-security’, ma
per queste leggi ‘Gestire i bug di sicurezza’ a pagina 44 per ulterioriinformazioni.
Tecnicamente è possibile effettuare l’upload di un pacchetto in piùdistribuzioni allo stesso tempo ma di solito non ha alcun senso farloperchè le dipendenze del pacchetto possono cambiare a seconda delladistribuzione. In particolare, non ha mai senso combinare la
distribuzioneexperimental con qualunque altra. (vedi ‘Experimental’ a pagina 22).
5.5.1
Caso speciale: upload alla distribuzione stable
Effetuare un upload alla distribuzione stable implica che ilpacchetto verrà posto nella directory
stable-proposed-updatesdell’archivio Debian per essere ulteriormente testata prima che
sia realmenteincluso in stable.
Bisognerebbe apporre maggiore attenzione quando si effettua un upload perstable. Di base, un
pacchetto dovrebbe essere mandato in uploadin stable solo se si verifica uno dei seguenti casi:
• un problema nella funzionalità realmente critico
• il pacchetto diventa ininstallabile
• manca il pacchetto in una certa architettura
Nel passato, si usava fare upload verso stable anche perproblemi relativi alla sicurezza. Comunque, questa pratica è sconsigliatain quanto gli upload usati per gli advisory di sicurezza Debian
sonoautomaticamente copiati nell’archivio proposed-updatesappropriato quando l’advisory viene rilasciata. Vedi ‘Gestire i bug di sicurezza’ a pagina 44per 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 seguitocausare dei bug.
Pacchetti mandati in upload su stable devono essere compilati insistemi che girano su stable,
in modo che le loro dipendenze sianolimitate alle librerie (e altri pacchetti) disponibili in stable;per esempio, un pacchetto di cui si sia effettuato l’upload in stableche dipende da una libreria esistente solo in unstable sarà rifiutato.Effettuare cambiamenti alle dipendenze di altri
pacchetti (giocando conProvides o file shlibs), rendendo questi altri pacchettipossibilmente
ininstallabili, è fortemente sconsigliato.
37
Il “Release Team” (che può essere contattato tramite <[email protected].
org>)valuterà regolarmente gli upload in stable-proposed-updates edeciderà se il tuo pacchetto
può essere incluso in stable.Per favore sii chiaro (e prolisso se necessario) nelle voci nel tuochangelog per gli upload in stable, in quanto altrimenti ilpacchetto non sarà considerato per
l’inclusione.
5.5.2
Caso speciale: upload a testing-proposed-updates
La distribuzione testing è composta dai pacchetti da unstable in accordo alle regolespiegate in
‘Ulteriori informazioni sulla distribuzione testing’ a pagina 21. In ogni caso, il release manager
può fermare gliscript di testing quando ha intenzione di fare un “freeze” della distribuzione.In
quel caso, puoi volere effettuare upload a testing-proposed-updatesper fornire fix di pacchetti
durante il freeze.
Tieni a mente che quegli upload non sono processati automaticamente, devonopassare per le
mani del release manager. Dovresti quindi avere una buonaragione per effettuare upload lì.
Per sapere quale sia una buona ragione negliocchi del release manager, dovresti leggere le
istruzioni cheregolarmente da su <[email protected]>.
Non dovresti effettuare upload su testing-proposed-updates quando puoiaggiornare i toi pacchetti attraverso unstable. Se non puoi (per esempioperchè hai una nuova versione in sviluppo in
unstable), puoi usarlo ma è raccomandatochiedere prima l’autorizzazione al release manager.
5.6
5.6.1
Effetuare un upload
Inviare un upload a ftp-master
Per inviare un pacchetto in upload, hai bisogno di un account personalesu ftp-master.
debian.org, cosa che dovresti avere essendoun mantainer ufficiale. Se usi scp o rsyncper
trasferire i file, posizionali in /org/ftp.debian.org/incoming/; se usi FTPanonimo,
posizionali in /pub/UploadQueue/.
Se vuoi usare la funzione descritta in ‘Incoming ritardato’ a pagina 25,dovrai mandare l’upload
a ftp-master. È l’unico punto diupload 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 dimanutenzione dell’archivio scorrerà il file changes e vedrà
che nontutti i file sono stati inviati in upload. Se non hai voglia di trasferireil file changes per
ultimo, puoi semplicimente copiare i tuoi file in unadirectory temporanea in ftp-master e
quindi spostarli in/org/ftp.debian.org/incoming/.
Nota: Non inviare a ftp-master upload di pacchetticrittografici che appartengono a contrib
o non-free.Upload di tali software dovrebbero andare a non-us (vedi ‘Inviare un upload a
non-US’ nella pagina seguente). Inoltre pachetti contenenti codice brevettatoda il governo degli Stati Uniti non possono essere inviati in upload a ftp-master; dipendentemente dal caso
38
potrebbero essere comunqueinviati a non-US/non-free (è in non-free per caratteristichedella distribuzione e non a causa della licenza del software). Se non puoiinviarlo in upload a
ftp-master, non puoi neanche farlo alle codedi upload oltreoceano su chiark o erlangen.
Se non seisicuro se i controlli sulle licenze o sualla crittografia degli StatiUniti si applicano al
tuo pacchetto, manda un messaggio a <[email protected]>e chiedi.
Puoi anche trovare utili per l’upload dei pacchetti i pacchetti Debian‘dupload’ a pagina 83
o ‘dput’ a pagina 83. Questi maneggevoli programmiaiutano ad automatizzare il processo
dell’upload di pacchetti in Debian.
Dopo l’upload del tuo pacchetto, puoi controllare come il software dimanutenzione
dell’archivio lo processerà facendo giraredinstall sul tuo file changes:
dinstall -n foo.changes
Nota che dput può automaticamente fare questo per te.
5.6.2
Inviare un upload a non-US
Come sopra discusso, sofware a esportazione controllata non dovrebberoessere inviati a
ftp-master. Al suo posto, spedisci il pacchettoa non-us.debian.org,ponendo i file in
/org/non-us.debian.org/incoming/ (di nuovo, sia ‘dupload’ a pagina 83 che ‘dput’ a
pagina 83possono fare questo per te se propriamente invocati).Di default, puoi usare gli stessi
account/password che usi suftp-master. Se per gli upload usi FTP anonimo, poni i filein
/pub/UploadQueue/.
Puoi controllare i tuoi upload allo stesso modo di come fai suftp-master, con:
dinstall -n foo.changes
Nota che i cittadini o i residenti negli Stati Uniti sono soggettia restrizioni sull’esportazione di
software crittografico. Al tempodella scrittura di questo documento, i cittadini degli Stati Unitisono autorizzati a esportare qualche software crittografico, soggettoa regole di notificazione
dal Dipartimento sul Commercio degli StatiUniti. Comunque, questa restrizione è stata posta
in deroga per isoftware già disponibile al di fuori degli Stati Uniti. Di conseguenza,qualsiasi
software crittografico che appartiene alla sezione maindell’archivio Debian e che non dipende
da nessun pacchetto esterno amain (e.g., non dipende da niente in non-US/main)puo’ essere
inviato a ftp-master o alle sue code, sopradescritte.
La policy Debian non previene upload su non-US da cittadini o residentidegli Stati Uniti, ma
queste persone dovrebbero fare attenzione nel farlo.È raccomandato che gli sviluppatori intraprendano tutti i passinecessari per assicurarsi che non violino le correnti leggi degliStati Uniti
effettuando un upload su non-US, compreso consultarsicon un avvocato.
Per i pacchetti in non-US/main, non-US/contrib,gli sviluppatori dovrebbero almeno seguire leprocedure specificate dal Governodegli Stati Uniti (http://www.bxa.doc.gov/
39
Encryption/PubAvailEncSourceCodeNofify.html). I mantainer di pacchetti in nonUS/non-freedovrebbero in aggiunta consultare le regole per la notificazione dulle esportazioni
(http://www.bxa.doc.gov/Encryption/) sul software non libero.
Questa sezione è esclusivamente a titolo informativo e noncostituisce dei consigli legali. Di
nuovo, è fortemente raccomandato chei cittadini e residenti degli Stati Uniti consultino un
avvocatoprima di effettuare upload a non-US.
5.6.3
Upload via chiark
Se hai una connessione di rete lenta verso ftp-master, esistonodelle alternative. Una è quella
di inviare file in upload a Incomingattraverso una coda di upload in Europa su chiark.
Per dettaglicollegati a ftp://ftp.chiark.greenend.org.uk/pub/debian/private/
project/README.how-to-upload.
Nota: Non inviare in upload pacchetti contenenti software che èa esportazione controllata dal governo degli Stati Uniti sulla coda inchiark. Siccome questa coda di upload va
in ftp-master,le prescrizioni trovate in ‘Inviare un upload a ftp-master’ a pagina 37 si
applicano anchequa.
Il programma dupload supporta gli upload a chiark;per favore fai riferimento alla
documentazione fornita con il programmaper i dettagli.
5.6.4
Upload via erlangen
Un altra coda di upload è disponibile in Germania: semplicemente inviai file in upload via FTP
anonimo a ftp://ftp.uni-erlangen.de/pub/Linux/debian/UploadQueue/.
L’upload deve essere un upload completo Debian, come lo invieresti aIncoming di
ftp-master, ovvero dei file .changesinsieme agli altri file menzionati nei .changes stessi. Ildemone della coda controlla anche che il .changes siacorrettamente firmato con GnuPG
o OpenPGP da uno sviluppatore Debian,in modo che nessun file fasullo possa intrufolarsi in
ftp-masterattraverso questa coda. PEr favore assicurati anche che il campoMaintainer nel
.changes contiene il tuo indirizzoe-mail. L’indirizzo lì trovato è usato per tutte le risposte,
propriocome in ftp-master.
Non c’è alcn bisogno di muovere i tuoi file in una directory secondariadopo l’upload, come su
chiark. E, in ogni caso, dovrestiricevere una mail di risposta dal demone della coda spiegando cosaè successo al tuo pacchetto. È sperabile che sia stato spostato inftp-master, 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 inerlangen. Siccome questa coda di upload va
in ftp-master,le prescrizioni trovate in ‘Inviare un upload a ftp-master’ a pagina 37 si
applicano anchequa.
Il programma dupload supporta gli upload a erlangen;per favore fai riferimento alla
documentazione fornita con il programmaper i dettagli.
5.6.5
40
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 ftp-master.Puoi inviare file in upload, esattamente come in
erlangen, a ftp://samosa.debian.org/pub/UploadQueue/.
Una coda di upload è disponibile in Giappone: semplicemente invia ifile in upload via FTP
anonimo a ftp://master.debian.or.jp/pub/Incoming/upload/.
5.6.6
Notificazione che un nuovo pacchetto è stato installato
I mantainer dell’archivio Debian sono responsabili per la gestione degliupload dei pacchetti.
Per la maggior parte, gli upload sono giornalmentegestiti automaticamente dagli strumenti di
manutenzione dell’archivio,katie. Specificatamente, gli aggiornamenti di pacchettiesistenti
nella distribuzione ‘unstable’ sono gestiti automaticamente.In altri casi, specialmente nei nuovi
pacchetti, il posizionamentodel pacchetto in upload nella distribuzione è gestito manualmente.Quando gli upload sono gestiti manualmente, il cambiamento all’archiviopuò 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 sarannochiusi 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 sezioneil pacchetto è stato inserito.
Se esiste disparità, riceverai unaemail separata per avvisarti di ciò. Continua a leggere sotto.
Nota anche che se effettui upload attraverso le code, anche il softwaredemone di coda ti
manderà una notifica via email.
5.7
Specificare sezione, sottosezione e priorità del pacchetto
I campi Section e Priority del filedebian/control non specifica in realtà in che luogo il
fileverrà piazzato nell archivio, e nemmeno la sua priorità. Per conservarel’integrità complessiva dell’archivio, sono i mantainer dell’archivioche hanno il controllo su quei campi. I valori
nel filedebian/control sono in realtà solo suggerimenti.
I mantainer dell’archivio tengono traccia delle sezioni e prioritàcanoniche per i pacchetti nel
file override. Se esiste unadisparità tra il file override e i campi indicati nel filedebian/control,
allora riceverai una email notificantela divergenza quando il pacchetto sarà installati nell’archivio.Puoi o correggere il tuo file debian/control per iltuo prossimo upload, oppure puoi
desiderare di apportare unamodifica nel file override.
Per alterare la sezione reale in cui viene posto un pacchetto, deviprima assicurarti che
il debian/control nel tuopacchetto sia accurato. Dopodichè, manda una email a
41
<[email protected]>oppure segnala un bug di ftp.debian.org richiedendoche la sezione o la priorità del tuo pacchetto venga modificata dallavecchia alla nuova.
Assicurati di spiegare le tue ragioni.
Per ulteriori informazioni circa i file override, vedidpkg-scanpackages(8) e http://www.
debian.org/Bugs/Developer#maintincorrect.
Nota che il campo Section specifica sia la sezione che lasottosezione, descritte in ‘Sezioni’ a
pagina 19. Se la sezioneè “main”, dovrebbe essere omessa. La lista delle sottosezioni permessepuò essere trovata in http://www.debian.org/doc/debian-policy/ch-archive.
html#s-subsections.
5.8
Gestire i bug
Ogni sviluppatore deve essere in grado di lavorare con il sistemadi tracciamento dei bug
(http://www.debian.org/Bugs/) Debian. Questo include sapere comearchiviare propriamente i bug report (vedi‘Riportare bug’ a pagina 73), come aggiornarli e registrarli, e come
processarli echiuderli.
Le caratteristiche del sistema di tracciamento deibug interessanti per gli sviluppatori sono descritte nella documentazione per gli sviluppatori sul BTS (http://www.debian.org/Bugs/
Developer).Questo include chiudere bug, inviare messaggi di followup, assegnareseverità 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 quandosono stati chiusi premeturamente, sono gestite usando il
cosiddettomail server di controllo. Tutti i comandi disponibili in questo server sono descritti nelladocumentazione del server di controllo del BTS (http://www.debian.org/Bugs/
server-control).
5.8.1
Monitorare i bug
Se vuoi essere un buon mantainer, dovresti cotrollare periodicamenteil sistema di tracciamento dei bug Debian (BTS) (http://www.debian.org/Bugs/)per i tuoi pacchetti. Il
BTS contiene tutti i bug aperti contro ituoi pacchetti. Puoi controllarli visitando questa
pagina:http://bugs.debian.org/[email protected].
I mantainer interagiscono con il BTS attraverso l’indirizzo emailbugs.debian.org. La
documentazione sui comandi disponibili puòessere trovata su http://www.debian.org/
Bugs/, oppure, se hai installato ilpacchetto doc-debian, puoi dare un’occhiata ai filein locale
/usr/share/doc/debian/bug-*.
Qualcuno trova utile ricevere dei resoconti periodici sui bug aperti.Puoi aggiungere un cron
job come i seguentise vuoi ricevere settimanalmente una email sottolineante tutti i bug aperti
contro i tuoi pacchetti.
# chiedi un resoconto settimanale sui bug nei miei pacchetti0 17 * * fri
ech
42
Sostituisci address con il tuo indirizzo come mantainer ufficialeDebian.
5.8.2
Rispondere ai bug
Quando rispondi ai bug, assicurati che qualunque discussione tu intraprendacirca i bug sia
inviata sia a chi ha originalmente inviato il bug che albug stesso (p.es., <[email protected].
org>). Se stai scrivendo una nuovaemail e non ricordi l’indirizzo email di chi ha inviato il bug,
puoi usarel’indirizzo <[email protected]> per contattarlo ememorizzare
la tua email nel log del bug (ciò significa che non hai bisogno diinviare una copia della mail a
<[email protected]>).
Se ricevi un bug recante la dicitura “FTBFS”, ciò significa “Fails to buildfrom source” - fallisce
durante il build dai sorgenti .I porter usano spesso questo acronimo.
Una volta che hai finito con un bug (p.es. lohai risolto), marcalo con done (chiudilo) mandando
un messaggioesplicativo a <[email protected]>. Se stai risolvendo unbug cambiando il pacchetto ed effettuandone un upload, puoi automatizzarela chiusura del bug come
descritto in ‘Quando i bug vengono chiusi da nuovi upload.’ a pagina 44.
Non dovresti mai chiudere bug attraverso il comando delbug server close inviato a
<[email protected]>. Se fai così,il segnalatore originario non riceverà alcuna
informazione sul perchèdetto bug è stato chiuso.
5.8.3
Bug housekeeping
Come mantainer, toverai spesso bug in altri pacchetti o ti verrannosegnalati bug in tuoi pacchetti che sono in realtà bug di altri pacchetti.Le feature del sistema di tracciamento dei buginteressanti per gli sviluppatori sono descritte nellaDocumentazione sul BTS per gli sviluppatoriDebian (http://www.debian.org/Bugs/Developer). Operazioni come reassegnare, fondere e marcare le segnalazionidi bug sono descritte nella documentazionedel server
di controllo del BTS (http://www.debian.org/Bugs/server-control). Questa sezione contiene alcune linee guidaper la gestione dei tuoi bug, basate sull’esperienza collettiva
deglisviluppatori Debian.
Segnalare bug per problemi che incontri in altri pacchetti fa partedegli “obblighi civili” nell’essere un mantainer,vedi ‘Riportare bug’ a pagina 73 per i dettagli. In ogni caso, gestire i bugnei
tuoi stessi pacchetti è ancora più importante.
Di seguito è riportata una lista di passi che puoi seguire pergestire una segnalazione di bug.
1 Stabilire se la segnalazione corrisponda o meno realmente a un bug.A volte gli utenti
stanno solo invocando un programma nel modo sbagliatoperchè non hanno letto la documentazione. Se pensi che sia successo inrealtà questo, chiudi semplicemente il bug indicando abbastanza informazioniper permettere all’utente di risolvere il problema (indica la giustadocumentazione e cose così). Se giungono in continuazione segnalazionisullo
stesso problema potresti chiederti se la documentazione siaadeguata o se il programma
43
non dovrebbe accorgersi del problema emandare in output un messaggio di errore più
informativo. Questo potrebbe essere un problema da sottoporre all’autore delsoftware.
Se il segnalatore originale del bug non è d’accordo con la tua decisionedi chiudere il
bug, possono riaprirlo finchè non trovate un accordosu come gestirlo. Se non riesci a
trovarlo, puoi volere marcare ilbug wontfix per fare sapere alla gente che il bug esiste
mache non sarà corretto. Se questa situazione è inaccettabile, tu (o ilsegnalatore) puoi
richiedere una “sentenza” della commissione tecnicariassegnando il bug a tech-ctte
(puoi usare ilcomando “clone” del BTS se desideri di tenerlo segnalato sul tuopacchetto).
Prima di farlo, per piacere leggi le procedure raccomandate (http://www.debian.
org/devel/tech-ctte).
2 Se il bug è reale ma è causato da un altro pacchetto, riassegnalosemplicemente al pacchetto giusto. Se non sai a quale pacchettodovrebbe essere riassegnato, puoi o chiedere
aiuto in<[email protected]> o riassegnarlo a debian-policyper
fare decidere a loro quale pacchetto sia bacato.
A volte puoi avere bisogno di aggiustare la severità del bug in modo checorrisponda
alla nostra definizione di severità. Questo perché la gentetende a gonfiare la severità dei
bug per assicurarsi che venganorisolti velocemente. Certi bug possono persino venire
degradatia ‘wishlist’ quando il cambiamento richiesto è solo cosmetico.
3 Il segnalatore del bug può avere dimenticato di fornire alcune informazioni,in tal caso
devi chiedergli le informazioni necessarie. Puoi usare il tagmoreinfo per marcare il bug
di conseguenza. Oltretutto, se non puoiriprodurre il bug, marcalo unreproducible.
Chiunque sia in grado diriprodurre il bug è quindi invitato a fornire ulteriori informazioni su comefare per riprodurlo. Dopo qualche mese, se nessuno ha mandato
informazioni,il bug può essere chiuso.
4 Se il bug è dovuto alla pacchettizzazione, risolvilo semplicemente. Se nonsei in
grado di risolverlo da solo, marca il bug con help.Puoi anche chiedere aiuto
su <[email protected]> oppure <[email protected].
org>.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 espedirla
allo stesso tempo all’autore. Assicurati di mandare la patchal BTS e marcare il bug con
patch.
5 Se hai risolto un bug in locale, o una patch è stata inviataall’archivio CVS, puoi marcare il bug come pending per farsapere alla gente che il bug è stato corretto e che
verrà chiuso conil prossimo upload (aggiungendo closes: nel changelog).Questo è
particolarmente utile se ci sono più sviluppatori che lavoranosullo stesso pacchetto.
6 Una volta che un pacchetto corretto è disponibile nella distribuzioneunstable, puoi chiudere il bug. Ciò puoò essere fatto automaticamente,vedi ‘Quando i bug vengono chiusi
da nuovi upload.’ nella pagina successiva.
5.8.4
44
Quando i bug vengono chiusi da nuovi upload.
Intanto che bug e problemi nei tuoi pacchetti vengono risolti, è tuaresponsabilità come mantainer del pacchetto chiudere il bug. Comunque,non dovresti chiudere il bug finché il pacchetto
che lo corregge nonsia stato accettato nell’archivio Debian. Di conseguenza, una voltache ricevi la notifica che il tuo pacchetto aggiornato è statoinstallato nell’archivio, puoi e dovresti
chiudere il bug nel BTS.
È comunque possibile evitare di dover chiudere manualmente i bug dopogli upload — elenca
semplicemente i bug risolti nel tuo filedebian/changelog, rispettando una certa sintassi, e
ilsoftware di manutenzione dell’archivio chiuderà il bug per te. Per esempio:
acme-cannon (3.1415) unstable; urgency=low
* Riempito di opzioni (closes: Bug
In termini tecnici, la seguente espressione regolare Perl descrive comesono identificati i
changelog che chiudono bug:
/closes:\s*(?:bug)?\#\s*\d+(?:,\s*(?:bug)?\#\s*\d+)*/ig
Noi preferiamo la sintassi closes:
con il testo delchangelog.
#XXX, essendola più concisa e la più facile da integrare
Se ti succede di sbagliare a scrivere il numero di un bug o di dimenticareun bug nelle voci del
changelog, non esitare ad annullare ogni dannocausato dall’errore. Per riaprire bug chiusi per
errore, manda un comandoreopen XXX all’indirizzo del controllo del sistemadi tracciamento
dei bug, <[email protected]>. Per chiudere i rimanentibug risolti dal tuo upload,
manda il file .changes a<[email protected]>, dove XXX è il numero deltuo
bug.
Tieni a mente che non è obbligatorio chiudere i bug usando il changelogcome descritto sopra. Se vuoi chiudere bug che semplicemente non hannoniente a che fare con gli upload
che hai fatto, fallo mandando una emaildi spiegazione a <[email protected]>.
NONchiudere bug nella voce del changelog di una versione se i cambiamenti fattiin quella
versione non hanno niente a che fare con il bug.
Per informazioni generali su come scrivere le tue voci nel changelog, vedi‘Procedimenti
consigliati per debian/changelog’ a pagina 65.
5.8.5
Gestire i bug di sicurezza
Per la loro natura sensibile , i bug disicurezza devono essere gestiti con molta attenzione. Il
Team di sicurezzaDebian esiste per coordinare queta attività, tenendo traccia dei problemidi
sicurezza esistenti, aiutando i mantainer con problemi di sicurezzao risolvendoli direttamente,
mandando advisory di sicurezza emantenendo security.debian.org.
45
Quando vieni a conoscenza dell’esistenza di un bug di sicurezza inun pacchetto Debian, che
tu ne sia o meno il mantainer raccogliinformazioni pertinenti al problema, e contatta prontamente il teamdi sicurezza presso <[email protected]> il più presto possibile.Per
esempio, sono informazioni utili:
• Quali versioni del pacchetto sono riconosciute essere affette dal bug. Controlla ogni
versione presente in una release Debian supportata, così come testing e unstable.
• La natura del rimedio, se disponibile (le patch sono perticolarmente d’aiuto)
• Qualunque pacchetto “riparato” che hai personalmente preparato (manda solo i file
.diff.gz e .dsc e leggi prima ‘Preparare i pacchetti per indirizzare i problemi di
sicurezza’ nella pagina successiva)
• Qualunque assistenza sei in grado di fornire per aiutare il testing (exploit, regression
testing, ecc.)
• Qualunque informazione necessaria per l’advisory (vedi ‘Advisory di sicurezza’ nella
pagina seguente)
Riservatezza
Al contrario della maggior parte delle altre attività in Debian, a voltele informazioni sui problemi di sicurezza devono essere tenute privateper un certo tempo. Questo permette ai distributori di software dicoordinare il rilascio delle informazioni in modo da minimizzare l’esposizione dei loro utenti. Questa decisionedipende dalla natura del problema e del rimedio
corrispondente, e sesia già di pubblico dominio.
Ci sono diversi modi in cui uno sviluppatore può venire a conoscenzadi un problema di
sicurezza:
• lo nota su un forum pubblico (mailing list, sito web, ecc.)
• qualcuno manda un bug report
• qualcuno li informa tramite un’email privata
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:
• Se l’esposizione di sicurezza è minima, a volte non c’è bisogno di tenere segreto il
problema e un rimedio dovrebbe essere creato e rilasciato.
• 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.
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 mandareuna fix in upload suunstable (o da qualsiasi altra parte, come un archivio CVS pubblico).Non è sufficente offuscare i
46
dettagli delle modifiche, essendo ilcodice stesso pubblico, e può essere (e sarà) esaminato dal
pubblicoin generale.
Ci sono due ragioni per rilasciare informazioni anche se è richiestoun certo grado di sicurezza:
il problema era risaputo da un certo tempo,o il problema o l’exploit è diventato pubblico.
Advisory di sicurezza
Le advisory di sicurezza sono rilasciate solo per la corrente, rilasciatadistribuzione stabile,
e non per testing o unstable. Quando sonorilasciate, le advisory sono inviate alla mailing
list<[email protected]> e postate sulle pagine web di sicurezza (http://www.debian.org/security/).Le advisory di sicurezza vengono scritte
e postate dal team disicurezza. Nonostante ciò saranno certamente contenti se unmantainer
può fornire qualche informazione per loro, o scrivere partedel testo. Le informazioni che
dovrebbero comparire in un advisoryincludono:
• Una descrizione del problema e della sua portata, includendo:
– Il tipo del problema (privilege escalation, denial of service, etc.)
– Quali privilegi possono essere ottenuti, e da chi (seda qualcuno)
– Come può essere sfruttato
– Se sia sfruttabile in remoto o in locale
– Come il problema è stato risolto
Questa informazione permette agli utenti di stimare la minaccia ailoro sistemi.
• Numeri di versione dei pacchetti affetti
• Numeri di versione dei pacchetti sistemati
• Informazioni su dove ottenere i pacchetti aggiornati (di solito dall’archivio di sicurezza
Debian)
• Riferimenti alle advisory originali CVE (http://cve.mitre.org), identificatori, e
quant’altro. informazioni utili per stabilire referenze incrociate alla vulnerabilità
Preparare i pacchetti per indirizzare i problemi di sicurezza
Un modo per assistere il team di sicurezza nei loro compiti è difornirli di pacchetti sistemati
adatti per un advisory di sicurezza peril 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 essereapplicate alla versione presente nella release
Debian stabile corrente.Generalmente, i mantainer upstream sono disponibili ad aiutarti incaso
di bisogno. Altrimenti, il team di sicurezza Debian può esserein grado di aiutarti.
47
In qualche caso, non è possibile effettuare il back-port di un fix di sicurezza, per esempio quando unanotevole quantità di codice sorgente deve essere modificata o riscritta.Se questo è il caso, potrebbe essere necessario ripiegare su una nuovaversione 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: provasempre le tue modifiche. Se hai
un exploit disponibile, provaloe guarda se veramente ha successo sul pacchetto vecchio efallisce su quello sistemato. Prova anche altre, normali azioni,siccome a volte un fix di sicurezza può infrangerealtre feature che non hanno apparentemente alcuna relazione in modimolto
sottili.
NON includere alcuna modifica nel tuo pacchetto chenon sia direttamente correlata alla risoluzione della vulnerabilità.Queste avranno solo bisogno di essere ripristinate, causandoperdite
di tempo. Se ci sono altri bug nel tuo pacchetto che vorrestisistemare, effettua un upload in
proposed-updates nel solito modo,dopo il rilascio dell’advisory di sicurezza. Il meccanismo
degliaggiornamenti di sicurezza non è un modo per introdurre modifiche neltuo 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 differenzecon la versione precedente in continuazione (interdiff dalpacchetto patchutils e debdiff dadevscripts
sono strumenti utili per questo, vedi‘debdiff’ a pagina 81).
Assicurati di verificare le seguenti cose:
• Assegna al giusta distribuzione nel tuo debian/changelog.
Per stable è
stable-security e per testing è testing-security, e per la release stable
precedente è oldstable-security. Non indicare distribution-proposed-updates o
stable!
• 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.
• 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 dpkg --compare-versions. 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.
• Non effettuare upload di soli sorgenti se il tuo pacchetto ha qualche pacchetto binaryall (non usare l’opzione -S di dpkg-buildpackage). L’infrastruttura buildd non ne
effettuerà il build. Questo si applica anche agli upload di pacchetti normali.
48
• 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 (dpkg-buildpackage -sa). Se c’è stato un precedente upload
a security.debian.org con la stessa versione upstream, puoi inviare l’upload senza il
sorgente upstream (dpkg-buildpackage -sd).
• Assicurati di usare esattamente lo stesso *.orig.tar.gz usato nell’archivio normale,
altrimenti non sarà in seguito possibile spostare il fix di sicurezza nell’archivio principale.
• 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 ‘Macchine Debian’ a pagina 14) o impostare un chroot
(vedi ‘pbuilder’ a pagina 83 e ‘debootstrap’ a pagina 83).
Upload del pacchetto sistemato
NON effettuare un upload alla coda di upload disicurezza (oldstable-security, stable-security,
ecc.) senza avereprecedentemente ottenuto l’autorizzazione dal team di sicurezza. Seil pacchetto non soddisfa pienamente le richieste del team, porterànumerosi problemi e ritardi
durante la gestione dell’upload nonvoluto.
NON inviare i tuoi fix a proposed-updates senzaccordinarti con il team di sicurezza. I pacchetti
dasecurity.debian.org saranno automaticamente copiati nella directoryproposed-updates. Se
un pacchetto con lo stesso o più alto numero diversione è già installato all’interno dell’archivio,
l’aggiornamentodi sicurezza sarà rifiutato dal sistema dell’archivio. In quel modo,invece, la
distribuzione stable finirà senza un aggiornamento disicurezza per questo pacchetto.
Una volta che hai creato e controllato il nuovo pacchetto ed èstato approvato dal
team di sicurezza, deve essere inviato inupload in modo che possa essere installato negli archivi. Pergli aggiornamenti di sicurezza, il posto in cui inviare l’uploadè
ftp://security.debian.org/pub/SecurityUploadQueue/ .
Una volta che un upload alla coda di sicurezza è stato accettato,il pacchetto sarà automaticamente ricostruito per tutte learchitetture e messo da parte per la verifica dal team di
sicurezza.
Gli upload in attesa di essere accettati o verificati sono accessibilisolo dal team di sicurezza.
Questo è necessario siccome ci possonoessere dei fix per problemi di sicurezza che non possono
ancora esseredivulgati.
Se un membro del team di sicurezza accetta un pacchetto, questo saràinstallato su
security.debian.org così come nella giustadistribution-proposed-updates su ftp-master o
nell’archivionon-US.
5.9
49
Spostare, rimuovere, rinominare, adottare e abbandonare
pacchetti
Alcune operazioni di manipolazione dell’archivio non sono automatizzatenel processo di
upload Debian. Queste procedure dovrebbero essereseguite manualmente dai mantainers.
Questo capitolo fornisce dellelinee guida su cosa fare in questi casi.
5.9.1
Spostare pacchetti
A volte un pacchetto cambia la propria sezione. Per esempio, unpacchetto dalla sezione ‘nonfree’ potrebbe cambiare la proprialicenza in GPL in una successiva versione, in qual caso il
pacchettodovrebbe essere spostato in ‘main’ oppure ‘contrib’.1
Se devi cambiare la sezione di uno dei tuoi pacchetti, cambia leinformazioni di controllo
del pacchetto per posizionarlo sella sezionedesiderata, e invialo nuovamente in upload (vedi laPolicy Debian (http://www.debian.org/doc/debian-policy/) 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 deituoi pacchetti (p.es. “devel”, “admin”),la procedura è leggermentediversa. Correggi la sottosezione come appare nel file di
controllodel pacchetto, e invialo nuovamente in upload. In aggiunta, avraibisogno di far sì che
il file override venga aggiornato, come descrittoin ‘Specificare sezione, sottosezione e priorità
del pacchetto’ a pagina 40.
5.9.2
Rimuovere pacchetti
Se per qualche ragione vuoi completamente rimuovere un pacchetto (perdire, se è una
vecchia libreria di compatibilità che non è piùnecessaria), devi mandare un bug contro
ftp.debian.orgchiedendo che il pacchetto venga rimosso. Assicurati di indicare daquale
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 pacchettosia stato rimosso da unstable e nessun
pacchetto dipenda daesso.
Devi anche giustificare la richiesta spiegandone in dettaglio idettagli. Ciò per evitare rimozioni
indesiderate e tenere traccia delperchè un pacchetto è stato rimosso. Per esempio, puoi fornire
ilnome del pacchetto che sostituisce quello da rimuovere.
Di solito puoi chiedere la rimozione solo di un pacchetto mantenuto date stesso. Se vuoi
rimuovere un altro pacchetto, devi ottenerel’autorizzazione del suo mantainer.
Se sei in dubbio sul fatto che un pacchetto sia disponibileo meno, manda un email
a <[email protected]> chiedendo altreopinioni. È inoltre interessante il programmaapt-cache del pacchetto apt.Quando viene lanciato come apt-cache
1
Vedi la Policy Debian (http://www.debian.org/doc/debian-policy/)per le linee guida su a quale
sezione appartiene un pacchetto.
50
showpkgpackage, il programma mostrerà i dettagli dipackage, incluse le dipendenze inverse.
La rimozionedei pacchetti abbandonati è discussa su <[email protected]>.
Una volta che il pacchetto è stato rimosso, bisognerebbe gestirne ibug. Dovrebbero o essere riassegnati a un altro pacchetto nel casoin cui il codice reale si sia evoluto in un altro
pacchetto (p.es.libfoo12 è stato rimosso perchè libfoo13 losostituisce) oppure chiusi se
semplicemente il software non fa piùparte di Debian.
Rimuovere pacchetti da Incoming
In passato, era possibile rimuovere pacchetti da incoming.Comunque, con l’introduzione del
nuovo sistema di incoming, ciò non èpiù possibile. Piuttosto, devi inviare in upload una nuova
revisione deltuo pacchetto con una versione superiore a quella del pacchetto che haiintenzione di sostituire. Entrambe le versioni verranno installateall’interno dell’archivio ma solo la
versione più alta sarà realmentedisponibile in unstable, siccome la versione precedente saràimmediatamente sostituita dalla più alta. Comunque, se controllicorrettamente i tuoi pacchetti, il
bisogno di sostituire un pacchettonon dovrebbe succedere troppo spesso.
5.9.3
Rimpiazzare o rinominare pacchetti
Quando sbagli a dare il nome al tuo pacchetto, dovresti seguire un processocomposto da
due fasi per rinominarlo. Prima di tutto, imposta il tuo filedebian/control per sostituire ed essere in conflitto con il nome obsoleto del pacchetto(vedi la Policy Debian (http:
//www.debian.org/doc/debian-policy/) per idettagli). Una volta che hai effettuato
l’upload del pacchetto e che ilpacchetto stesso è stato spostato nell’archivio, invia un bug controftp.debian.org chiedendo di rimuovere il pacchetto con ilnome vecchio. Allo stesso
tempo non dimenticare di riassegnarepropriamente i bug del pacchetto.
Altre volte, puoi commettere uno sbaglio mentre costruisci il tuopacchetto e volerlo sostituire. Il solo modo di farlo è di aumentareil numero di versione è inviare in upload una nuova
versione. La vecchiaversione scadrà nel solito modo. Nota che questo si applica in ogniparte
del tuo pacchetto, sorgenti compresi: se vuoi rimpiazzare latarball dei sorgenti upstream del
tuo pacchetto, dovrai inviarlo inupload con una versione differente. Una semplice possibilità è
disostituire foo_1.00.orig.tar.gz confoo_1.00+0.orig.tar.gz. Questa restrizione
dà a ogni filesul sito ftp un nome unico, cosa che aiuta ad assicurare consistenzaattraverso la
rete dei mirror.
5.9.4
Abbandonare un pacchetto
Se non sei più in grado di mantenere un pacchetto, devi informare glialtri di questo, e vedere che il pacchetto sia marcato come orphaned.Dovresti impostare il mantainer del pacchetto a Debian QA Group<[email protected]> e inviare un bug report contro
il pseudo-pacchettownpp. Il bug report dovrebbe essere intitolatoO: package -- short
descriptionindicando che il pacchetto è ora abbandonato. La severità del bug dovrebbeessere impostata a normal. Se pensi che sia necessario, mandaneuna copia a <debian-devel@
51
lists.debian.org> mattendo l’indirizzo nell’headerX-Debbugs-CC: del messaggio (no,
non usare CC:, in quel modo l’oggettodel messaggio non indicherà il numero del bug).
Se il pacchetto è specialmente cruciale per Debian, dovresti invece mandareun bug contro wnpp e intitolarlo: RFA: package-- short description e impostarne la severità
aimportant. RFA sta per Request For Adoption(richiesta di adozione). In questo caso mandane
certamente una copia adebian-devel, come descritto poc’anzi.
Leggi le istruzioni sulle pagine web WNPP (http://www.debian.org/devel/wnpp/)per
ulteriori informazioni.
5.9.5
Adottare un pacchetto
Una lista dei pacchetti che necessitano un nuovo mantainer è disponibilenella lista dei pacchetti futuri e in bisogno di lavoro (WNPP) (http://www.debian.org/devel/wnpp/). Se
vuoi prenderti in carica la manutenzione di qualsiasi pacchettoelencato nella WNPP, per favore
guarda la succitata pagina perinformazioni e conoscere le procedure da seguire.
Non è corretto semplicemente rilevare un pacchetto che pensi siatrascurato — questo sarebbe un hijacking di pacchetti. Puoicertamente contattare il mantainer corrente e chiedergli se
puoiprendere il pacchetto sotto la tua custodia. Se hai delle ragioni percredere che un mantainer è andato “AWOL” (absent without leave), vedi ‘Trattare con mantainer inattivi e/o
irraggiungibili’ a pagina 75.
Generalmente, non puoi prendere il possesso del pacchetto senza ilconsenso del mantainer
corrente. Anche se ti ignorano, non ci sonolo stesso le basi per rilevare un pacchetto. Le
lamentele sui mantainerdovrebbero essere fatte sulla mailing list degli sviluppatori. Se ladiscussione non si conclude in modo positivo, e il problema è di naturatecnica, considera la possibilità di portarlo all’attenzione delcomitato tecnico (vedi la pagina web del comitato tecnico
(http://www.debian.org/devel/tech-ctte) per ulteriori informazioni).
Se rilevi un vecchio pacchetto, probabilmente vuoi essere elencatocome il mantainer ufficiale del pacchetto nel sistema dei bug.Questo avverrà automaticamente una volta che effettui
un upload di unanuova versione con il campo Maintainer: aggiornato, anche seci vorrà
qualche ora dopo che l’upload è stato fatto. Se non ti aspettidi effettuare alcun upload di una
nuova versione per un po’ di tempo,puoi usare ‘Il sistema di tracciamento dei pacchetti’ a pagina 26 per ottenere i bug report.Assicurati comunque che il vecchio mantainer non abbia dei
problemia continuare a ricevere i bug durante quel periodo.
5.10
Porting
Debian supporta sempre più architetture. Anche se non sei un porter,e usi una sola architettura, fa parte dei tuoi doveri di mantaineressere conscio dei problemi relativi alla portabilità.
Quindi, anchese non sei un porter, dovresti comunque leggere buona parte di questoparagrafo.
Il porting è l’atto di costruire pacchetti Debian per architetturediverse da quella originaria del
mantainer del pacchetto binario.È un’attività unica ed essenziale. Infatti, i porter effetuanola
52
maggior parte della compilazione reale di pacchetti Debian. Peresempio, per ogni singolo
pacchetto binario per i386,deve esserci una ricompilazione per ogni architettura, il chesignifica
12 ulteriori build.
5.10.1
Essere cortesi con i porter
I porters hanno un compito difficile e unico, dovendo avere a che farecon un grande numero
di pacchetti. Idealmente, ogni pacchetto sorgentedovrebbe riuscire nel build al primo colpo. Sfortunatamente ciò spessonon accade. Questa sezione contiene una lista di errori <–
FIXME:era gotchas –> commessi di frequente dai mantainer Debian —problemi comuni che
spesso pesanosui porter e rendono il loro lavoro inutilmente difficile.
La prima e più importarte cosa è rispondere velocemente ai bug oproblemi sollevati dai porter.
Per favore sii cortese con i porter,come se fossero co-mantainer del tuo pacchetto (e in un certo
sensolo sono). Per favore sii tollerante con bug report succinti o persinonon chiari, fa del tuo
meglio per ricercare cosa sia il problema.
Ad oggi, la maggior parte dei problemi incontrati dai porter sonocausati da bug di pacchettizzazione nei pacchetti sorgenti.Ecco una lista di cose che dovresti controllare o esserne a
conoscenza.
1 Assicurati che i settaggi Build-Depends eBuild-Depends-Indep nel tuo debian
/controlsiano correttamente impostati. Il miglior modo per assicurarseneè quello di usare il pacchetto debootstrap percreare un ambiente chroot unstable (vedi
‘debootstrap’ a pagina 83).All’interno di quell’ambiente chroot, installa il pacchettobuild-essential e tutte le dipendenzemenzionate nei campi Build-Depends
e/oBuild-Depends-Indep. Dopodichè prova a fare il build deltuo pacchetto all’interno di quell’ambiente chroot. Questoprocedimento può essere automatizzato tramite l’uso del programmapbuilder il quale è fornito dal pacchetto omonimo(vedi ‘pbuilder’
a pagina 83).
Se non puoi impostare un chroot corretto, dpkg-depcheckpuò aiutarti (vedi
‘dpkg-depcheck’ a pagina 85).
Vedi la Policy Debian (http://www.debian.org/doc/debian-policy/) peristruzioni su come impostare le dipendenze di build.
2 Non impostare “architecture” a un valore diverso da “all” o “any”a meno che tu non
sappia cosa stai facendo. In troppi casi i mantainernon seguono le istruzioni della Policy Debian (http://www.debian.org/doc/debian-policy/). Impostare la tua
architettura a “i386”è generalmente sbagliato.
3 Assicurati che il tuo pacchetto sorgente sia corretto.
Lanciadpkg-source -x
package.dsc per essere sicuroche il tuo pacchetto sorgente si decomprima correttamente. Dopodichè,da lì, prova a effettuare il build del tuo pacchetto da zero
condpkg-buildpackage.
4 Assicurati di non inserire nel pacchetto sorgente i filedebian/files o debian
/substvars.Questi file dovrebbero essere rimossi dal target ‘clean’ didebian/rules.
53
5 Assicurati di non fare affidamento su programmi installati in localeo su particolari configurazioni. Per esempio,non dovresti mai chiamare programmi in /usr/local/bin
osimili. Prova a non fare affidamento a programmi impostati in modospeciale. Prova a
fare il build del tuo pacchetto su un altra macchina,anche se della stessa architettura.
6 Non dipendere dal fatto che il pacchetto che stai costruendo sia giàinstallato (un sottocaso del problema sopra descritto).
7 Non dipendere se possibile dal fatto che il compilatore sia di unacerta versione. Se
non è possibile, assicurati che le tue dipendenzedi build rifletta la restrizione, anche
se stai probabilmente cercandodei guai, siccome a volte architetture diverse hanno dei
compilatoristandard diversi.
8 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 diloro, il che significa che si possa invocarne uno senza prima
averinvocato l’altro. Per provarlo, prova a lanciaredpkg-buildpackage -B.
5.10.2
Linee guida per gli upload dei porter
Se il pacchetto effettua il build senza problemi sull’architetturasu 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 builde l’upload del tuo pacchetto binario in modo che sia propriamente installatonell’archivio. Se devi apportare delle correzioni al pacchetto per farein modo che possa essere compilato
per l’altra architettura, stai inrealtà effettuando un NMU, qundi devi invece consultare ‘Come
fare un NMU di sorgenti’ a pagina 58.
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 debian/changelog.
Il
modo
invocare
dpkg-buildpackage
èdpkg-buildpackage -B
-mporter-email.Ovviamente imposta porter-email con il tuo indirizzoemail. Questo
effettuerà il build binario solo per le parti del pacchettodipendenti dall’architettura, usando il
target ‘binary-arch’in debian/rules.
Ricompilazione di NMU esclusivamente binari
A volte l’upload iniziale del porter è problematico in quanto l’ambientein cui è stato costruito il pacchetto non è abbastanza buono (librerievecchie o obsolete, cattivo compilatore, . . . ).In
tal caso potresti semplicemente doverlo ricompilare in un ambienteaggiornato. In questo caso, devi incrementare il numero di versione, inmodo che il vecchio pacchetto non funzionante possa essere rimpiazzatonell’archivio Debian (katie si rifiuta di installare nuovipacchetti
se non hanno un numero di versione maggiore rispetto a quellocorrentemente disponibile).
Nonostante le modifiche richieste al changelog,queste sono chiamate NMU solo binari — in
questo caso non c’è bisognodi fare scattare tutte le altre architetture perconsiderarsi superate o
richiederne la ricompilazione.
54
Tali ricompilazioni richiedono una speciale “magica” numerazione diversione, in modo che
gli strumenti di manutenzione dell’archivioriconoscano che, sebbene ci sia una nuova versione Debian, non esisteun corrispondente aggiornamento dei sorgenti. Se sbagli, i mantainerdell’archivio respingeranno il tuo upload (dovuto alla mancanza delcorrispondente codice
sorgente).
La “magia” per un NMU solo di ricompilazione viene fatta scattareusando il numero di terzo
livello sulla parte Debian del numero diversione. Per esempio, se stai ricompilando la versione
“2.9-3”,il tuo NMU dovrebbe avere versione “2.9-3.0.1”. Se l’ultima versioneera“3.4-2.1”, il tuo
NMU dovrebbe avere il numero di versione“3.4-2.1.1”.
Quando fare un NMU di sorgenti se sei un porter
I porter che effettuano un NMU di sorgenti seguono generalmente lelinee guida trovate in
‘Non-Maintainer Upload (NMU)’ a fronte, esattamente come gli altri.Comunque, ci si aspetta
che il ciclo di attesa per un NMU sorgentedi un porter sia minore rispetto per uno normale,
siccome i porterdevono far fronte a una grande quantità di pacchetti. Di nuovo,la situazione
cambia dipendentemente dalla distribuzione su cuisi vuole effettuare l’upload.
Comunque, se sei un porter e stai facendo un NMU per ‘unstable’, dovrestiseguire 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 giorniper i porter
che lavorano sulla distribuzione unstable. Questo periodopuò essere accorciato se il problema
è critico e ostacola l’attivitàdi porting, a discrezione del gruppo dei porter. (Ricorda, niente
ditutto ciò è Policy, ma solo accordi sulle linee guida.)
Secondo, i porter che effettuano NMU di sorgenti dovrebbero assicurarsiche il bug che inviano
al BTS dovrebbe essere di severità ‘serious’ omaggiore. Ciò assicura che un singolo pacchetto
sorgente possa esserecompilato su tutte le architetture supportate da Debian al tempo delrilascio. È molto importante il fatto di avere una versione delpacchetto binario e sorgente per tutte
le architetture in modo da soddisfarei requisiti di molte licenze.
I porter dovrebbero provare a evitare patch che girano semplicementeattorno a bug nella versione corrente dell’ambiente di compilazione,del kernel, o delle libc. A volte questi kludgenon
si possono evitare. Se devi girare attorno a bug del compilatoree cose simili, assicurati di definire propriamente il tuo lavoro con#ifdef; inoltre, documenta i kludge che fai in modo che
lagente possa sapere come rimuoverli una volta che il problema esternoè stato risolto.
I porter possono anche avere un posto non ufficiale dove riporre irisultati del proprio lavoro
durante il periodo di attesa. Ciòaiuta gli altri che usano il port a trarne beneficio anche duranteil periodo di attesa. Ovviamente tali locazioni non hanno nessuna’benedizione’ ne riscontro
ufficiale, quindi i clientisono avvisati.
5.10.3
Infrastrutture e automazione nel porting
Esiste un’infrastruttura e diversi strumenti per aiutare ad automatizzareil porting dei pacchetti. Questa sezione contiene una breve vista d’insiemedi questa automazione e di que-
55
sti strumenti; leggi la documentazione delpacchetto o altri riferimenti per le informazioni
complete.
Mailing list e pagine web
Le pagine web contenenti lo stato di ogni port si trovanoall’indirizzo http://www.debian.
org/ports/.
Ogni port di Debian ha la propria mailing list. La lista delle mailinglist dei porting si
trova all’indirizzo http://lists.debian.org/ports.html.Queste liste sono usate per
coordinare i porter e per mettere in contattogli utenti di un dato port con i porter.
Strumenti dei porter
Le descrizioni dei diversi strumenti per il porting si trovanoin ‘Porting tools’ a pagina 85.
buildd
Il sistema buildd è usato come un sistema distribuitoclient-server di build delle distribuzioni.
Di solito è usato insieme aauto-builders, che sono host “slave” che semplicementecontrollano
e cercano di fare il build automatico dei pacchettidei quali si deve effettuare il porting. Esiste
anche un’interfacciaemail al sistema, che permette ai porter di controllare un pacchettosorgente
(di solito uno di cui non si puo’ ancora fare il buildautomaticamente) e lavorarci sopra.
buildd non è ancora disponibile come pacchetto;comunque, la maggior parte dei porter o
lo stanno correntementeusando o pianificando di usarlo in un futuro non lontano. Il builderreale è pacchettizzato come sbuild, vedi la suadescrizione in ‘sbuild’ a pagina 83.Il sistema buildd completo include anche un certonumero di componenti ancora da pacchettizzare
molto utili che vengonousati continuamente, come andrea e wanna-build.
Una parte delle informazioni prodotte da buildd che sonogeneralmente utili ai porter sono disponibili sul web all’indirizzo http://buildd.debian.org/. Queste informazioni includono le informazioni aggiornategiornalmente da andrea (dipendenze deisorgenti) e
quinn-diff (pacchetti che necessitano unaricompilazione).
Siamo abbastanza fieri di questo sistema, siccome ha tanti usi possibili.Gruppi di sviluppatori
indipendenti possono usare il sistema per diversevarianti secondarie di Debian, che possono essereo meno di interesse generale (per esempio, una versione di Debian costruitacon il
bound-checking di gcc). Renderà inoltre Debian ingrado di ricompilare velocemente intere
distribuzioni.
5.11
Non-Maintainer Upload (NMU)
In certe circostanze è necessario per qualcuno che non sia il mantainerufficiale del pacchetto
effettuarne una release. Questoè chiamato un non-maintainer upload, in breve NMU.
56
I porter Debian, i quali compilano i pacchetti per differentiarchitetture, effettuano occasionalmente dei NMU solo binari comeparte della loro attività di porter (vedi ‘Porting’ a pagina 51).Un altra ragione per cui vengono fatti dei NMU è quando unosviluppatore Debian
necessita di correggere pacchetti di altrisviluppatori in modo da indirizzare seri problemi di
sicurezza obug paralizzanti, specialmente durante il periodo di freeze, o quandoil mantainer
del pacchetto non è in grado di risolvere il problemain tempi ragionevoli.
Questo capitolo contiene informazioni che forniscono le linee guidasu quando e come dovrebbero essere fatti i NMU. Una distinzionefondamentale è fatta tra NMU di sorgenti e solo binari,
spiegatanella prossima sezione.
5.11.1
Terminologia
Ci sono due nuovi termini usati all’interno di questa sezioni:“NMU solo binari” e “NMU di
sorgenti”. Questi termini vengonousati con dei significati tecnici specifici in tutto questo documento.NMU di sorgenti e solo binari sono simili tra loro, siccome implicanoentrambi un
upload di un pacchetto da uno sviluppatore che non è ilmantainer ufficiale del pacchetto. Ecco
perchè è unnon-maintainer upload.
Un NMU di sorgenti è un upload di un pacchetto fatto da uno sviluppatoreche non è il mantainer ufficiale del pacchetto, fatto per risolvereun baco del pacchetto. Gli NMU di sorgenti implicano sempre dellemodifiche al sorgente (anche se è solo una modifica aldebian/changelog).
Cio può essere sia una modifica alsorgente upstream o una modifica alla parte Debian del sorgente.Nota, comunque, che NMU di sorgenti possono anche includere pacchettidipendenti
dall’architettura, così come una diff Debian aggiornata.
Un NMU solo binario è una ricompilazione e upload di un pacchettobinario per una certa
architettura. Di solito è parte di un lavorodi porting. Un NMU solo binario è un upload,
non effettuato dal suomantainer, della versione binaria del pacchetto, senza che sianorichieste
modifiche ai sorgenti. Ci sono diversi casi in cui i porterdevono risolvere dei problemi nei
sorgenti per farli compilare nellaloro architettura; questo sarebbe considerato un NMU di sorgentipiuttosto che un NMU solo binario. Come puoi vedere, non facciamoalcuna distinzione
nella terminologia tra NMU di porter e NMU nondi porter.
Entrambe le classi di NMU, di sorgenti e solo binari, possono essereriferite con il termine generico “NMU”. Ciò nonostante, questo causaspesso confusione, in quanto per molta gente
“NMU” significa “NMUdi sorgenti”, quindi è meglio fare attenzione. In questo capitolo, seusiamo il termine generico “NMU” ci riferiamo a qualunque tipo dinon-mantainer upload, che
sia di entrambi (sorgenti e binari) o solodi binari.
5.11.2
Chi può fare un NMU
Solo i mantainer Debian ufficiali e registrati possono fare NMU binario di sorgenti, Un mantainer ufficiale è qualcuno che ha la sua chiavenel keyring Debian. I non sviluppatori, comunque,
sono incoraggiati ascaricare il pacchetto sorgente e iniziare a lavorarci su per risolverei problemi; comunque, piutosto che fare un NMU, dovrebbero semplicementeinviare patch al sistema
di tracciamento dei bug. I mantainer quasi sempreapprezzano le patch di qualità e i bug report.
5.11.3
57
Quando fare un NMU di sorgenti
Le linee guida su quando fare un NMU di sorgenti dipendono dalladistribuzione bersaglio, ovvero stable, unstable o experimental.I porter hanno delle regole leggermente differenti rispetto
ai non-porter, a causa delle loro circostanze uniche (vedi‘Quando fare un NMU di sorgenti se
sei un porter’ a pagina 54).
Quando viene trovato un bug di sicurezza, il team di sicurezzapuò effettuare un NMU. Per
favore vedi ‘Gestire i bug di sicurezza’ a pagina 44per ulteriori informazioni.
Durante il ciclo di rilascio (vedi ‘Stable, testing e unstable’ a pagina 20),gli NMU che sistemano
bug di sicurezza di severità uguale o maggiorea serious sono incoraggiati e accettati. Anche
in questo caso dovresticomunque adoperarti per contattare il mantainer del pacchetto; potrebbestare giusto per inviare in upload un fix per il problema. Come perqualunque NMU di
sorgenti, devono essere seguite le linee guida in‘Come fare un NMU di sorgenti’ nella pagina
successiva. Si fanno eccezioni speciali per ‘Bug squashing party’ a pagina 74.
Upload di fix per bug in unstable dovrebbero essere fatti solo rispettandoquesto protocollo:
• Assicurati che i bug a cui è indirizzato a risolvere il NMU sono tuttischedati nel sistema
di tracciamento dei bug (BTS). Se non lo sono,inviali immediatamente.
• Aspetta qualche giorno la risposta dal mantainer. Se non ricevi alcunarisposta, puoi se
vuoi aiutarli inviando la patch che sistema il bug.Non dimenticare di marcare il bug con
la parola chiave “patch”.
• Aspetta ancora qualche giorno. Se ancora non ricevi risposta dalmantainer, scrivigli una
email annunciando la tua intenzione difare un NMU sul pacchetto. Prepara un NMU
come descritto in‘Come fare un NMU di sorgenti’ nella pagina successiva, controllalo
attentamente sulla tua macchina(vedi ‘Controllare il pacchetto’ a pagina 34).Controlla
doppiamente che la tua patch non abbia alcun inaspettatoeffetto collaterale. Assicurati
che la tua patch sia più piccola enon distruttiva possibile.
• Invia il pacchetto in upload a incoming in DELAYED/7-day(vedi ‘Incoming ritardato’ a
pagina 25), manda la patch definitiva al mantainervia BTS e spiegagli che hanno 7 giorni
per reagire se vogliono cancellarel’NMU.
• Segui quello che accade, sei responsabile per qualsiasi bug tu abbiaintrodotto con il tuo
NMU. Probabilmente dovresti usare ‘Il sistema di tracciamento dei pacchetti’ a pagina 26
(PTS) per essere informato dello stato delpacchetto dopo il tuo NMU.
A volte, il release manager di un gruppo organizzato di sviluppatori puòannunciare un certo
periodo di tempo in cui le regole sugli NMU vengonorese meno severe. Questo di solito implica l’accorciamento del periododi attesa che precede l’invio dei fix e del periodo DELAYED.
È importantenotare che anche durante i cosiddetti “bug squashing party”, colui cheesegue
l’NMU deve prima inviare i bug e contattare lo sviluppatore e poiagire.
5.11.4
58
Come fare un NMU di sorgenti
Ciò che segue si applica ai porter finchè giocano il doppio ruolo dibug-fixer e porter di pacchetti. Se un porter deve modificare l’archiviodei sorgenti Debian, il suo upload è automaticamente
un NMU di sorgentied è soggetto alle sue regole. Se un porter sta solo inviando in uploadun
pacchetto binario ricompilato, le regole sono differenti; vedi‘Linee guida per gli upload dei
porter’ a pagina 53.
Prima di tutto è essenziale che le patch NMU dovrebbero essere menodistruttive possibile per
i sorgenti. Non fare dell’housekeeping ditask , non cambiare il nome dimoduli o di file, non
spostare directory; in generale, non aggiustareniente che non sia rotto. Rendi la patch più piccola possibile. Seci sono cose che esteticamente non ti piacciono, parlane al mantainerDebian,
parlane al mantainer upstream, o riporta un bug. In ogni caso,modifiche estetiche non devono
essere fatte in un non-maintainerupload.
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 sistemadi funzionare.
Se stai facendo un non-maintainer upload (NMU), dovresti aggiungereun nuovo numero di
versione minore alla parte debian-revisiondel numero di versione (la parte dopo l’ultimotrattino). 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 sarebbefoo_1.1-3.dsc. La versione upstream è ‘1.1’ e la revisioneDebian è ‘3’. Il successivo NMU
aggiungerebbe un nuovo numero minore ‘.1’alla revisione Debian; il nuovo file di controllo del
sorgente sarebbefoo_1.1-3.1.dsc.
Il numero minore della revisione Debian serve per evitare di rubareuno dei numeri di versione
dei mantainer del pacchetto, che potrebbedistruggere il loro lavoro. Ha anche il vantaggio
di renderevisibilmente chiaro che un pacchetto nell’archivio non è stato fattodal mantainer
ufficiale.
Se non c’è nessuna componente debian-revision nel numero diversione ne dovrebbe essere creata una, cominciando da ‘0.1’. Se èassolutamente necessario per qualcuno che non sia il solito
mantainerrilasciare una release basata su una nuova versione upstream, questapersona dovrebbe cominciare con il valore debian-revision a‘0.1’. Il mantainer ufficiale di un pacchetto
dovrebbe cominciare lasua numerazione debian-revision con ‘1’.
Gli NMU di sorgenti devono avere una nuova voce di changelog
Un non-mantainer che fa un NMU di sorgenti deve creare una voce dichangelog, descrivendo
quali bug sono sistemati dal NMU, e generalmenteperchè era richiesto un NMU e cosa ha risolto. La voce di changelogavrà l’indirizzo email del non-mantainer nella voce di log e ilnumero
della versione del NMU in essa.
Per consuetudine, le voci di changelog degli NMU di sorgenti comincianocon la linea
59
* Non-maintainer upload
NMU di sorgenti e il sistema di tracciamento dei bug
I mantainer diversi dal mantainer ufficiale del pacchetto dovrebberofare meno modifiche possibili al pacchetto, e dovrebbero sempre mandareuna patch nel formato “unified context diff”
(diff -u) spiegandoi dettagli delle loro modifiche al sistema di tracciamento dei bug.
E se stai semplicemente ricompilando il pacchetto? Se hai solo bisognodi ricompilarlo per una
singola architettura puoi fare un NMU solobinario come descritto in ‘Ricompilazione di NMU
esclusivamente binari’ a pagina 53 il che nonrichiede l’invio di alcuna patch. Se vuoi che il
pacchetto vengaricompilato per tutte le architetture, fai un NMU di sorgenti comeal solito e
dovrai spedire una patch.
Se il NMU (non-mantainer upload) di sorgenti risolve qualche bugesistente, tali bug piuttosto
che essere chiusi dovrebbero esseremarcati come fixed nel sistema di tracciamento dei bug.Per
convenzione, solo il mantainer ufficiale del pacchetto o chiha originariamente riportato il bug
sono autorizzati a chiuderebug. Fortunatamente il sistema dell’archivio Debian riconosce iNMU e quindi marca appropriatamente i bug sistemati dal NMU sechi lo ha inviato ha elencato
tutti i bug nel changelog con lasintassi Closes: bug#nnnnn(vedi‘Quando i bug vengono
chiusi da nuovi upload.’ a pagina 44 per ulteriori informazioni su comechiudere bug attraverso il changelog). Marcare i bug fixedassicura che tutti sappiano che il bug è stato risolto
in un NMU;comunque il bug è lasciato aperto finche le modifiche fatte nelNMU non siano
ufficialmente incorporate nel pacchetto dal suomantainer ufficiale.
Inoltre, dopo aver fatto un NMU, devi aprire un nuovo bug e includereuna patch mostrando
tutte le modifiche che hai apportato. In alternativapuoi mandare quelle informazioni ai bug
esistenti che sono stati sistematidal tuo NMU. Il mantainer normale o applicherà la patch o
impiegherà unmetodo alternativo per risolvere il problema. A volte i bug sono sistematia
monte in modo indipendente, che è un altra buona ragione per annullarele modifiche fatte
dalla patch NMU. Se il mantainer decide di non applicarela patch NMU ma di rilasciare una
nuova versione, egli deve assicurarsi chela nuova versione upstream risolva sul serio ogni
problema che è statosistemato nella release del non-mantainer.
In aggiunta, il mantainer normale dovrebbe sempre conservarela voce nel changelog che
documenta il non-mantainer upload.
Costruire NMU di sorgenti
I NMU di sorgenti dei pacchetti sono costruiti normalmente. Scegliuna distribuzione usando
le stesse regole trovate in ‘Scegliere la distribuzione’ a pagina 36, segui le altre prescrizioni in
‘Effetuare un upload’ a pagina 37.
Assicurati di non cambiare il valore del mantainer nelfile debian/control. Il tuo nome come
dato nella vocedel NMU del file debian/changelog sarà usato per firmareil file changes.
5.11.5
60
Riconoscere un NMU
Se viene effettuato un NMU su uno dei tuoi pacchetti, devi incorporarele modifiche nella tua
copia dei sorgenti. Questo è facile, devi soloapplicare la patch che ti è stata spedita. Una volta
che l’hai fatto,devi chiudere i bug che sono stati marcati come fixed dal NMU. Puoichiuderli o
manualmente mandando le mail richieste al BTS o aggiungendole richieste closes: #nnnn
nella voce del changelog del tuoprossimo upload.
In ogni caso, non dovresti essere arrabbiato per il NMU. Un NMU non èun attacco personale
nei confronti del mantainer, è una prova chequalcuno tiene abbastanza al pacchetto da volerti
aiutare nel tuolavoro, quindi dovresti esserne grato. Potresti anche volerglichiedere se sarebbero interessati ad aiutarti più frequentemente comeco-mantainer o mantainer di riserva (vedi
‘Manutenzione collaborativa’ in questa pagina).
5.12
Manutenzione collaborativa
“Manutenzione collaborativa” è un termine che descrive la condivisionedei compiti di manutenzione di pacchetti da parte di più persone.Questa collaborazione è quasi sempre una buona
idea, siccome porta auna maggiore qualità e velocizza i tempi di sistemazione dei bug. Èfortemente raccomandato che i pacchetti con una priorità Standardo che fanno parte del sistema
base abbiano dei co-mantainer.
Generalmente c’è un mantainer principale e uno o più co-mantainer. Ilmantainer principale
è la persona il cui nome è elencato nel campoMaintainer del file debian/control. Icomantainer sono tutti gli altri.
Nella sua forma di base, il processo di aggiungere un nuovo co-mantainerè abbastanza
semplice:
• Dai al co-mantainer accesso ai sorgenti da cui costruisci il pacchetto.Generalmente questo implica l’uso di un sistema di controllo di versionenetwork-capable, come CVS o
Subversion.
• Aggiungi il nome e l’indirizzo corretti del maintainer al campoUploaders nella sezione
globale del file debian/control.
Uploaders: John Buzz <[email protected]>, Adam Rex
<[email protected]>
• Usando il PTS (‘Il sistema di tracciamento dei pacchetti’ a pagina 26), i comaintainerdovrebbero iscriversi all’appropriato pacchetto sorgente.
La manutenzione collaborativa spesso può essere ulteriormente facilitatacon l’uso degli
strumenti su Alioth (vedi ‘Debian *Forge: Alioth’ a pagina 30).
61
Capitolo 6
Procedimenti di pacchetizzazione
consigliati
La qualità di Debian è in gran parte dovuta alla policy Debian (http://www.debian.org/
doc/debian-policy/), che definisce degli espliciti requisiti di basea cui tutti i pacchetti
Debian devono conformarsi. C’è anche ormai unpassato di esperienze condivise che vanno
oltre la policy Debian, unaccumulo di anni di esperienza nella pacchettizzazione. Molta gente
digrande 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.
6.1
Procedimenti consigliati per debian/rules
Le seguenti raccomandazioni riguardano il file debian/rules.Considerando che il file
debian/rules 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 maintainerpassano
più tempo.
6.1.1
Script helper
La ragione per cui utilizzare gli script helper in debian/rules è che permettono ai maintainer di usare e condividere una logica comunetra più pacchetti. Si prenda per esempio il
problema di installare deglielementi di menu: è necessario mettere il file in /usr/lib/menu,e
aggiungere comandi ai maintainer script per registrare e eliminare elementidal menu. Visto
che si tratta di una cosa molto comune che i pacchetti fanno,perchè ogni maintainer dovrebbe
Capitolo 6. Procedimenti di pacchetizzazione consigliati
62
riscrivere tutto ciò da solo, a volte con deibug? Inoltre, supponendo che la directory dei menu
cambi, ogni pacchetto dovrebbe essere modificato.
Gli script helper si occupano di queste problematiche. Rispettando leconvenzioni, 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 versiondegli
helper e nessun altro cambiamento.
‘Overview of Debian Maintainer Tools’ a pagina 79 contiene un paio di diversi helper. Il sistema (a nostroparere) migliore e più comune è debhelper. I precedenti sistemi, come debmake,
erano “monolitici”:non era possibile scegliere la parte desiderata del sistema ed utilizzarla,si
doveva utilizzare il sistema intero per fare tutto. debhelper,invece, è una raccolta di piccoli
programmi dh_*. Per esempio,dh_installman installa e comprime le pagine di manuale,dh_installmenu installa i file menu e via dicendo. Offre quindiabbastanza flessibilità da
essere in grado di utilizzare i piccoli script helper, quando servono, insieme ad altri comandi
in debian/rules.
Si può iniziare con debhelper leggendodebhelper(1), e seguendo gli esempi forniticon il
pacchetto. dh_make, dal pacchettodh-make (si veda ‘dh-make’ a pagina 82), può essereusato per convertire un pacchetto sorgente “vanilla” in uno che fa usodi debhelper. Questa
scorciatoia, comunque, non dovrebbe convincerti che non hai bisogno di disturbarti a capire i singoli script dh_*. Se userai un helper, hai bisogno diimpararlo, per comprenderne il
comportamento.
Alcuni sono convinti che i normali file debian/rules sianomeglio, 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 debian/rules vanilla sono disponibili suhttp://people.
debian.org/~srivasta/rules/.
6.1.2
Separare le patch in file multipli
Pacchetti grandi e complessi possono avere molti bug su cui lavorare.Correggendo un bug
direttamente nei sorgenti, può diventare difficiledifferenziare le varie patch applicate. Può diventare un bel problemaquando è necessario aggiornare il pacchetto ad un nuovo rilascioupstream che integra alcune delle modifiche (ma non tutte). Non èpossibile prendere l’insieme
totale dei diff (per esempio, da .diff.gz) e trovare in maniera unitaria le patch cherisolvono
bug chiusi dall’upstream.
Sfortunatamente, al momento il sistema di pacchettizzazione non fornisceil supporto per separare le patch in più file. Comunque, ci sono modi perseparare le patch: i file che le contengono
sono inclusi nel file patch Debian (.diff.gz), solitamente nella directory debian/.L’unica differenza è che non vengono applicate immediatamente da dpkg-source,ma dalla regola
build di debian/rules. La regolaclean si occupa di invertire questo comportamento.
dbs è uno degli approcci più comuni a questo problema. Consentedi fare tutto quello che è
stato spiegato precedentemente e agevola la creazionee l’aggiornamento di vecchie patch. Si
veda il pacchetto dbs per ulteriori informazioni e hello-dbs come esempio.
63
Anche dpatch ha queste caratteristiche, ma è pensato per essereancora più facile da usare.
Si faccia riferimento al pacchetto dpatch come fonte di documentazione ed esempi (in /usr
/share/doc/dpatch).
6.1.3
Pacchetti binari multipli
Un singolo pacchetto sorgente costruisce spesso più di un pacchettobinario, sia per fornire
più versioni dello stesso software (es.,il pacchetto sorgente di vim) o per dividere ungrosso
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 debian/rules.Semplicemente, è necessario spostare i file appropriati dalla directory di build negli alberi temporanei dei pacchetti. Per farlo si possonousare install oppure dh_install, dal pacchetto debhelper.
Ci si assicuri di controllarecome interagiscono i vari pacchetti, assicurandosi di avere le
correttedipendenze tra pacchetti in debian/control.
Il primo caso è un pochino più difficile visto che coinvolge ricompilazioni multiple dello stesso
software ma con opzioni di configurazionedifferenti. Il pacchetto sorgente di vim è un esempio
dicome gestire questa situazione usando un file debian/rulesscritto a mano.
6.2
Procedimenti consigliati per debian/control
I consigli seguenti sono relativi al file debian/control. Sono unsupplemento alla Policy
on package descriptions (http://www.debian.org/doc/debian-policy/ch-binary.
html#s-descriptions).
La descrizione del pacchetto, definita dal campo corrispondente del filecontrol, contiene sia
la descrizione breve (synopsis) che quella lunga del pacchetto. ‘Linee guida generiche per le
descrizioni dei pacchetti’ in questa pagina descrive alcune lineeguida applicabili ad entrambe.‘La sinossi del pacchetto, o descrizione breve’ nella pagina seguente fornisce consigli specifici alla descrizione breve,mentre ‘La descrizione lunga’ a pagina 65 contiene consigli relativi
alla descrizione lunga.
6.2.1
Linee guida generiche per le descrizioni dei pacchetti
La descrizione di un pacchetto dovrebbe essere scritta pensando alprobabile utente medio,
la persona media che userà e trarrà beneficiodal pacchetto. Per esempio, pacchetti di sviluppo sono per glisviluppatori, e possono presentare un linguaggio tecnico. Altregeneriche
applicazioni, come gli editor, dovrebbero essere scritti perun utente meno tecnico.
La nostra revisione delle descrizioni dei pacchetti ci ha portatoa concludere che molte descrizioni dei pacchetti sono tecniche,il che significa che non sono scritte per avere un senso per
gliutenti non esperti. A meno che il tuo pacchetto sia realmente soloper utenti esperti, questo
è un problema.
64
Come puoi scrivere per utenti non tecnicamente esperti? Evita iljargon. Evita di riferirti ad
altre applicazioni o framework con iquali l’utente potrebbe non essere familiare — “GNOME” o “KDE”vanno bene, siccome questi termini sono probabilmente familiari agliutenti, ma
“GTK+” probabilmente no. Prova a non assumere nessunaconoscenza in assoluto. Se devi
usare termini tecnici, introducili.
Sii obiettivo. Le descrizioni dei pacchetti non sono il posto perpromuovere il tuo pacchetto,
non importa quanto ci tieni. Ricordache al lettore potrebbero non importare le stesse cose a cui
tieni.
Riferimenti ai nomi di qualunque altro software, pacchetto, nome diprotocollo, standard
o specifica dovrebbero usare le loro formecanoniche, se esistono. Per esempio, usa “X
Window System”, “X11”oppure “X”; e non non “X Windows”, “X-Windows”, or “X Window”.Usa “GTK+”, non “GTK” o “gtk”. Usa “GNOME”, non “Gnome”. Usa“PostScript”,
non “Postscript” oppure “postscript”.
Se hai problemi a scrivere la tua descrizione, potresti
<[email protected]> e chiedere aiuto.
6.2.2
voleremandarla
a
La sinossi del pacchetto, o descrizione breve
La linea della sinossi (la descrizione breve) dovrebbe essere concisa.Non deve ripetere il nome
del pacchetto (questa è policy).
È una buona idea pensare alla sinossi come una clausola appositivae non come una frase completa. Una clausola appositiva è definita inWordNet come una relazione grammaticale tra
una parola e una conseguentefrase sostantiva, p.es. , “Rudolph the red-nosed reindeer”. Qui
la clausolaappositiva è “red-nosed reindeer”. Siccome la sinossi è una clausola più cheuna
frase completa, la nostra raccomandazione è che non cominci con la letteramaiuscola nè finisca con un punto. Non dovrebbe inoltre cominciare con unarticolo, sia definito (“the”) che
indefinito(“a” oppure “an”).
Potrebbe aiutarti immaginare che la sinossi sia combinata con ilnome del pacchetto nel modo
seguente:
package-name is a synopsis.
Alternativamente, potrebbe avere un senso pensarla come
package-name is synopsis.
oppure, se il nome stesso del pacchetto è plurale (come per esempio“developers-tools”)
package-name are synopsis.
Questo modo di creare una frase dal nome del pacchetto e la sinossidovrebbe essere considerato euristico e non una regola stretta. Cisono alcuni casi in cui non ha senso cercare di formare
una frase.
6.2.3
65
La descrizione lunga
La descrizione lunga è la principale fonte d’informazioni disponibileall’utente circa un pacchetto prima che lo installi. Dovrebbe forniretutte le informazioni necessarie all’utente per
decidere seinstallare o meno il pacchetto. Assumi che l’utente abbia già lettola sinossi del
pacchetto.
La descrizione lunga dovrebbe consistere in frasi complete.
Il primo paragrafo della descrizione lunga dovrebbe rispondere alleseguenti domande: cosa fa
il pacchetto? Quali compiti aiuta l’utentea svolgere? È importante descrivere ciò in modi non
tecnici,a meno che ovviamente il pacchetto sia destinato proprio a personeesperte.
I paragrafi seguenti dovrebbero rispondere alle seguenti domande: perchèdovrei come utente
avere bisogno di questo pacchetto? Quali altrecaratteristiche ha il pacchetto? Cosa ha in più
o in meno comparatocon altri pacchetti (p.es. “se hai bisogno di X, usa invece Y”)?Questo
pacchetto è correlato ad altri in qualche modo che non possaessere gestito dal manager dei
pacchetti (p.es. “questo è un clientper il server foo”)?
Stai attento ad evitare errori ortografici o grammaticali. Assicuratidi controllarne l’ortografia.
ispell ha un’opzione speciale-g per i file debian/control:
ispell -d american -g debian/control
6.2.4
Home page upstream
Ci raccomandiamo che tu aggiunga l’URL della home page del pacchettoalla sua descrizione in
debian/control. Questa informazionedovrebbe essere aggiunta alla fine della descrizione,
usando il seguenteformato:
.
Homepage: http://some-project.some-place.org/
Nota che gli spazi che precedono la linea, che servono per romperecorrettamente le linee.
Per vedere un esempio di come viene visualizzato,vedi http://packages.debian.org/
unstable/text/docbook-dsssl.html.
Se non c’è nessuna home page per il software, naturalmente non si dovrebbeinserire.
Nota che ci aspettiamo che questo campo venga eventualmente rimpiazzatoda un vero e proprio campo in debian/control riconosciutoda dpkg e packages.debian.org. Se non
hai voglia dispostare la home page dalla descrizione a questo campo, probabilmentedovresti
aspettare finchè detto campo sia disponibile.
6.3
Procedimenti consigliati per debian/changelog
I seguenti procedimenti integrano la Policy dei file changelog (http://www.debian.org/
doc/debian-policy/ch-docs.html#s-changelogs).
6.3.1
66
Scrivere voci di changelog utili
La voce di changelog per una revisione di un pacchetto documenta lemodifiche effettuate in
quella revisione, e solo quelle. Concentratinel descrivere le modifiche significanti e visibili
dall’utente che sono state fatte dall’ultima versione.
Focalizzati su cosa è stato cambiato — chi, come e quandogeneralmente sono meno importanti.
Detto ciò, ricordati di accreditareeducatamente le persone che hanno fornito un valido aiuto
nel preparareil pacchetto (p.es. chi ha mandato delle patch).
Non c’è bisogno di elaborare le modifiche triviali e ovvie. Puoi ancheunire diverse modifiche
in una sola voce. Dall’altro lato non esseretroppo succinto quando spieghi dei cambiamenti
importanti. Siispecialmente chiaro se ci sono modifiche che influiscono il comportamentodel
programma. Per ulteriori siegazioni, usa il fileREADME.Debian.
Usa l’inglese comune in modo che la maggioranza dei lettori possacomprenderlo. Evita abbreviazioni, gergo tecnico e il jargon quandospieghi modifiche che chiudono bug, specialmente
per bug inviati dautenti che non ti sono sembrati particolarmente esperti. Siieducato, non
rispondere male.
A volte è desiderabile premettere i nomi dei file che sono statimodificati alle voci di changelog. Non c’è comunque bisogno dielencare esplicitamente ogni file modificato, specialmente
sedette modifiche sono piccole o ripetitive. Puoi usare le wildcards.
Quando ti riferisci a bug, non presumere niente. Di quale era ilproblema, e aggiungi la stringa
“closes: #nnnnn”. Vedi‘Quando i bug vengono chiusi da nuovi upload.’ a pagina 44 per
ulteriori informazioni.
6.3.2
Concetti comunemente sbagliati sulle voci di changelog
Le voci di changelog non dovrebbero documentareinformazioni generiche di pacchettizzazione (“Hey, if you’re lookingfor foo.conf, it’s in /etc/blah/.”),siccome gli amministratori e
gli utenti si pensa conoscano almenolontanamente come queste cose vengono generalmente arrangiate neisistemi Debian. Menzionalo, comunque, se cambi la locazione di un file
diconfigurazione.
I bug chiusi con una voce di changelog dovrebbero essere quelli chesono realmente risolti
nella stessa revisione del pacchetto. Chiuderebug nel changelog che non c’entrano nulla è una
cattiva abitudine.Vedi ‘Quando i bug vengono chiusi da nuovi upload.’ a pagina 44.
Le voci di changelog non dovrebbero essere usatiper discutere con chi ha riportato bug (“I
don’t see segfaultswhen starting foo with option bar; send in more info”), frasigeneriche sulla vita, l’universo e altro (“sorry this uploadtook me so long, but I caught the flu”), oppure
chiedere aiuto(“the bug list on this package is huge, please lend me a hand”).Queste cose generalmente non saranno notate da chi vorrestiraggiungere, ma potrebbe irritare persone che
desiderano leggereinformazioni circa le modifiche reali apportate al pacchetto.Vedi ‘Rispondere ai bug’ a pagina 42 per ulteriori informazioni su comeusare il sistema di tracciamento dei
bug.
67
È tradizione riconoscere i bug risolti tramite non-mantainer upload nella prima voce
dichangelog dell’upload del mantainer, per esempio, in una voce comequesta:
* Maintainer upload, closes: #42345, #44484, #42444.
Questo chiuderà i bug NMU marcati “fixed” quando il pacchettoentrerà in archivio. Nello
stesso modo è possibile chiudere bugriportati perchè è stato fatto un NMU. Certamente è anche
perfettamenteaccettabile chiudere bug risolti da NMU in altri modi; vedi ‘Rispondere ai bug’
a pagina 42.
6.3.3
Errori comuni nelle voci di changelog
Gli esempi seguenti mostrano degli errori comuni o esempi di cattivostile nelle voci di
changelog.
* Fixed all outstanding bugs.
Questo ovviamente non dice agli utenti nulla di utile.
* Applied patch from Jane Random.
Cosa faceva la patch?
* Late night install target overhaul.
Revisione (Overhaul) che ha portato a cosa? Il menzionare latarda notte dovrebbe ricordarci
che non dovremmo fidarci delcodice?
* Fix vsync FU w/ ancient CRTs.
Troppi acronimi, e non è ben chiaro a cosa ci si riferisce,o come è stato aggiustato.
* This is not a bug, closes: #nnnnnn.
Prima di tutto non c’è assolutamente bisogno di fare un uploaddel pacchetto per dare questa informazione; usa invece il sistemadi tracciamento dei bug. Inoltre, non c’è nessuna spiegazione
sulperchè il report non è un bug.
* Has been fixed for ages, but I forgot to close; closes: #54321.
68
Se per qualche ragione non hai menzionato il numero del bug in una precedentevoce di changelog, non c’è alcun problema, chiudi semplicemente il bugnormalmente tramite il BTS. Non
c’è bisogno di toccare il file di changelog,assumendo che la descrizione del fix sia già dentro (questo si applica ancheai fix dagli autori/mantainer originali, non devi tenere traccia nel
tuochangelog dei bug risolti secoli fa).
* Closes: #12345, #12346, #15432
Dov’è la descrizione? Se non riesci a pensare a un messaggio esplicativo,comincia inserendo il
titolo di ogni diverso bug.
6.4
Procedimenti consigliati per gli script del mantainer
Gli script del mantainer includono i file debian/postinst,debian/preinst, debian
/prerm edebian/postrm. Questi script si prendono cura di ogniimpostazione di installazione o rimozione del pacchetto che non ègestita dalla semplice creazione o cancellazione di file edirectory. Le seguenti informazioni sono un supplemento della Policy Debian
(http://www.debian.org/doc/debian-policy/).
Gli script del mantainer devono essere idempotenti. Ciò significache devi assicurarti che non
capiti nulla di male se lo script vienechiamato due volte quando normalmente dovrebbe essere
chiamato unavolta sola.
Lo standard input e lo standard output possono essere rediretti(p.es. in pipe) a scopo di
logging, quindi non basarti sul fattoche siano delle tty.
Tutti i prompt o configurazioni interattive dovrebbero essere tenutial minimo indispensabile.
Quando è necessario, dovresti usare ilpacchetto debconf per l’interfaccia. In ogni casoricorda
che puoi presentare dei prompt solo nella fase configuredello script postinst.
Tieni gli script del mantainer più semplici possibili. Ti consigliamo diusare script shell POSIX
puri. Ricordati che se hai bisogno di qualisasifunzionalità bash, lo script deve avere una linea bash sh-bang. ShellPOSIX o bash sono preferiti al perl, siccome abilitanodebhelper ad
aggiungere facilmente dei pezzi agli script.
Se modifichi gli script del mantainer, assicurati di testare la rimozionedel pacchetto, la duplice
installazione e il purge. Assicurati che unpacchetto di cui è stato fatto il purge sia completamente sparito, ilche significa che deve rimuovere qualunque file direttamente oindirettamente
creato in qualsiasi script del mantainer.
Se hai la necessità di controllare l’esistenza di un comando, dovrestiusare qualcosa come
if [ -x /usr/sbin/install-docs ]; then ...
Se non vuoi codificare inflessibilmentela path del comando nel tuo script del mantainer, la
seguente funzioneconforme allo standard POSIX può essere d’aiuto:
69
pathfind() {
OLDIFS="$IFS"
IFS=:
for p in $PATH; do
if [ -x "$p/$*" ]; then
IFS="$OLDIFS"
return 0
fi
done
IFS="$OLDIFS"
return 1
}
Puoi usare questa funzione per cercare la $PATH per il nomedi un comando, passato come argomento. Ritorna true (zero) se il comandoè stato trovato, altrimenti false. Questo è veramente
il modo piùportabile, in quanto command -v, type, ewhich non sono POSIX.
Anche se which è un’alternativa accettabile, essendo provenientedal pacchetto richiesto
debianutils, non risiede nellapartizione di root. In effetti, è in /usr/bin invece che in
/bin, quindi non si può usare in script che sono lanciati primache la partizione /usr sia
montata. Comunque, la maggior partedegli script non avranno questo problema.
6.5
Gestione della configurazione con debconf
Debconf è un sistema di gestione della configurazione chepuò essere usato da tutti i vari
script di pacchettizzazione (principalmentepostinst) per richiedere un feedback dall’utente
che concernecome configurare il pacchetto. Interazioni dirette con l’utente ora devonoessere
evitate in favore di interazioni tramite debconf.Ciò in futuro permetterà installazioni non
interattive.
Debconf è un grande strumento ma spesso è usato in modo povero. Molti erroricomuni sono
elencati nella pagina di manualedebconf-devel(7). È qualcosa che devi necessariamente
leggere se decidi di usare debconf.
6.6
6.6.1
Internazionalizzazione
Gestire le traduzioni di debconf
Come i porter, i traduttori hanno un compito difficile. Lavorano sutanti pacchetti e devono collaborare con molti diversi mantainer.Inoltre, la maggior parte delle volte non parlano
nativamente l’inglesequindi potresti dover essere particolarmente paziente con loro.
Lo scopo di debconf era di rendere la configurazionedi pacchetti più facile sia per i mantainer che per gli utenti.Originalmente, la traduzione dei template di debconf era gestita
70
condebconf-mergetemplate. Quella tecnica è comunque oramaideprecata; il modo migliore di realizzare l’internazionalizzazione didebconf è quello di usare il pacchettopo-debconf.
Questo metodo è più semplice sia peri mantainer che per i traduttori; vengono forniti degli
script ditransizione.
Usando po-debconf, la traduzione è tenuta in filepo (presi dalle tecniche di traduzione di gettext).File template speciali contengono i messaggi originali e segnano qualimessaggi sono traducibili. Quando cambi il valore di un campotraducibile, lanciando
debconf-updatepo, la traduzione èmarcata che necessita attenzione dai traduttori. Quindi, al tempo dieffettuare il build, il programma dh_installdebconfsi prende cura di tutte
le magie necessarie per aggiungere la templatecon le traduzioni aggiornate nei pacchetti binari.
Per i dettagli, ilriferimento è la pagina di manuale po-debconf(7).
6.6.2
Documentazione internazionalizzata.
L’internazionalizzazione della documentazione è cruciale per gli utenti,ma richiede molto lavoro. Non c’è modo di eliminare tutto quel lavoro, mapuoi rendere le cose più facili ai
traduttori.
Se mantieni della documentazione di qualsiasi dimensione, è più facileper i traduttori se hanno accesso a un sistema di controllo dei sorgenti.Ciò permette ai traduttori di vedere la differenza tra due versioni delladocumentazione, quindi, per esempio, possono vedere cosa ha bisogno diessere nuovamente tradotto.
È raccomandato che la documentazionetradotta mantenga una nota circa su quale revisione del
controllo deisorgenti si basa la traduzione.
Un sistema interessante è fornito da
doc-check (http://cvs.debian.org/boot-floppies/documentation/doc-check?
rev=HEADcontent-type=text/vnd.viewcvs-markup) nel pacchetto boot-floppies,
il quale mostra una vista d’insiemedello stato della traduzione per ogni data lingua, usando
commentistrutturati per la revisione corrente del file che deve essere tradotto e,per un file tradotto, la revisione del file originale su cui è basata latraduzione. Potresti volere adattare e
fornire tutto questo nella tuaarea CVS.
Se mantieni documentazione XML o SGML, ti suggeriamo di isolare qualsiasiinformazione
indipendente dal linguaggio e definirle come entità in unfile separato che è incluso da tutte le
diverse traduzioni. Questo rendemolto più facile per esempio tenere gli URL aggiornati in più
file.
6.7
6.7.1
Situazioni comuni di pacchettizzazione
Pacchetti che usano autoconf/automake
Tenere aggiornati i file di autoconf config.sub econfig.guess è critico per i porter, specialmente per learchitetture più volatili. Qualche procedimento di pacchettizzazione moltobuono per qualunque pacchetto che usa autoconf e/oautomake sono stati sintetizzati in
/usr/share/doc/autotools-dev/README.Debian.gznel pacchetto autotools-dev.
Sei fortemente incoraggiatoa leggere questo file e a seguire le raccomandazioni fornite.
6.7.2
71
Librerie
Le librerie sono sempre difficili da pacchettizzare per svariate ragioni.La policy impone molte
restrizioni per facilitare la loro manutenzionee per assicurare che gli aggiornamenti vengano effettuati più facilmentepossibile quando una nuova versione upstream viene rilasciata.Un
malfunzionamento in una libreria può provocare il malfunzionamento didozzine di pacchetti
dipendenti.
I procedimenti consigliati per la pacchettizzazione delle libreriesono stati raggruppati ne
la guida della pacchettizazione delle librerie (http://www.netfort.gr.jp/~dancer/
column/libpkg-guide/).
6.7.3
Documentazione
Assicurati di seguire la Policy sulla documentazione (http://www.debian.org/doc/
debian-policy/ch-docs.html).
Se il tuo pacchetto contiene documentazione costruita da XML oSGML, ti raccomandiamo di
non fornire i sorgenti XML o SGML nel o neipacchetti binari. Se gli utenti vogliono i sorgenti
della documentazione,dovrebbero procurarsi il pacchetto sorgente.
La policy specifica che la documentazione dovrebbe essere fornita informato HTML. Noi raccomandiamo anche di fornire documentazione neiformati PDF e puro testo se conveniente e se è possibile ottenereoutput di qualità. Comunque, generalmente non è appropriato
fornireversioni in testo puro di documentazione la cui sorgente è in formatoHTML.
I manuali forniti più importanti dovrebbero registrarsi adoc-base durante l’installazione.
Vedila documentazione del pacchetto doc-baseper ulteriori informazioni.
6.7.4
Tipologie specifiche di pacchetti
Un discreto numero di tipologie specifiche di pacchetti hanno dellesotto-policy speciali e
corrispondenti regole e procedimenti dipacchettizzazione:
• Pacchetti correlati al perl hanno una policy perl (http://www.debian.org/doc/
packaging-manuals/perl-policy/), qualche esempio di pacchetti che seguonotale
policy sono libdbd-pg-perl (modulo perl binario) olibmldbm-perl (modulo perl
indipendente dall’architettura).
• Pacchetti correlati al python hanno la loro policy python; vedi/usr/share/doc
/python/python-policy.txt.gz nel pacchetto python.
• Pacchetti correlati a emacs hanno la policy emacs (http://www.debian.org/doc/
packaging-manuals/debian-emacs-policy).
• Pacchetti correlati a java hanno la loro policy java (http://www.debian.org/doc/
packaging-manuals/java-policy/).
72
• Pacchetti correlati a ocaml hanno la loro policy, situata in/usr/share/doc/ocaml
/ocaml_packaging_policy.gz nel pacchetto ocaml. Un buonesempio è il pacchetto
sorgente camlzip.
• Pacchetti che forniscono DTD XML o SGML dovrebbero conformarsi alleraccomendazioni nel pacchetto sgml-base-doc.
• Pacchetti lisp dovrebbero registrarsi acommon-lisp-controller, circa il quale vedi
/usr/share/doc/common-lisp-controller/README.packaging.
6.7.5
Dati indipendenti dall’architettura
Non è raro avere un gran numero di dati indipendenti dall’architetturapacchettizati insieme
a un programma. Per esempio, file audio, unacollezione di icone, pattern di sfondo, o altri
file grafici. Se ladimensione di tali dati è trascurabile rispetto alla dimensione delresto del
pacchetto, è probabilmente meglio tenere tutto in un singolopacchetto.
Comunque, se la dimensione dei dati è considerevole, considera lapossibilità di dividerli in
un pacchetto separato e indipendentedall’architettura (“_all.deb”). Facendo questo, eviti un’inutileduplicazione degli stessi dati in undici o più .deb, uno per ogniarchitettura. Mentre ciò
aggiunge un po’ di overhead extra nei filePackages, salva un bel po’ di spazio sui mirror
Debian.Separare i dati indipendenti dall’architettura riduce inoltre il tempodi lavorazione di
lintian o linda (vedi‘Package lint tools’ a pagina 80) quando lanciati sull’intero archivio
Debian.
73
Capitolo 7
Oltre la pacchettizzazione
Debian è molto di più che la semplice pacchettizzazione di sofwaree la manutenzione di tali pacchetti. Questo capitolo contieneinformazioni circa i modi, spesso decisamente critici,
dicontribuire a Debian oltre la semplice creazione e manutenzionedi pacchetti.
Essendo un’organizzazione di volontari, Debian si basa sulladiscrezione dei propri membri
nella scelta di su che cosa voglionolavorare e nella scelta delle cose più importanti sulle quali
impiegareil proprio tempo.
7.1
Riportare bug
Ti incoraggiamo a mandare bug appena ne trovi nei pacchetti Debian.In effetti, gli sviluppatori
Debian sono spesso la prima linea deitester. Trovare e riportare bug nei pacchetti degli altri
svilupatorifa progredire la qualità di Debian.
Leggi le instruzioni per riportare bug (http://www.debian.org/Bugs/Reporting)nel
sistema di tracciamento dei bug (http://www.debian.org/Bugs/) di Debian.
Prova a riportare il bug da un account di utente normale dal qualeti aspetti di ricevere posta,
in modo che la gente possa raggiungertise hanno bisogno di ulteriori informazioni circa il bug.
Noninviare bug come root.
Puoi usare uno strumento come reportbug(1) perriportare bug. Esso può automatizzare e
generalmente facilitare il processo.
Assicurati che il bug non sia già stato riportato a un pacchetto.Ogni
pacchetto
ha
una
lista
di
bug
facilmente
raggiungibile
all’indirizzohttp://bugs.debian.org/packagename.Utility come querybts(1) possono inoltrefornire tale informazione (e anche reportbug di solitoinvocherà querybts prima di
inviare).
Cerca di inviare i tuoi bug nel posto giusto. Quando per esempio iltuo bug riguarda un pacchetto che sovrascrive file di un altro pacchetto,controlla la lista dei bug di entrambi i pacchetti
in modo daevitare di archiviare bug report doppi.
Capitolo 7. Oltre la pacchettizzazione
74
Come extra , puoi scorrere altri pacchetti,fondendo bug che sono stati riportati più di una volta,
o marcandoi bug come ‘fixed’ quando sono già stati risolti. Nota che quandonon sei né chi ha
riportato il bug né il mantainer del pacchetto,non dovresti chiudere il bug (a meno che non hai
il permesso delmantainer).
Ogni tanto puoi voler controllare cosa è successo al bug reportche hai inviato. Cogli questa
opportunità per chiudere i bug chenon puoi più riprodurre. Per cercare tutti i bug che hai
riportato,devi solo visitare http://bugs.debian.org/from:<your-email-addr>.
7.1.1
Riportare un gran numero di bug in una volta sola
Riportare un grande numero di bug per lo stesso problema su ungran numero di pacchetti
differenti — p.es., più di 10 —è un apratica deprecata. Fai tutto il possibile per evitare del tuttobug in massa. Per esempio, se il controllo per il problema può essereautomatizzato, aggiungi
un nuovo controllo a lintianin modo che venga emesso un errore o un avvertimento.
Se riporti più di 10 bug in una volta sola sullo stesso argomento,è raccomandato mandare
un messaggio a <[email protected]> descrivendola tue intenzioni prima
di inviare il report. Questo permetterà aglialtri sviluppatori di verificare che il bug sia un
problema reale.In aggiunta, aiuterà prevenire una situazione in cui diversi mantainerinizino a
inviare lo stesso bug report simultaneamente.
Nota che quando mandi molti bug sullo stesso soggetto, dovresti inviareil bug report a
<[email protected]> in modo che ilreport non venga inoltrato alla mailing list
di distribuzione del bug.
7.2
7.2.1
Opere di assicurazione qualità
Lavori giornalieri
Anche se esiste un gruppo di persone dedicato all’assicurazionequalità, i doveri di QA non
sono riservati a loro. Puoi perteciparein questo lavoro tenendo i tuoi pacchetti il più possibile
liberida bug, e più “puliti” possibile per lintian (vedi ‘lintian’ a pagina 80).Se trovi che non
sia possibile, allora dovresti considere l’opportunitàdi abbandonare (orphaning) qualcuno dei
tuoi pacchetti (vedi ‘Abbandonare un pacchetto’ a pagina 50). Alternativamente puoi chiedere
l’aiuto di altre personein modo da risolvere tutti i tuoi bug che hai in arretrato(puoi chiedere
aiuto su <[email protected]> oppure <[email protected].
org>).Allo stesso tempo, puoi cercare dei co-mantainer (vedi‘Manutenzione collaborativa’ a
pagina 60).
7.2.2
Bug squashing party
Ogni tanto il gruppo QA organizza dei bug squashing party per eliminarepiù problemi possibile. Sono annunciati su <[email protected]>e l’annuncio
75
spiega su quale area ci si concentrerà durante il party:generalmente si concentrano su bug release critical ma può succedere chedecidino di aiutare a finire un’importante aggiornamento in
corso d’opera(come una nuova versione del perl che richiede la ricompilazione di tuttii moduli
binari).
Le regole per i non-mantainer upload differiscono durante i party inquanto l’annuncio del
party è considerato come un annuncio preventivoper i NMU. Se hai pacchetti che possono
essere affetti dal party (perchèper esempio hanno bug release critical), dovresti mandare un
update aognuno dei bug corrispondenti per spiegare il loro stato corrente e cosati aspetti dal
party. Se non vuoi un NMU, o se sei interessato solo auna patch, o se ti occuperai da solo del
bug, per piacere spiegalo nelBTS.
Le persone che partecipano al party hanno regole speciali per gli NMU,essi possono effettuare
dei NMU senza prima avvertire se inviano i loroNMU almeno in DELAYED/3-day. Tutti le
altre regole sui NMU si applicanocome al solito, essi dovrebbero inviare la patch del NMU
al BTS (in unodei bug aperti risolti dal NMU o in un nuovo bug marcato come fixed).Essi
dovrebbero inoltre rispettare le volontà del mantainer se egli neha espresso qualcuna.
Se qualcuno non si sente tranquillo con unNMU, egli dovrebbe semplicemente mandare una
patch al BTS. È moltomeglio che un NMU sbagliato.
7.3
Contattare altri mantainer
Durante la tua vita in Debian, avrai bisogno di contattare altrimantainer per varie ragioni. Potresti voler discutere un nuovomodo di cooperare tra un insieme di pacchetti correlati, oppurepotresti semplicemente ricordare a qualcuno che è disponibile unanuova versione upstream
di cui hai bisogno.
Cercare l’indirizzo email del mantainer del pacchetto può distrarti.Fortunatamente esiste un
semplice alias,<package>@packages.debian.org, che fornisce un modo perinviare email
al mantainer, qualunque sia il suo (o i loro) indirizzoemail. Sostituisci <package> con il nome
di un pacchettobinario o sorgente.
Potresti anche essere interessato a contattare le persone che sonosottoscritte a un dato pacchetto
sorgente attraverso‘Il sistema di tracciamento dei pacchetti’ a pagina 26. Puoi farlo usando
l’indirizzo email<package-name>@packages.qa.debian.org.
7.4
Trattare con mantainer inattivi e/o irraggiungibili
Se noti che un pacchetto abbia carenze di manutenzione, dovrestiassicurarti che il mantainer
sia attivo e continuerà a lavorare aisuoi pacchetti. È possibile che non siano più attivi ma nonsi
siano deregistrati dal sistema, tanto per dire. Dall’altro lato,è anche possibile che abbiano solo
bisogno di un promemoria.
Il primo passo è contattare educatamente il mantainer e aspettare unarisposta per un tempo
ragionevole. È abbastanza difficile definireun “tempo ragionevole”, ma è importante tenere
76
conto che la vita realeè a volte molto movimentata. Un modo di gestire questa situazione
sarebbemandare un promemoria dopo due settimane.
Se il mantainer non risponde entro quattro settimane (un mese), sipuò presumere che probabilmente non si riceverà mai una risposta.Se questo accade, dovresti investigare ulteriormente
e cercare di ottenerepiù informazioni utili possibili sul mantainer in questione. Ciò include:
• Le informazioni modello “echelon” disponibili attraverso il database LDAP degli svilupaptori (https://db.debian.org/), il quale indica quando è stata l’ultima volta
che uno sviluppatore abbia inviato qualcosa a una mailing-list Debian. (Questo include
gli upload attraverso la lista debian-*-changes lists.) Inoltre, ricordati di controllare se il
mantainer sia marcato “on vacation” nel database.
• Il numero di pacchetti di cui è responsabile questo mantainer, e le condizioni di quei
pacchetti. In particolare, ci sono dei bug RC che sono stati aperti per un sacco di tempo?
Inoltre, quanti bug ci sono in generale? Un’altra informazione importante è se i pacchetti
siano stati o meno soggetti a NMU, e se è così, da chi.
• Esiste quasisasi attività del mantainer fuori da Debian? Per esempio, potrebbe avere
recentemente postato qualcosa a mailing list non Debian o newsgroup.
Un problema grosso sono i pacchetti che sono stati sponsorizzati – ilmantainer non è uno sviluppatore Debian ufficiale. Le informazioni modello“echelon” non sono disponibili per gente
sponsorizzata, per esempio, quindihai bisogno di trovare e contattare lo sviluppatore Debian
che ha realmenteinviato il pacchetto in upload. Dato che hanno firmato il pacchetto, essisono responsabili comunque per l’upload, e dovrebbero sapere cosa è successoalla persona che
hanno sponsorizzato.
È anche permesso di inviare una richiesta a <[email protected].
org>,chedendo se qualcuno ha notizie del mantainer scomparso.
Una volta che hai ottenuto tutto ciò, puoi contattare <[email protected]>.La
gente in questo alias userà le informazioni che hai fornito in modo dadecidere sul da farsi.
Per esempio, potrebbero abbandonare (orphaning)uno o tutti i pacchetti del mantainer. Se un
pacchetto è stato oggetto diNMU, potrebbero preferire contattare chi ha inviato il NMU prima
diabbandonare il pacchetto – forse tale persona è interessata al pacchetto.
Un’ultima parola: per favore ricordati di essere educato. Noi siamo tuttivolontari e non possiamo dedicare tutto il nostro tempo a Debian. Inoltre,non sei a conoscenza delle circostanze
in cui si trova la persona coinvolta.Forse porebbero essere gravemente malati o perfino morti –
non sai chipotrebbe essere dalla parte ricevente – immagina come si potrebbe sentireun parente
se legge le e-mail del defunto e trova un messaggio molto scortese,arrabbiato e accusatorio!)
Dall’altro lato, anche se siamo volontari, abbiamo delle responsabilità.So you can stress the
importance of the greater good– se un mantainer non ha più il tempo o l’interesse, dovrebbe
“lasciarandare” e dare il pacchetto a qualcuno con più tempo.
7.5
77
Interazione con futuri sviluppatori Debian
Il successo di Debian dipende dalla sua abilità di attrarre e tenerenuovi volontari di talento. Se
sei un mantainer con una certa esperienza,ti raccomandiamo di coinvolgerti nel processo di far
entrare nuovisviluppatori. Questa sezione descrive come aiutare i nuovi futurisviluppatori.
7.5.1
Sponsorizzare pacchetti
Sponsorizzare un pacchetto significa fare l’upload di un pacchetto per unmantainer che non
può farlo da solo, un aspirante mantainer. Sponsorizzareun pacchetto significa anche accettare
la responsabilità di esso.
Se desideri diventare uno sponsor volontario, puoi iscrivertiall’indirizzo http://www.
internatif.org/bortzmeyer/debian/sponsor/.
I nuovi mantainer di solito hanno certe difficoltà a creare pacchetti Debian— ciò è abbastanza comprensibile. Questo è il perchè dell’esistenzadello sponsor, per controllare il pacchetto e
verificare che sia buonoabbastanza per l’inclusione in Debian. (Nota che se il pacchetto sponsorizzatoè nuovo, anche gli ftpmaster dovranno ispezionarlo prima di permetterglidi entrare
in arachivio.)
Sponsorizzare semplicemente firmando l’upload o solo ricompilandolo èdefinitivamente non
raccomandato. Devi effettuare ilbuild del pacchetto sorgente proprio come faresti con un
pacchetto tuo.Ricorda che non importa se hai lasciato il nome del futuro sviluppatoresia nel
changelog che nel file control, l’upload può comunque esserericondotto a te.
Se sei un aspirante manager per un futuro sviluppatore, puoi anche essereil suo sponsor. In
quel modo puoi anche verificare come l’aspirante stagestendo la parte ’Tasks and Skills’ della
sua richiesta.
7.5.2
Gestire i pacchetti sponsorizzati
Inviando in upload a Debian un pacchetto sponsorizzato, stai certificandoche il pacchetto si
attiene agli standard minimi di Debian. Ciò implicache devi fare il build e testare il pacchetto
sul tuo sistema prima dieffettuare l’upload.
Non puoi semplicemente inviare in upload un .deb binariodallo sponsorizzato. In teoria, dovresti solo chiedere il file diff ela locazione della tarball sorgente originaria, quindi scaricare
isorgenti e applicare te stesso la diff. In pratica, potresti volerusare il pacchetto sorgente costruito dal tuo sponsorizzato. In quel caso,devi controllare che non ha alterato i file upstream
nel file.orig.tar.gz che fornisce.
Non aver paura di scrivere allo sponsorizzato e delineare lemodifiche che devono essere
fatte. Spesso ci vogliono diverseemail avanti e indietro prima che il pacchetto sia in una
formaaccettabile. Essere uno sponsor significa essere un mentore.
Una volta che il pacchetto incontra gli standard Debian, fanne ilbuild e firmalo con
78
dpkg-buildpackage -kKEY-ID
prima diinviarlo in upload alla directory incoming.
Il campo Mantainer dei file control echangelog dovrebbero elencare le persona che hanno fattoil pacchetto, ovvero lo sponsorizzato. Egli quindi riceverà tutte leemail del BTS sul
pacchetto.
Se preferisci lasciare una traccia più evidente del tuo lavoro disponsorizzazione, puoi
aggiungere una linea che lo esplicita nellavoce più recente di changelog.
Sei incoraggiato a tenere i contatti con il pacchetto che sponsorizziusando ‘Il sistema di
tracciamento dei pacchetti’ a pagina 26.
7.5.3
Advocating new developers
See the page about advocating a prospective developer (http://www.debian.org/devel/
join/nm-advocate) at the Debian web site.
7.5.4
Handling new maintainer applications
Please see Checklist forApplication Managers (http://www.debian.org/devel/join/
nm-amchecklist) at the Debian web site.
79
Appendice A
Overview of Debian Maintainer Tools
This section contains a rough overview of the tools available tomaintainers. The following is
by no means complete or definitive, butjust 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 morethan one way to do it.
Some people prefer to use high-level package maintenance tools andsome do not. Debian is
officially agnostic on this issue; any toolwhich gets the job done is fine. Therefore, this section is
not meantto stipulate to anyone which tools they should use or how they shouldgo about with
their duties of maintainership. Nor is it meant toendorse any particular tool to the exclusion
of a competing tool.
Most of the descriptions of these packages come from the actualpackage descriptions themselves. Further information can be found inthe package documentation itself. You can also see
more info with thecommand apt-cache show <package-name>.
A.1
Core tools
The following tools are pretty much required for any maintainer.
A.1.1
dpkg-dev
dpkg-dev contains the tools (includingdpkg-source) required to unpack, build and upload
Debiansource packages. These utilities contain the fundamental, low-levelfunctionality required to create and manipulated packages; as such,they are required for any Debian
maintainer.
Capitolo A. Overview of Debian Maintainer Tools
A.1.2
80
debconf
debconf provides a consistent interface toconfiguring packages interactively. It is user interfaceindependent, allowing end-users to configure packages with atext-only interface, an HTML
interface, or a dialog interface. Newinterfaces can be added modularly.
You can find documentation for this package in thedebconf-doc package.
Many feel that this system should be used for all packages requiringinteractive configuration; see ‘Gestione della configurazione con debconf’ a pagina 69.debconf is not currently
required by Debian Policy,but that may change in the future.
A.1.3
fakeroot
fakeroot simulates root privileges. This enablesyou to build packages without being root
(packages usually want toinstall files with root ownership). If you havefakeroot installed,
you can build packages as auser: dpkg-buildpackage -rfakeroot.
A.2
Package lint tools
According to the Free On-line Dictionary of Computing (FOLDOC), ‘lint’is “a Unix C language processor which carries out more thorough checkson the code than is usual with C compilers.” Package lint tools helppackage maintainers by automatically finding common problems
andpolicy violations with their packages.
A.2.1
lintian
lintian dissects Debian packages and emitsinformation on bugsand policy violations. It contains automated checks for many aspectsof Debian policy as well as some checks for common
errors.
You should periodically get the newest lintian from‘unstable’ and check over all your packages. Notice that the -ioption 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 ‘Controllare il pacchetto’ a pagina 34 for more information on how and whento use
Lintian.
You can also see a summary of all problems reported by Lintian on yourpackages at http:
//lintian.debian.org/. Those reports contain the latestlintian output on the whole
development distribution(“unstable”).
A.2.2
linda
linda is another package linter. It is similar tolintian but has a different set of checks.
Itswritten in Python rather than Perl.
A.2.3
81
debdiff
debdiff (from the devscripts package, ‘devscripts’ a pagina 84)compares file lists and
control files of two packages. It is a simpleregression test, as it will help you notice if the
number of binarypackages has changed since the last upload, or if something’s changedin the
control file. Of course, some of the changes it reports will beall right, but it can help you
prevent various accidents.
You can run it over a pair of binary packages:
debdiff package_1-1_arch.deb package_2-1_arch.deb
Or even a pair of changes files:
debdiff package_1-1_arch.changes package_2-1_arch.changes
For more information please see debdiff(1).
A.3
Helpers for debian/rules
Package building tools make the process of writingdebian/rules files easier. See ‘Script
helper’ a pagina 61for more information on why these might or might not be desired.
A.3.1
debhelper
debhelper is a collection of programs that can beused in debian/rules to automate common tasks related tobuilding binary Debian packages. Programs are included to installvarious
files into your package, compress files, fix file permissions,integrate your package with the
Debian menu system.
Unlike some approaches, debhelper is broken intoseveral small, granular commands which
act in a consistent manner. Assuch, it allows a greater granularity of control than some of
theother “debian/rules tools”.
There are a number of little debhelper add-onpackages, too transient to document. You can
see the list of most ofthem by doing apt-cache search ^dh-.
A.3.2
debmake
debmake, a pre-cursor todebhelper, is a less granulardebian/rules assistant. It includes
two main programs:deb-make, which can be used to help a maintainer converta regular (nonDebian) source archive into a Debian source package;and debstd, which incorporates in one
big shot the samesort of automated functions that one finds indebhelper.
The consensus is that debmake is now deprecated infavor of debhelper. However, it’s not a
bug to usedebmake.
A.3.3
82
dh-make
The dh-make package contains dh_make, a program thatcreates a skeleton of files necessary
to build a Debian package out ofa source tree. As the name suggests, dh_make is a rewrite
ofdebmake and its template files use dh_* programs fromdebhelper.
While the rules files generated by dh_make are in general asufficient basis for a working package, they are still just the groundwork:the burden still lies on the maintainer to finely tune the
generated filesand make the package entirely functional and Policy-compliant.
A.3.4
yada
yada is another packaging helper tool.
It uses adebian/packages file to autogeneratedebian/rules and other necessary files in thedebian/ subdirectory.
Note that yada is called “essentially unmaintained”by it’s own maintainer, Charles BriscoeSmith. As such, it can beconsidered deprecated.
A.3.5
equivs
equivs is another package for making packages. Itis often suggested for local use if you
need to make a package simplyto fulfill dependencies. It is also sometimes used when
making“meta-packages”, which are packages whose only purpose is to dependon other
packages.
A.4
Package builders
The following packages help with the package building process,
dpkg-buildpackage as well as handling supportingtasks.
A.4.1
generaldriving
cvs-buildpackage
cvs-buildpackage provides the capability to injector import Debian source packages into
a CVS repository, build a Debianpackage from the CVS repository, and helps in integrating
upstreamchanges into the repository.
These utilities provide an infrastructure to facilitate the use of CVSby Debian maintainers. This allows one to keep separate CVS branchesof a package for stable, unstable and
possiblyexperimental distributions, along with the other benefits ofa version control system.
A.4.2
83
debootstrap
The debootstrap 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
tooperate and install the rest of the system.
Having a system like this can be useful in many ways. For instance,you can chroot into it
if you want to test your builddepends. Or, you can test how your package behaves when
installedinto a bare base system. Chroot builders use this package, see below.
A.4.3
pbuilder
pbuilder constructs a chrooted system, and builds apackage inside the chroot. It is very
useful to check that a package’sbuild-dependencies are correct, and to be sure that unnecessary
andwrong build dependencies will not exist in the resulting package.
A related package is pbuilder-uml, which goes evenfurther build doing the build within
User-mode-linux.
A.4.4
sbuild
sbuild is another automated builder. It can usechrooted environments as well. It can be used
stand-alone, or as partof a networked, distributed build environment. As the latter, it ispart
of the system used by porters to build binary packages for allthe available architectures. See
‘buildd’ a pagina 55 for moreinformation, and http://buildd.debian.org/ to see the
system inaction.
A.5
Package uploaders
The following packages help automate or simplify the process ofuploading packages into the
official archive.
A.5.1
dupload
dupload is a package and a script to automaticallyupload Debian packages to the Debian
archive, to log the upload, andto send mail about the upload of a package. You can configure
it fornew upload locations or methods.
A.5.2
dput
The dput package and script does much the samething as dupload, but in a different way.
It hassome features over dupload, such as the ability tocheck the GnuPG signature and
84
checksums before uploading, and thepossibility of running dinstall in dry-run mode after
theupload.
A.6
Maintenance automation
The following tools help automate different maintenance tasks, fromadding changelog entries
or signature lines, looking up bugs in Emacs,to making use of the newest and official use
ofconfig.sub.
A.6.1
devscripts
devscripts is a package containing wrappersand tools which are very helpful for maintaining your Debianpackages. Example scripts include debchange anddch, which manipulate your debian/changelogfile from the command-line, and debuild, which is awrapper
around dpkg-buildpackage. The btsutility is also very helpful to update the state of bug
reports on thecommand line. uscan can be used to watch for new upstreamversions of your
packages. The debrsign can be used toremotely sign a package prior to upload, which is nice
when themachine you build the package on is different from where your GPG keysare.
See the devscripts(1) manual page for acomplete list of available scripts.
A.6.2
autotools-dev
Contains best practices for people maintaining packages that useautoconf and/or
automake. Also containscanonical config.sub and config.guess fileswhich are known
to work on all Debian ports.
A.6.3
dpkg-repack
dpkg-repack creates Debian package file out of a packagethat has already been installed.
If any changes have been made to thepackage while it was unpacked (e.g., files in /etc
weremodified), the new package will inherit the changes.
This utility can make it easy to copy packages from one computer toanother, or to recreate
packages that are installed on your systembut no longer available elsewhere, or to store the
current state of apackage before you upgrade it.
A.6.4
alien
alien converts binary packages between various packagingformats, including Debian, RPM
(RedHat), LSB (Linux Standard Base),Solaris and Slackware packages.
A.6.5
85
debsums
debsums checks installed packages against their MD5 sums.Note that not all packages have
MD5 sums, since they aren’t requiredby Policy.
A.6.6
dpkg-dev-el
dpkg-dev-el is an Emacs lisp package which providesassistance when editing some of the
files in the debiandirectory of your package. For instance, when editingdebian/changelog,
there are handy functions forfinalizing a version and listing the package’s current bugs.
A.6.7
dpkg-depcheck
dpkg-depcheck (from the devscripts package, ‘devscripts’ nella pagina precedente)runs a command under strace to determine all the packages thatwere used by the said
command.
For Debian packages, this is useful when you have to compose aBuild-Depends line for
your new package: running the buildprocess through dpkg-depcheck will provide you with
agood first approximation of the build-dependencies. For example:
dpkg-depcheck -b debian/rules build
dpkg-depcheck can also be used to check for run-timedependencies, especially if your
package uses exec(2) to run otherprograms.
For more information please see dpkg-depcheck(1).
A.7
Porting tools
The following tools are helpful for porters and forcross-compilation.
A.7.1
quinn-diff
quinn-diff is used to locate the differences fromone architecture to another. For instance, it
could tell you whichpackages need to be ported for architecture Y, based onarchitecture X.
A.7.2
dpkg-cross
dpkg-cross is a tool for installing libraries andheaders for cross-compiling in a way similar todpkg. Furthermore, the functionality ofdpkg-buildpackage and dpkg-shlibdeps
isenhanced to support cross-compiling.
A.8
86
Documentation and information
The following packages provide information for maintainers or helpwith building
documentation.
A.8.1
debiandoc-sgml
debiandoc-sgml provides the DebianDoc SGML DTD,which is commonly used for Debian
documentation. This manual, forinstance, is written in DebianDoc. It also provides scripts
forbuilding and styling the source to various output formats.
Documentation for the DTD can be found in thedebiandoc-sgml-doc package.
A.8.2
debian-keyring
Contains the public GPG and PGP keys of Debian developers. See ‘Mantenere la tua chiave
privata’ a pagina 7 and the package documentation for moreinformation.
A.8.3
debview
debview provides an Emacs mode for viewing Debianbinary packages. This lets you examine
a package without unpackingit.

Guida di riferimento per lo sviluppatore Debian

Transcript

Documenti analoghi

Aggiornare debian - micro guida Kijio v.1 2004 Ecco in estrema

Gioca Jouer: centro di ricreazione e divertimento per bambini

presentazoneshell

Debian Security Team

Nuovo repository APT!

Debian - Adunanza

Euro Character Support Mini HOWTO

Slides - LinuxVar

File Server GNU/Linux Debian in Azienda