C'è adesso una nuova sotto-directory nella directory principale del programma (`gentoo-0.9.12'), il cui nome è `debian'. Ci sono un certo numero di file in questa directory che dovremo modificare allo scopo di adattare il comportamento del pacchetto. I più importati fra loro sono `control', `changelog', `copyright' e 'rules', che sono richiesti per tutti i pacchetti.
Questo file contiene vari valori che dpkg
, dselect
e
altri pacchetti useranno per la gestione del pacchetto.
Questo è il file control che dh_make crea per noi.
1 Source: gentoo 2 Section: unknown 3 Priority: optional 4 Maintainer: Josip Rodin <joy-mg@debian.org> 5 Build-Depends: debhelper (>> 3.0.0) 6 Standards-Version: 3.5.2 7 8 Package: gentoo 9 Architecture: any 10 Depends: ${shlibs:Depends} 11 Description: <insert up to 60 chars description> 12 <insert long description, indented with spaces>
(I numeri di riga sono aggiunti).
Le righe 1-6 sono le informazioni di controllo per il pacchetto sorgente.
La riga 1 è il nome del pacchetto sorgente.
La riga 2 è la sezione della distribuzione in cui il pacchetto è incluso.
Come ti sarai reso conto, Debian è diviso in sezioni: main (il software free), non-free (il software non esattamente free) e contrib (software free che dipende da software non free). Al di sotto di queste ci sono delle sotto-sezioni logiche che descrivono in breve di che genere di pacchetto si tratta. Così abbiamo `admin' per programmi da amministratore, `base' per gli strumenti di base, `devel' per gli strumenti per programmatori, `doc' per la documentazione, `libs' per le librerie, `mail' per programmi e demoni di posta elettronica, `net' per applicazioni e demoni di rete, `x11' per programmi specifici per X11, e molte altre.
Modifichiamo quindi la sezione in x11. (Un prefisso "main/" è implicito per cui lo omettiamo.)
La riga 3 descrive quanto sia importante che l'utente installi tale pacchetto. Leggi il manuale della Policy per una guida su come configurare questi campi. La priorità "optional" generalmente funzionerà per nuovi pacchetti.
Sezioni e priorità sono usati effettivamente solo da dselect
dselect quando ordina i pacchetti e seleziona i default. Una volta caricato il
pacchetto in Debian, il valore di questi due campi possono essere modificati
dai maintainer dell'archivio FTP, nel qual caso ne sarai informato via email.
Dal momento che si tratta di un pacchetto a priorità normale, lasciamo il campo al valore "optional".
La riga 4 è nome e e-mail del maintainer. Assicurati che questo campo contenga un campo "To: " valido per una email, perché dopo averlo caricato il sistema di tracciamento delle anomalie lo userà per inviarti le email relativi a errori. Evita l'uso di virgole, '&' e parentesi.
La riga 5 è la versione degli standard di Debian Policy che questo pacchetto segue, la versione del manuale di Policy che leggi mentre costruisci i pacchetti.
La sesta riga include la lista dei pacchetti richiesti per creare il tuo
pacchetto. Alcuni pacchetti come gcc e make sono impliciti, vedi il pacchetto
build-essential
per dettagli. Se qualche compilatore non standard
o altri strumenti sono necessari per compilare il tuo pacchetto, dovresti
aggiungerlo alla riga `Build-Depends'. Valori multipli sono separati con
virgole; leggi più avanti la spiegazione delle dipendenze binarie per saperne
di più della sintassi di questo campo.
Qui puoi anche avere Build-Depends-Indep, Build-Conflicts e altri campi. Questi dati saranno usati dal software di costruzione automatica dei pacchetti per creare pacchetti binari per altre piattaforme di computer. Vedi il manuale della Policy per altre informazioni sulle build-dependencies e la Guida di Riferimento dello Sviluppatore per informazioni su tali piattaforme (architetture) e come portare il software su di esse.
Ecco un trucco che puoi usare per trovare quali pacchetti il tuo pacchetto richiede per la creazione:
strace -f -o /tmp/log ./configure # o make invece di ./configure, se il pacchetto non usa autoconf for x in `dpkg -S $(grep open /tmp/log|\ perl -pe 's!.* open\(\"([^\"]*).*!$1!' |\ grep "^/"| sort | uniq|\ grep -v "^\(/tmp\|/dev\|/proc\)" ) 2>/dev/null|\ cut -f1 -d":"| sort | uniq`; \ do \ echo -n "$x (>=" `dpkg -s $x|grep ^Version|cut -f2 -d":"` "), "; \ done
Per trovare manualmente le esatte dipendenze per la compilazione di
/usr/bin/foo
, esegui
objdump -p /usr/bin/foo | grep NEEDED
e per ogni libreria elencata, per es. libfoo.so.6
, esegui
dpkg -S libfoo.so.6
A questo punto usa la versione -dev di ogni pacchetto come valore di
`Build-deps'. Se usi ldd
a questo scopo, ti verranno indicate
anche tutte le librerie di dipendenza indiretta, col problema di un numero
eccessivo di dipendenze per la compilazione.
Gentoo sembra richiedere xlibs-dev
, libgtk1.2-dev
e
libglib1.2-dev
per compilare, per cui li aggiungiamo dopo
debhelper
.
La riga 8 è il nome del pacchetto binario. Questo è generalmente lo stesso nome del sorgente, ma non deve necessariamente essere così.
La riga 9 descrive l'architettura di CPU per la quale il pacchetto binario è
stato compilato. Possiamo lasciare il valore "any" perché
dpkg-gencontrol(1)
lo riempirà con il valore appropriato per
qualsiasi macchina sulla quale questo pacchetto è stato compilato.
Se il tuo pacchetto è indipendente dalla architettura (per esempio, uno script di shell o Perl, o un documento) modifica questo campo in "all", e leggi oltre in Il file `rules', Sezione 4.4 sull'uso del metodo `binary-indep' invece di `binary-arch' per costruire un pacchetto.
La riga 10 mostra una della più potenti caratteristiche del sistema di pacchettizzazione Debian. I pacchetti possono far riferimento l'uno all'altro in vari modi. Oltre a Depends:, altri campi di relazione sono Recommends:, Suggests:, Pre-Depends:, Conflicts:, Provides:, e Replaces:.
Gli strumenti di gestione dei pacchetti generalmente si comportano nello stesso
modo quando trattano queste relazioni; se così non è, viene spiegato. (vedi
dpkg(8)
, dselect(8)
, apt(8)
,
aptitude(1)
ecc.)
Questo è ciò che le dipendenze significano:
Il pacchetto non sarà installato sino a quando i pacchetti da cui dipende non lo sono. Usa questo valore se il tuo programma non funziona affatto (o causa un serio malfunzionamento) quando un pacchetto particolare non è già presente.
Alcuni frontend come dselect o aptitude ti chiederanno di installare i pacchetti raccomandati, insieme al tuo pacchetto; dselect insisterà nel volerlo fare. Dpkg e apt-get invece, ingnorano questo campo. Usa questo valore per pacchetti che non sono strettamente necessari, ma tipicamente usati con il tuo programma.
Quando un utente installa il tuo programma, tutti i frontend chiedono verosimilmente se devono installare i pacchetti suggeriti. Dpkg e apt-get non se ne curano Usa questo valore per pacchetti che lavorano insieme al tuo programma, ma non sono affatto necessari.
Questo è più stringente di Depends:. Il pacchetto non sarà installato a meno che i pacchetti da cui pre-dipende non siano installati e correttamente configurati. Usa questo valore con molta prudenza, e solo dopo averne discusso nella mailing list debian-devel. Leggi: non usarlo affatto. :-)
Il pacchetto non sarà installato sino a quando tutti i pacchetti con i quali va in conflitto non saranno stati rimossi. Usa questo valore se il tuo programma assolutamente non può girare (o causa un serio danno) se un particolare pacchetto è presente.
Per alcuni tipi di pacchetti dove ci sono alternative multiple sono stati definiti dei nomi virtuali. Puoi trovarne una lista completa nel file /usr/share/doc/debian-policy/virtual-package-names-list.text.gz. Usa questo valore se il tuo programma fornisce una funzione di un pacchetto virtuale esistente .
Usa questo valore quando il tuo programma sostituisce i file di un altro pacchetto o sostituisce completamente un altro pacchetto (usato congiuntamente a Conflicts:). I file dei suddetti pacchetti saranno sostituiti con i file del tuo pacchetto.
Tutti questi campi hanno una sintassi uniforme. Sono una lista di nomi di pacchetti separati da virgole. Questi nomi di pacchetti possono anche essere liste di nomi di pacchetti alternativi, separati da una barra verticale | (simbolo di pipe).
Questi campi possono restringere la propria applicabilità a una particolare versione di ciascun pacchetto. Tali versioni sono elencate in parentesi dopo ogni nome di pacchetto, e dovrebbero contenere una relazione fra le possibili qui in elenco, seguita da un numero di versione. Le relazioni consentite sono: <<, <=, =, >= e >> che stanno per strettamente precedente, precedente o uguale, esattamente uguale, successiva o uguale, e strettamente successiva, rispettivamente. Per esempio,
Depends: foo (>= 1.2), libbar1 (= 1.3.4) Conflicts: baz Recommends: libbaz4 (>> 4.0.7) Suggests: quux Replaces: quux (<< 5), quux-foo (<= 7.6)
L'ultima caratteristica che hai necessità di conoscere è $(shlibs:Depends).
Dopo che il tuo pacchetto sarà stato generato e installato nella directory
temporanea, dh_shlibdeps(1)
lo esaminerà alla ricerca di binari e
librerie, determinerà le dipendenze da librerie condivise e stabilirà in quali
pacchetti queste si trovano, come libc6 o xlib6g. Questo programma passerà la
lista a dh_gencontrol(1)
che li metterà al posto giusto, e tu non
dovrai preoccuparti di specificarle da solo.
Detto ciò possiamo lasciare la riga Depends: come è ora, e inserire un'altra riga dopo questa che dice Suggests: file, perchè gentoo può usare alcune funzionalità offerte da quel programma/pachetto.
La riga 12 è una breve descrizione. Gli schermi di molte persone sono larghi 80 colonne, per cui non dovrebbe essere di più di 60 caratteri. Modificherai tale campo in "fully GUI configurable X file manager using GTK+".
La riga 13 contiene una descrizione estesa. Dovrebbe essere un paragrafo dove vengono dati più dettagli sul pacchetto. La colonna 1 di ogni riga dovrebbe essere vuota. Non ci devono essere righe vuote in mezzo, ma puoi mettere un . (punto) in una colonna, per simularle. Inoltre, non ci deve essere più di una riga vuota dopo la descrizione.
Questo è il file control aggiornato:
1 Source: gentoo 2 Section: x11 3 Priority: optional 4 Maintainer: Josip Rodin <joy-mg@debian.org> 5 Build-Depends: debhelper (>> 3.0.0), xlibs-dev, libgtk1.2-dev, libglib1.2-dev 6 Standards-Version: 3.5.2 7 8 Package: gentoo 9 Architecture: any 10 Depends: ${shlibs:Depends} 11 Suggests: file 12 Description: fully GUI configurable GTK+ file manager 13 gentoo is a file manager for Linux written from scratch in pure C. It 14 uses the GTK+ toolkit for all of its interface needs. gentoo provides 15 100% GUI configurability; no need to edit config files by hand and re- 16 start the program. gentoo supports identifying the type of various 17 files (using extension, regular expressions, or the 'file' command), 18 and can display files of different types with different colors and icons. 19 . 20 gentoo borrows some of its look and feel from the classic Amiga file 21 manager "Directory OPUS" (written by Jonathan Potter).
(Ho aggiunto i numeri di riga.)
Questo file contiene le informazioni sui riferimenti, copyright e licenza del pacchetto upstream. Il suo formato non è dettato dalla Policy, ma i contenuti lo sono (sezioni 13.6 "Informazioni di Copyright").
dh_make ne ha creato uno di default, quello di seguito:
1 This package was debianized by Josip Rodin <joy-mg@debian.org> on 2 Wed, 11 Nov 1998 21:02:14 +0100. 3 4 It was downloaded from <fill in ftp site> 5 6 Upstream Author(s): <put author(s) name and email here> 7 8 Copyright: 9 10 <Must follow here>
(Ho aggiunto i numeri di riga.)
Le cose importanti da aggiungere a questo file sono l'indirizzo da cui il pacchetto è stato preso e l'effettiva nota di copyright e licenza. Devi includere la licenza completa, a meno che non sia una delle comuni licenze di free software, come la GNU GPL o LGPL, la BSD o l'Artistic, nel quale caso puoi semplicemente fare riferimento all'opportuno file in /usr/share/common-licenses/ che esiste su tutti i sistemi Debian.
In breve, ecco come il file copyright di gentoo appare:
1 This package was debianized by Josip Rodin <joy-mg@debian.org> on 2 Wed, 11 Nov 1998 21:02:14 +0100. 3 4 It was downloaded from: ftp://ftp.obsession.se/gentoo/ 5 6 Upstream author: Emil Brink <emil@obsession.se> 7 8 This software is copyright (c) 1998-99 by Emil Brink, Obsession 9 Development. 10 11 You are free to distribute this software under the terms of 12 the GNU General Public License. 13 On Debian systems, the complete text of the GNU General Public 14 License can be found in /usr/share/common-licenses/GPL file.
(Ho aggiunto i numeri di riga.)
Questo è un file obbligatorio, che ha un formato speciale descritto nella Policy alla sezione 4.4 "debian/changelog". Tale formato è usato da dpkg e altri programmi per ricavare il numero di versione, revisione, distribuzione e livello di urgenza del tuo pacchetto.
Per te è ugualmente importante dal momento che è una buona cosa aver documentato tutte le modifiche apportate. Questo aiuterà chi scarica il tuo pacchetto a vedere velocemente se ci sono problemi non risolti con il pacchetto, che dovrebbe sapere. Sarà salvato come `/usr/share/doc/gentoo/changelog.Debian.gz' nel pacchetto binario.
dh_make ne crea uno di default, che appare così:
1 gentoo (0.9.12-1) unstable; urgency=low 2 3 * Initial Release. 4 5 -- Josip Rodin <joy-mg@debian.org> Wed, 11 Nov 1998 21:02:14 +0100 6 7 Local variables: 8 mode: debian-changelog 9 End:
(Ho aggiunto i numeri di riga.)
La riga 1 è il nome del pacchetto, versione, distribuzione e livello di urgenza. Il nome deve corrispondere al nome del pacchetto sorgente, la distribuzione dovrebbe essere `unstable' o `experimental' (per ora), e il livello non dovrebbe essere modificato in qualcosa maggiore di `low'. :-).
Le righe 3-5 sono voci di log, dove documenti le modifiche fatte nella
revisione del pacchetto (non le modifiche di upstream - c'è un file speciale a
tale scopo, creato dall'autore di upstream, installato come
/usr/share/doc/gentoo/changelog.gz). Le nuove righe devono essere inserite
prima della riga più in alto, che inizia con un asterisco (`*'). Puoi farlo
con dch(1)
, emacs(1)
o a mano con un editor di testo.
Devi metterci qualcosa di questo genere:
1 gentoo (0.9.12-1) unstable; urgency=low 2 3 * Initial Release. 4 * This is my first Debian package. 5 * Adjusted the Makefile to fix $DESTDIR problems. 6 7 -- Josip Rodin <joy-mg@debian.org> Wed, 11 Nov 1998 21:02:14 +0100 8
(Ho aggiunto i numeri di riga.)
Puoi leggere altro sull'aggiornamento del file changelog più oltre in Aggiornamento del pacchetto, Capitolo 9.
Ora occorre dare una occhiata alle regole esatte che
dpkg-buildpackage(1)
userà per creare effettivamente il pacchetto.
Questo file è in effetti un altro Makefile, ma diverso da quello dei sorgenti
upstream. Diversamente da altri file in debian/, questo è marcato come
eseguibile.
Tutti i file `rules', come ogni Makefile, consistono di diverse regole che specificano come gestire i sorgenti. Ogni regola consiste di target e nomi di file o nomi di azione che devono essere intraprese (per es. `build:' o `install:'.) Le regole che tu vuoi siano eseguite sono invocate come argomenti a riga di comando (per esempio, `./debian/rules build' o `make -f rules install'.) Dopo il nome del target, puoi fornire i nomi delle dipendenze, il programma o file da cui dipende quella regola. A seguire, ci può essere un qualsiasi numero di comandi (indentati con <tab>!), finché si trova una riga vuota. Da quel punto inizia un'altra regola. Righe vuote multiple e linee che iniziano con `#' (hash) sono trattate come commenti e ignorate
Sarai probabilmente confuso ora, ma sarà tutto più chiaro dopo l'esame del file `rules' che dh_make fornisce come default. Dovresti anche leggere la voce `make' in info per maggiori informazioni.
La cosa importante da capire, a proposito del file rules creato da dh_make, è che si tratta solo di un suggerimento. Funzionerà per semplici pacchetti, ma per i più complicati non avere remore nell'aggiungere o togliere qualcosa ad esso, per accomodarlo alle tue necessità. L'unica cosa che non devi modificare sono i nomi delle regole, perché gli strumenti usano tutti gli stessi nomi, come richiesto dalla Policy.
Ecco (approssimativamente) come appare il file di default debian/rules che dh_make ha generato:
1 #!/usr/bin/make -f 2 # Sample debian/rules that uses debhelper. 3 # GNU copyright 1997 to 1999 by Joey Hess. 4 5 # Uncomment this to turn on verbose mode. 6 #export DH_VERBOSE=1 7 8 # This is the debhelper compatibility version to use. 9 export DH_COMPAT=4 10 11 CFLAGS = -g 12 ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS))) 13 CFLAGS += -O0 14 else 15 CFLAGS += -O2 16 endif 17 18 build: build-stamp 19 build-stamp: 20 dh_testdir 21 22 # Add here commands to compile the package. 23 $(MAKE) 24 #docbook-to-man debian/gentoo.sgml > gentoo.1 25 26 touch build-stamp 27 28 clean: 29 dh_testdir 30 dh_testroot 31 rm -f build-stamp 32 33 # Add here commands to clean up after the build process. 34 -$(MAKE) clean 35 36 dh_clean 37 38 install: build 39 dh_testdir 40 dh_testroot 41 dh_clean -k 42 dh_installdirs 43 44 # Add here commands to install the package into debian/gentoo. 45 $(MAKE) install DESTDIR=$(CURDIR)/debian/gentoo 46 47 # Build architecture-independent files here. 48 binary-indep: build install 49 # We have nothing to do by default. 50 51 # Build architecture-dependent files here. 52 binary-arch: build install 53 dh_testdir 54 dh_testroot 55 # dh_installdebconf 56 dh_installdocs 57 dh_installexamples 58 dh_installmenu 59 # dh_installlogrotate 60 # dh_installemacsen 61 # dh_installpam 62 # dh_installmime 63 # dh_installinit 64 dh_installcron 65 dh_installman 66 dh_installinfo 67 # dh_undocumented 68 dh_installchangelogs ChangeLog 69 dh_link 70 dh_strip 71 dh_compress 72 dh_fixperms 73 # dh_makeshlibs 74 dh_installdeb 75 # dh_perl 76 dh_shlibdeps 77 dh_gencontrol 78 dh_md5sums 79 dh_builddeb 80 81 binary: binary-indep binary-arch 82 .PHONY: build clean binary-indep binary-arch binary install
(Ho aggiunto i numeri di riga.)
Hai probabilmente familiarità con righe come la prima, dagli script di shell e Perl. Essa dice al sistema operativo che questo file deve essere processato usando /usr/bin/make.
Il senso delle variabili DH_* menzionate alle righe 6 e 9 dovrebbe essere
evidente dalla breve descrizione. Per maggiori informazioni su DH_COMPAT leggi
la sezione "livelli di compatibilità di Debhelper" della
debhelper(1)
pagina di manuale.
Le righe da 11 a 16 sono schemi di supporto per i parametri DEB_BUILD_OPTIONS, descritti nella sezione 11.1 "Binari" della Policy. Di base queste cose controllano se i binari sono creati con i simboli per il debugging, e se questi possono essere eliminati al momento della installazione. Di nuovo, si tratta solo di uno schema, un suggerimento che dovresti seguire. Dovresti controllare come il sistema di compilazione dell'upstream gestisce l'inclusione di simboli di debugging e la loro cancellazione in installazione e implementare il tutto tu stesso.
Generalmente puoi dire al gcc di compilare con "-g" usando la variabile CFLAGS -- se questo è il caso del tuo pacchetto, propaga la variabile aggiungendo CFLAGS="$(CFLAGS)" alla chiamata $(MAKE) nella regola build (vedi oltre). In alternativa, se il tuo pacchetto usa uno script configure di autoconf, puoi passarlo a configure premettendo la suddetta stringa alla invocazione di ./configure nella regola di build.
A proposito di stripping, i programmi sono configurati comunemente per essere
installati non strippati, e spesso senza una opzione per modificare questa
cosa. Fortunatamente, hai anche dh_strip(1)
che controllerà se il
flag DEB_BUILD_OPTIONS=nostrip è configurato e terminerà silenziosamente.
Le righe dalla 18 alla 26 descrivono la regola `build' (e la figlia
`build-stamp') che lanciano make con il Makefile proprio della applicazione per
compilare il programma. Se il tuo pacchetto usa le utilità di configurazione
GNU per creare i binari, assicurati assolutamente di leggere
/usr/share/doc/autotools-dev/README.Debian.gz
. Parleremo
dell'esempio commentato docbook-to-man più avanti in manpage.1.ex, manpage.sgml.ex, Sezione
5.8.
La regola `clean', come specificata nelle righe 28-36, ripulisce ogni binario non necessario e file autogenerati, lasciati in giro dalla creazione del pacchetto. Questa regola deve lavorare tutte le volte (anche quando l'albero dei sorgenti è già ripulito!), per cui usa le opzioni di forzatura (per es. per rm, è -f), oppure fai in modo che make ignori i valori di ritorno (errori) usando un `-' prima del nome del comando.
Il processo di installazione, la regola `install', inizia a riga 38. Fondamentalmente lancia la regola `install' del Makefile del programma, ma installa nella directory $(CURDIR)/debian/gentoo - questo è il motivo per cui abbiamo specificato $(DESTDIR) come directory radice per l'installazione nel Makefile di gentoo.
Come suggeriscono i commenti, la regola `binary-indep', alla riga 48, è usata per costruire i pacchetti indipendenti dalla architettura. Dal momento che non ne abbiamo, non verrà fatto niente in questo caso.
Fino alla prossima regola - `binary-arch', dalla riga 52 alla 79, lanciamo una serie di piccoli programmi di utilità dal pacchetto debhelper che svolgono varie operazioni sui file del tuo pacchetto per renderlo conforme alla Policy.
Se il tuo pacchetto fosse del tipo `Architecture: all', avresti bisogno di includere tutti i comandi per costruire i pacchetti sotto la regola `binary-indep', e lasciare la regola `binary-arch' vuota, invece.
I nomi dei programmi di debhelper iniziano con dh_, e il resto è la descrizione di cosa fa effettivamente il programma di utilità. È tutto abbastanza auto esplicativo, ma ecco qualche spiegazione addizionale:
dh_testdir(1)
controlla di trovarsi nella giusta directory (cioè
la directory superiore dei sorgenti),
dh_testroot(1)
controlla che tu abbia i privilegi di root che sono
necessari per i target `binary-arch', `binary-indep' e 'clean',
dh_installman(1)
copia tutte le pagine di man al posto giusto
nella directory destinazione, devi solo dirgli dove sono relativamente alla
directory superiore dei sorgenti,
dh_strip(1)
elimina le intestazioni per il debugging dagli
eseguibili e librerie, per renderli più piccoli,
dh_compress(1)
comprime pagine di man e documentazioni più grandi
di 4kB con gzip(1)
,
dh_installdeb(1)
copia i file legati al pacchetto (per es. gli
script da maintainer) sotto la directory debian/gentoo/DEBIAN
,
dh_shlibdeps(1)
calcola le dipendenze da librerie condivise di
librerie ed eseguibili,
dh_gencontrol(1)
installa una versione modificata del file di
controllo in debian/gentoo/DEBIAN
,
dh_md5sums(1)
genera i codici di controllo MD5 per tutti i file
del pacchetto.
Per informazioni più complete su cosa fanno tutti questi script dh_*, e quali sono le loro altre opzioni, leggi le rispettive pagine di manuale. Ci sono alcuni altri, alle volte utili, script dh_*, che non sono menzionati qui. Se ne avessi bisogno, leggi la documentazione di debhelper.
La sezione binary-arch è quella dove dovresti effettivamente commentare qualsiasi riga che richiama funzionalità che non occorrono. Per gentoo, commenterò tutte le righe su examples, cron, init, man and info, semplicemente perché gentoo non le richiede. Inoltre alla linea 68, avrò bisogno di sostituirò `ChangeLog' con `FIXES', perché è il nome reale del file di changelog dell'upstream.
Le ultime due righe (insieme con le altre non spiegate qui) sono solo cose più o meno necessarie, delle quali puoi leggere nel manuale del make e nella Policy. Al momento, non è essenziale conoscerle.
Guida per il nuovo Maintainer
versione 1.2.3, 18 January 2005.joy-mg@debian.org
frankie@debian.org