Indice
README.Debian
compat
conffiles
pacchetto
.cron.*
dirs
pacchetto
.doc-base
docs
emacsen-*
pacchetto
.examples
pacchetto
.init
e
pacchetto
.default
install
pacchetto
.info
pacchetto
.links
{pacchetto
.,source/}lintian-overrides
manpage.*
pacchetto
.manpages
NEWS
{pre,post}{inst,rm}
package
.symbols
TODO
watch
source/format
source/local-options
source/options
patches/*
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
, come nel file
pacchetto
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
, ecc.
pacchetto-2
.install
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 <[email protected]>, Wed, 11 Nov 1998 21:02:14 +0100
Qui dovrebbero inserire delle brevi informazioni specifiche di Debian. Si veda dh_installdocs(1).
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.
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}
».
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:
-
Installato come
pacchetto
cron.hourly/etc/cron.hourly/
:
viene eseguito una volta ogni ora.
pacchetto
-
Installato as
pacchetto
cron.daily/etc/cron.daily/
:
viene eseguito una volta al giorno.
pacchetto
-
Installato come
pacchetto
cron.weekly/etc/cron.weekly/
:
viene eseguito una volta a settimana.
pacchetto
-
Installato come
pacchetto
cron.monthly/etc/cron.monthly/
:
viene eseguito una volta al mese.
pacchetto
- Installato
come pacchetto
cron.d/etc/cron.d/
:
per qualsiasi altro periodo.
pacchetto
Molti di questi file sono script di shell, fatta eccezione di
che segue
il formato di crontab(5).
pacchetto
.cron.d
Nessun esplicito file cron.*
è necessario per impostare
la rotazione dei log; a questo proposito si veda dh_installlogrotate(1) e logrotate(8).
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
.
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».
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
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.
Il comando dh_installexamples(1) installa i file e le directory elencati al suo interno come file di esempio.
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
file
will be installed as
package
.default/etc/default/
. This
file sets defaults that are sourced by the init script. This
package
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.
package
.default
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/
.
Comunque se lo script di init originale sembra funzionare bene ed installa
tutto nella corretta destinazione, si devono comunque impostare i link
simbolici pacchetto
.initrc*
. 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.
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/
non è stato
installato, in questo caso il file bar
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
, ecc.
pacchetto-2
.install
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
).
Se il pacchetto generato ha delle pagine info, queste andrebbero installate
utilizzando il comando dh_installinfo(1) ed elencandole nei file
.
pacchetto
.info
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
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
o pacchetto
.lintian-overridessource/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
è utilizzato per il pacchetto binario chiamato pacchetto
.lintian-overrides
ed è
installato in
pacchetto
usr/share/lintian/overrides/
dal comando dh_lintian.
pacchetto
Il file source/lintian-overrides
è utilizzato per il
pacchetto sorgente. Questo non viene installato.
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.
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]
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
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
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
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.
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/
files. Si veda Sezione A.2, «Gestire
package
.symbolsdebian/
».
package
.symbols
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/
presenti i nel file project
/tar-name
-(.+)\.tar\.gzwatch
. 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).
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
.
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
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)$"
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
per i sorgenti,
allora la modifica del pacchetto sorgente di tipo foo
.patch3.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.