Capitolo 5. Altri file nella directory `debian`

Indice

The dh_make command had major updates since this old document was written. So some parts of this document aren't applicable any more.

È disponibile la riscrittura di questo tutorial, con contenuti aggiornati e con esempi più pratici, denominato Guide for Debian Maintainers. Si prega di utilizzare il nuovo tutorial come documento primario.

The debmake command is used in place of the dh_make command in my new Guide for Debian Maintainers.

Per controllare la maggior parte delle operazioni che debhelper effettua durante la creazione del pacchetto, si possono inserire dei file di configurazione all'interno della directory debian. Questo capitolo fornirà una panoramica sull'utilizzo di ciascuno di essi ed il loro formato. Si legga il Manuale delle policy di Debian e la Guida di riferimento per lo sviluppatore Debian per le linee guida sulla creazione dei pacchetti.

The dh_make command will create some template configuration files under the debian directory. Take a look at all of them.

In questo capitolo, per semplicità, i file nella directory debian sono indicati senza la directory radice debian/, ogni volta che il loro significato è scontato.

Alcuni modelli di file di configurazione per debhelper non possono essere creati dal comando dh_make. In questo caso, è necessario crearlo con un editor.

Se si vuole o si ha bisogno di attivare uno di questi file, si effettuino le seguenti operazioni:

si rinominino i file di configurazione con il nome usato dall'attuale pacchetto binario al posto di pacchetto;
si modifichi il contenuto del file in base alle proprie esigenze;
si elimini il file modello di cui non si ha più bisogno;
si modifichi il file control (si veda Sezione 4.1, «control»), se necessario;
si modifichi il file delle regole (si veda Sezione 4.4, «Il file rules»), se necessario.

Qualsiasi file di configurazione di debhelper senza prefisso del pacchetto, come nel file install vengono applicati al primo pacchetto binario. Quando ci sono molti pacchetti binari le loro configurazioni possono essere specificate aggiungendo il loro prefisso al nome del file di configurazione come pacchetto-1.install, pacchetto-2.install, ecc.

5.1. `README.Debian`

Ogni ulteriore dettaglio o discrepanza tra il pacchetto originale e la versione Debian dovrebbe essere documentato qui.

dh_make ne crea uno predefinito; ecco come appare:

gentoo for Debian
-----------------
<possible notes regarding this package - if none, delete this file>
 -- Josip Rodin <joy-mg@debian.org>, Wed, 11 Nov 1998 21:02:14 +0100

Qui dovrebbero inserire delle brevi informazioni specifiche di Debian. Si veda dh_installdocs(1).

5.2. `compat`

Il file compat definisce il livello di compatibilità di debhelper. Al momento dovrebbe essere impostato a debhelper v10 nel modo seguente:

$ echo 10 > debian/compat

È possibile utilizzare il livello di compatibilità v9 in determinate circostanze per la compatibilità con i sistemi meno recenti. Tuttavia, l'utilizzo di qualsiasi livello inferiore al v9 non è raccomandato e dovrebbe essere evitato per i nuovi pacchetti.

5.3. `conffiles`

Una delle cose più fastidiose riguardanti il software accade quando si spende una grande quantità di tempo e di sforzi per personalizzare un programma solo per vedere un aggiornamento spazzare via tutte le modifiche fatte. Debian risolve questo problema marcando i file di configurazione come conffiles. ^[54] Quando si aggiorna un pacchetto, verrà richiesto se si vogliono mantenere o meno i vecchi file di configurazione.

dh_installdeb(1) marcherà automaticamente ogni file che si trova nella directory /etc come conffiles, così che se il programma ha soli file di configurazione in quella directory, non ci sarà bisogno di specificarli in questo file. Per la maggior parte dei tipi di pacchetto, l'unico posto in cui si dovrebbero trovare i conffile è all'interno di /etc e quindi non c'è bisogno che questo file esista.

