Capitolo 5. Altri file nella directory `debian`

# Capitolo 5. Altri file nella directory `debian`

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:

- ``pacchetto`cron.hourly` - Installato come `/etc/cron.hourly/`pacchetto``: viene eseguito una volta ogni ora.

- ``pacchetto`cron.daily` - Installato as `/etc/cron.daily/`pacchetto``: viene eseguito una volta al giorno.

- ``pacchetto`cron.weekly` - Installato come `/etc/cron.weekly/`pacchetto``: viene eseguito una volta a settimana.

- ``pacchetto`cron.monthly` - Installato come `/etc/cron.monthly/`pacchetto``: viene eseguito una volta al mese.

- ``pacchetto`cron.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