Se il programma creato utilizza file di configurazione e li sovrascrive in automatico, è meglio non rendere questi ultimi dei file di configurazione perché dpkg chiederà ogni volta agli utenti di verificare i cambiamenti.

Se il programma di cui si sta creando il pacchetto richiede ad ogni utente di modificare i file di configurazione nella directory /etc, ci sono principalmente due modi per non renderli conffiles e quindi di mantenere dpkg tranquillo:

Si può creare un link simbolico nella directory /etc che punti ad un file nella directory /var generato dagli script del manutentore.
Si crei un file generato dagli script del manutentore nella directory /etc.

Per maggiori informazioni sugli script del manutentore, si veda Sezione 5.18, «{pre,post}{inst,rm}».

5.4. `pacchetto.cron.*`

Se il pacchetto creato richiede che vengano programmate delle operazioni per funzionare correttamente, si può utilizzare questo file per lo scopo. Si possono programmare delle operazioni in modo tale che vengano eseguite su base oraria, giornaliera, settimanale, mensile o che vengano eseguite alternativamente in qualsiasi momento si voglia. I file saranno:

pacchettocron.hourly - Installato come /etc/cron.hourly/pacchetto: viene eseguito una volta ogni ora.
pacchettocron.daily - Installato as /etc/cron.daily/pacchetto: viene eseguito una volta al giorno.
pacchettocron.weekly - Installato come /etc/cron.weekly/pacchetto: viene eseguito una volta a settimana.
pacchettocron.monthly - Installato come /etc/cron.monthly/pacchetto: viene eseguito una volta al mese.
pacchettocron.d - Installato come /etc/cron.d/pacchetto: per qualsiasi altro periodo.

Molti di questi file sono script di shell, fatta eccezione di pacchetto.cron.d che segue il formato di crontab(5).

Nessun esplicito file cron.* è necessario per impostare la rotazione dei log; a questo proposito si veda dh_installlogrotate(1) e logrotate(8).

5.5. `dirs`

Questo file specifica le directory di cui si ha bisogno ma che non vengono create nella normale procedura di installazione (make install DESTDIR=... chiamata da dh_auto_install). Questo generalmente indica la presenza di un problema nel Makefile.

I file elencati nel file install non hanno bisogno che le directory vengano create prima. Si veda Sezione 5.11, «install».

Si raccomanda di provare prima ad eseguire l'installazione ed utilizzare questo file solo se si incorre in problemi. Si noti che il carattere slash non precede il nome delle directory elencate nel file dirs.

5.6. `pacchetto.doc-base`

Se il pacchetto generato ha altra documentazione oltre alle pagine di manuale e di info, dovrebbe essere utilizzato il file doc-base per segnalarla in modo che l'utente possa trovarla con, ad esempio dhelp(1), dwww(1) o doccentral(1).

Questa documentazione è solitamente costituita da documenti HTML, file PS e PDF, disponibili in /usr/share/doc/nomepacchetto/.

Questo è il modo in cui il file doc-base di gentoo, gentoo.doc-base, appare:

Document: gentoo
Title: Gentoo Manual
Author: Emil Brink
Abstract: This manual describes what Gentoo is, and how it can be used.
Section: File Management
Format: HTML
Index: /usr/share/doc/gentoo/html/index.html
Files: /usr/share/doc/gentoo/html/*.html

Per informazioni sul formato del file si veda install-docs(8) ed la copia locale del manuale Debian doc-base, reperibile con il pacchetto doc-base.

Per ulteriori dettagli su come installare documentazione aggiuntiva, si veda in Sezione 3.3, «Installazione dei file nei loro percorsi».

5.7. `docs`

Questo file specifica il nome dei file di documentazione che si possono avere dh_installdocs(1) li installa nella directory temporanea automaticamente.

Normalmente, questo file includerà tutti i file esistenti nella directory dei sorgenti di più alto livello che sono chiamati BUGS, README*, TODO ecc.

Per il pacchetto gentoo, sono stati inclusi anche altri files:

BUGS
CONFIG-CHANGES
CREDITS
NEWS
README
README.gtkrc
TODO

5.8. `emacsen-*`

Se il pacchetto generato contiene file Emacs che possono essere compilati al momento dell'installazione, possono essere usati per impostarli.

Tali file sono installati nella directory temporanea con dh_installemacsen(1).

Se non se ne ha bisogno, possono essere eliminati.

5.9. `pacchetto.examples`

Il comando dh_installexamples(1) installa i file e le directory elencati al suo interno come file di esempio.

5.10. `pacchetto.init` e `pacchetto.default`

Se il pacchetto generato è un demone che deve partire all'avvio del sistema, hai chiaramente ignorato le mie raccomandazioni iniziali, vero? :-)

Please read dh_installinit(1) dh_installsystemd(1) to provide startup script.

The package.default file will be installed as /etc/default/package. This file sets defaults that are sourced by the init script. This package.default file is most often used to set some default flags or timeouts. If your init script has certain configurable features, you can set them in the package.default file, instead of in the init script itself.

Se il programma originale ha un file di init si può decidere di utilizzarlo o meno. Se non viene utilizzato quello script init.d allora ne dovrà essere creato uno nuovo in debian/pacchetto.init. Comunque se lo script di init originale sembra funzionare bene ed installa tutto nella corretta destinazione, si devono comunque impostare i link simbolici rc*. Per fare questo si deve sovrascrivere dh_installinit nel file rules con le seguenti righe:

override_dh_installinit:
        dh_installinit --onlyscripts

Se non si ha bisogno di tutto ciò, si possono rimuovere i file.

5.11. `install`

Se ci sono dei file che devono essere installati nel pacchetto ma con il normale comando make install non vengono elaborati, i nomi di quest'ultimi e le cartelle di destinazione vanno messe in questo file install. Tali file vengono installati con il comando dh_install(1).^[55] Andrebbe innanzitutto controllato che non ci sia uno strumento più specifico da poter utilizzare. Per esempio, i documenti dovrebbero essere elencati nel file docs e non in questo file.

Nel file install compare una riga per ogni file installato, contenente il nome del file (relativo alla directory in cui avviene la costruzione del pacchetto), uno spazio e la directory di installazione (relativa alla posizione del file install). Un esempio dell'utilizzo è quando un file binario src/bar non è stato installato, in questo caso il file install dovrebbe essere:

src/bar usr/bin

Questo significa che quando il pacchetto verrà installato, ci sarà un file eseguibile /usr/bin/bar.

Alternativamente, questo file install può presentare il nome del file senza la directory di installazione solo quando il percorso relativo della directory non cambia. Questo formato è solitamente utilizzato per grandi pacchetti che organizzano i risultati della costruzione in pacchetti multipli utilizzando pacchetto-1.install, pacchetto-2.install, ecc.

Il comando dh_install andrà a controllare nella cartella debian/tmp alla ricerca di file, se non ne trova nella directory corrente (or in qualsiasi altro posto si sia indicato di guardare utilizzando --sourcedir).

5.12. `pacchetto.info`

Se il pacchetto generato ha delle pagine info, queste andrebbero installate utilizzando il comando dh_installinfo(1) ed elencandole nei file pacchetto.info.

5.13. `pacchetto.links`

Se è necessario creare dei collegamenti simbolici aggiuntivi nella directory utilizzata per la creazione del pacchetto, si dovrebbero installare, come maintainer del pacchetto, utilizzando dh_link(1) con il path per esteso della sorgente e della destinazione dei file nel file package.links.

5.14. `{pacchetto.,source/}lintian-overrides`

Se il pacchetto lintian segnala degli errori di diagnostica in un caso in cui esista una policy Debian che ammette delle eccezioni alle regole, si possono utilizzare i file pacchetto.lintian-overrides o source/lintian-overrides per inibire le segnalazioni. Si legga il manuale utente di Lintian (https://lintian.debian.org/manual/index.html) e si eviti di farne un uso eccessivo.

Il file pacchetto.lintian-overrides è utilizzato per il pacchetto binario chiamato pacchetto ed è installato in usr/share/lintian/overrides/pacchetto dal comando dh_lintian.

Il file source/lintian-overrides è utilizzato per il pacchetto sorgente. Questo non viene installato.

5.15. `manpage.*`

I programmi creati dovrebbero avere una pagina di manuale. In caso contrario bisogna crearla. Il comando dh_make crea diversi file modello per la pagina di manuale. Questi devono essere copiati e modificati per ogni comando senza pagina di manuale. Si faccia attenzione a rimuovere i file modello non utilizzati.

5.15.1. `manpage.1.ex`

Le pagine del manuale sono solitamente scritte per nroff(1). Anche il file modello manpage.1.ex è scritto per nroff. Si veda la pagina di manuale man(7) per una breve descrizione su come modificare un file del genere.

L'ultimo file delle pagine del manuale dovrebbe includere il nome del programma che si sta documentando, quindi verrà rinominato da manpage a gentoo. Il nome del file include anche .1 come primo suffisso, il che sta ad indicare che la sezione della pagina del manuale è relativa ad un comando dell'utente. Si verifichi che questa sezione sia quella corretta. Qui di seguito viene presentata una breve lista delle sezioni delle pagine del manuale:

Sezione	Descrizione	Note
1	Comandi utente	Comandi eseguibili o script
2	Chiamate di sistema	Funzioni fornite dal kernel
3	Chiamate alla libreria	Funzioni delle librerie di sistema
4	File speciali	Posizionati normalmente in `/dev`
5	Formati di file	Ad esempio il formato del file `/etc/passwd`
6	Giochi	Giochi o altri programmi frivoli
7	Pacchetti di macro	Come le macro di man
8	Amministrazione del sistema	Programmi di norma eseguibili solo da root
9	Kernel routine	Chiamate non standard e interne

Così la pagina man del pacchetto gentoo dovrebbe chiamarsi gentoo.1. Se non ci fosse alcuna pagina man gentoo.1 nei sorgenti originali, andrebbe creata rinominando il modello manpage.1.ex in gentoo.1 e modificandolo utilizzando le informazioni contenute negli esempi e nei documenti originali.

Si può utilizzare il comando help2man per generare una pagina di manuale, priva del risultato di --help and --version, per ogni programma. ^[56]

5.15.2. `manpage.sgml.ex`

Se d'altra parte si preferisce scrivere in SGML piuttosto che utilizzare nroff, si può utilizzare il modello manpage.sgml.ex. Se si procede in questo modo andrà:

rinominato il file in qualcosa del tipo gentoo.sgml.
installato il pacchetto docbook-to-man
aggiunto docbook-to-man alla linea Build-Depends nel file control

aggiungere un obiettivo override_dh_auto_build al file rules :

override_dh_auto_build:
        docbook-to-man debian/gentoo.sgml > debian/gentoo.1
        dh_auto_build

5.15.3. `manpage.xml.ex`

Se si preferisce l'XML all'SGML, si può utilizzare il modello manpage.xml.ex. Se si decide questa modalità si avranno due scelte:

rinominare il file in qualcosa del tipo gentoo.1.xml
installare il pacchetto docbook-xsl e l'elaboratore XSLT come xsltproc (recommended)
aggiungere i pacchetti docbook-xsl, docbook-xml e xsltproc alla linea Build-Depends nel file control

aggiungere un obiettivo override_dh_auto_build al file rules :

override_dh_auto_build:
        xsltproc --nonet \
         --param make.year.ranges 1 \
         --param make.single.year.ranges 1 \
         --param man.charmap.use.subset 0 \
         -o debian/ \
http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl\
        debian/gentoo.1.xml
        dh_auto_build

5.16. `pacchetto.manpages`

Se il pacchetto creato presenta delle pagine del manuale, queste andrebbero installate utilizzando il comando dh_installman(1) ed elencandole nei file pacchetto.manpages.

Per installare il file doc/gentoo.1 come pagine di manuale per il pacchetto gentoo, si deve creare il file gentoo.manpages contenente:

docs/gentoo.1

5.17. `NEWS`

Il comando dh_installchangelogs(1) installa questo file.

5.18. `{pre,post}{inst,rm}`

I files postinst, preinst, postrm e prerm ^[57] vengono chiamati script del manutentore. Questi sono script che vengono messi nell'area di controllo del pacchetto e vengono lanciati dal comando dpkg quando il pacchetto viene installato, aggiornato o rimosso.

Un nuovo manutentore dovrebbe, se possibile, evitare ogni modifica manuale degli script del manutentore perché potrebbero creare dei problemi. Per maggiori informazioni si guardi nel Manuale delle policy di Debian, 6 'Script di manutenzione del pacchetto e procedure di installazione', e si dia un'occhiata ai file di esempio forniti da dh_make.

Se si sono, comunque, creati dei script del manutentore personalizzati per un pacchetto, bisogna essere sicuri di averli provati non solo per install e upgrade, ma anche per remove e purge.

Gli aggiornamenti alle nuove versioni dovrebbero essere indolore e non invadenti (gli utenti esistenti non dovrebbero notare gli aggiornamenti a meno di scoprire che vecchi bug sono stati corretti e che vi sono magari delle nuove funzionalità).

Quando l'aggiornamento deve per forza di cose essere invadente (per esempio, file di configurazione sparsi all'interno di diverse cartelle home con strutture totalmente differenti), si può impostare il pacchetto ai valori sicuri predefiniti (esempio, servizi disabilitati) e fornire una valida documentazione come richiesto dalla policy (README.Debian e NEWS.Debian) come ultima spiaggia. Sarebbe meglio non disturbare l'utente con la nota debconf richiamata da questi script del manutentore per gli aggiornamenti.

Il pacchetto ucf fornisce una infrastruttura di gestione simil-conffile per preservare cambiamenti effettuati dall'utente in file che non possono essere etichettati come conffile, come ad esempio quelli gestiti dagli script del manutentore. Questo dovrebbe ridurre al minimo i problemi ad esso associati.

Questi script del manutentore sono delle migliorie di Debian che fanno capire come mai le persone scelgano Debian. Bisogna stare molto attenti a non infastidirle a causa loro.

5.19. `package.symbols`

Creare il pacchetto di una libreria non è semplice per un maintainer con poca esperienza e dovrebbe essere evitato. Detto questo, se il pacchetto in questione ha delle librerie, si dovrebbero avere dei file debian/package.symbols files. Si veda Sezione A.2, «Gestire debian/package.symbols».

5.20. `TODO`

Il comando dh_installdocs(1) installa questo file.

5.21. `watch`

Il formato del file watch è documentato nella pagina di manuale uscan(1). Il file watch configura il programma uscan (nel pacchetto devscripts) per controllare il sito da cui è stato scaricato il sorgente originale. Questo file viene utilizzato pure dal servizio Debian Package Tracker.

Ecco il suo contenuto:

# watch control file for uscan
version=3
http://sf.net/gentoo/gentoo-(.+)\.tar\.gz debian uupdate

Normalmente con il file watch, l'URL http://sf.net/gentoo viene scaricato per cercare dei collegamenti del tipo <a href=...>. Il nome base (la parte appena dopo l'ultimo /) di questi URL sono confrontati con l'espressione regolare Perl (si veda perlre(1)) gentoo-(.+)\.tar\.gz. Tra i file che combaciano viene scaricato quello avente il numero di versione più grande e viene avviato il programma uupdate per creare un albero dei sorgenti aggiornato.

Sebbene questo sia vero per la maggior parte dei siti, il servizio di scaricamento di SourceForge su http://sf.net è un'eccezione. Quando il file watch ha un URL che corrisponde all'espressione regolare perl ^http://sf\.net/, il programma uscan lo sostituisce con http://qa.debian.org/watch/sf.php/. Il servizio di reindirizzamento degli URL http://qa.debian.org/ è progettato per mettere a disposizione un sistema stabile per reindirizzare gli URL tipo http://sf.net/project/tar-name-(.+)\.tar\.gz presenti i nel file watch. Questo risolve il problema relativo al cambiamento periodico degli URL di SourceForge.

Se il pacchetto originale dispone di una firma crittografica dell'archivio, si consiglia di verificarne l'autenticità utilizzando l'opzione pgpsigurlmangle come descritto in uscan(1).

5.22. `source/format`

Nel file debian/source/format, ci dovrebbe essere una unica riga che indichi il formato desiderato per il pacchetto sorgente (controllare dpkg-source(1) per una lista completa). Dopo squeeze, dovrebbe scrivere:

3.0 (native) per i pacchetti nativi Debian o
3.0 (quilt)per tutti gli altri.

Il nuovo formato sorgente 3.0 (quilt) registra le modifiche in una serie di patch quilt all'interno di debian/patches. Questi cambiamenti vengono poi automaticamente applicati durante l'estrazione del pacchetto sorgente. ^[58] Le modifiche di Debian sono semplicemente mantenute in un archivio debian.tar.gz contenente tutti i file sotto la directory debian. Questo nuovo formato supporta l'inclusione di file binari come per esempio le icone PNG del manutentore del pacchetto senza richiedere trucchi.^[59]

Quando dpkg-source estrae un pacchetto sorgente nel formato 3.0 (quilt), applica automaticamente tutte le patch elencate nel file debian/patches/series. Si può evitare di applicare le patch alla fine dell'estrazione con l'opzione --skip-patches.

5.23. `source/local-options`

Quando si vogliono gestire le attività di pacchettizzazione utilizzando un VCS, di norma si crea un ramo (es. upstream) in cui si tiene traccia dei cambiamenti apportanti al sorgente originale, e un altro ramo (es. di solito master per Git) in cui si tiene traccia delle modifiche apportate al pacchetto. In fine, è consigliato avere i sorgenti originali senza pach con i file in debian/* per il pacchetto Debian, per fare facilitare le operazioni di fusione con il nuovo sorgente originale.

Dopo aver costruito il pacchetto, il sorgente è di norma pachato. È necessario togliere la patch manualmente, eseguendo dquilt pop -a, prima di caricarlo nel ramo master. Si può automatizzare l'operazione, aggiungendo il file debian/source/local-options con contenuto unapply-patches. Questo file non è incluso nel sorgente del pacchetto generato, e cambia solamente la modalità di costruzione in locale. Questo file può contenere anche abort-on-upstream-changes, (si veda dpkg-source(1)).

unapply-patches
abort-on-upstream-changes

5.24. `source/options`

I file generati automaticamente nell'albero dei sorgenti possono essere molto fastidiosi per la pacchettizzazione, in quanto generano file di patch senza senso e di grandi dimensioni. Ci sono moduli personalizzati come dh_autoreconf per facilitare questo problema, come descritto nella Sezione 4.4.3, «Personalizzazione del file rules» .

È possibile fornire un'espressione regolare Perl al parametro --extend-diff-ignore di dpkg-source(1) per ignorare le modifiche apportate ai file generati automaticamente durante la creazione del pacchetto sorgente.

Come soluzione generale per affrontare il problema dei file generati automaticamente, è possibile memorizzare un parametro dpkg-source nel file source/options del pacchetto sorgente. Il comando di seguito salterà la creazione dei file di patch per config.sub, config.guess e Makefile.

extend-diff-ignore = "(^|/)(config\.sub|config\.guess|Makefile)$"

5.25. `patches/*`

Il vecchio formato sorgente 1.0 creava un singolo, grosso file diff.gz file che conteneva i file di manutenzione del pacchetto che stavano in debian ed i file di patch del sorgente. Un pacchetto così è un po' difficoltoso da ispezionare per capire successivamente la sequenza delle modifiche. Per questo tale formato non è considerato soddisfacente.

Il nuovo formato dei sorgenti 3.0 (quilt) salva le patch in file debian/patches/* utilizzando il comando quilt. Queste patch e gli altri dati del pacchetto che sono contenuti nella directory debian è pacchettizzato come file debian.tar.gz. Poiché il comando dpkg-source è in grado di gestire patch formattate con quilt nel formato sorgente 3.0 (quilt) senza il pacchetto quilt, non è necessario il avere quilt nel campo Build-Depends. ^[60]

Il comando quilt è documentato in quilt(1). Esso registra le modifiche ai sorgenti come una coda di file di patch -p1 nella directory debian/patches e l'albero dei sorgenti non varia al di fuori della directory debian. L'ordine delle patch è registrato nel file debian/patches/series. Si può applicare (=push), rimuovere(=pop), ed aggiornare le patch con facilità. ^[61]

Per Capitolo 3, Modificare i sorgenti, sono state create tre patch in debian/patches.

Dal momento che le patch di Debian si trovano in debian/patches, ci si assicuri di impostare correttamente il comando dquilt, come descritto nella Sezione 3.1, «Configurare quilt».

Quando qualcuno (me compreso) fornisce una patch foo.patch per i sorgenti, allora la modifica del pacchetto sorgente di tipo 3.0 (quilt)è abbastanza semplice:

$ dpkg-source -x gentoo_0.9.12.dsc
$ cd gentoo-0.9.12
$ dquilt import ../foo.patch
$ dquilt push
$ dquilt refresh
$ dquilt header -e
... describe patch

Le patch salvate nel nuovo formato sorgente 3.0 (quilt) devono essere prive di fuffa. Bisogna quindi assicurarsi di ciò eseguendo dquilt pop -a; while dquilt push; do dquilt refresh; done.

^[54]Vedere dpkg(1) e il manuale delle policy Debian, "D.2.5 Conffiles".

^[55] Questo comando rimpiazza il comando dh_movefiles(1), ormai deprecato, che veniva configurato dal file files.

^[56] Si noti che i segnaposto di help2man contengono la documentazione più dettagliata disponibile nel sistema info. Se al comando manca la pagina info si dovrebbe modificare manualmente la pagina man generata dal comando help2man.

^[57] Nonostante l'utilizzo dell'espressione bash {pre,post}{inst,rm} per indicare questi file, è necessario utilizzare la sintassi POSIX per questi script di manutenzione per mantenere la compatibilità con la shell di sistema dash.

^[58] Si veda DebSrc3.0 per una serie di informazioni generali riguardanti il passaggio al nuovo formato 3.0 (quilt) ed ai formati sorgente 3.0 (native).

^[59]Al momento questo nuovo formato supporta anche molteplici archivi e più metodi di compressione. Questi però esulano dall'obiettivo di questo documento.

^[60] Diversi metodi di mantenimento delle patch set sono stati proposti e sono utilizzati per i pacchetti Debian. Il sistema quilt è il sistema di manutenzione consigliato ed utilizzato. Altri includono dpatch, dbs e cdbs. Molte di questi tengono le patch come file debian/patches/*.

^[61] Se si sta chiedendo ad uno sponsor di caricare il proprio pacchetto, questo tipo di chiara separazione e documentazione dei cambiamenti è molto importante per accelerare la revisione del pacchetto da parte dello sponsor.


Capitolo 4. File richiesti nella directory `debian`		Capitolo 6. Costruzione del pacchetto