[ precedente ] [ Contenuti ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ successivo ]
debian
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 Manuale delle policy di
Debian
e Guida di riferimento per
lo sviluppatore Debian
per le linee guida sulla creazione dei
pacchetti.
Il comando dh_make
creerà il modello dei file di configurazione
nella directory debian
. Molti di questi file terminano con
l'estensione ".ex". In altri inoltre il nome del file
viene preceduto dal nome del pacchetto in binario, come
pacchetto. Si dia uno sguardo a tutti i differenti
file di configurazione.
Se si vuole o si ha bisogno di attivare alcuno di questi file, si effettuino le seguenti operazioni:
si rinomini il file modello rimuovendo l'estensione .ex o .EX se presente.
si modifichi il contenuto del file in base al bisogno.
si elimini il file modello di cui non si ha più bisogno.
si modifichi il file di controllo
(si veda Il file control
, Sezione
4.1), se necessario.
si modifiche il file delle regole
(si veda Il file rules
, Sezione 4.4), se
necessario.
Questi 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.
README.Debian
Ogni ulteriore dettaglio o discrepanza tra il pacchetto originale e la versione debianizzata, che si è creata, dovrebbe essere documentato qui.
dh_make
ne crea uno predefinito, ecco come appare:
gentoo per Debian ----------------- <possibili note riguardanti questo pacchetto - se non presenti, si cancelli questo 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)
.
compat
The compat
file defines the debhelper
compatibility
level. Currently, you should set it to the debhelper
V7 by the
following.
$ echo 7 > debian/compat
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 applicando un marchio ai file di configurazione in modo tale che, quando si aggiorna un pacchetto, verrà richiesto se si vogliono mantenere o meno i vecchi file di configurazione.
A partire da debhelper
V3, dh_installdeb(1)
automaticamente marcherà 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 maggioranza dei tipi di pacchetto, l'unico posto in cui si
trovano (ed 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 2 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 fa generare un file dagli script del manutentore nella directory
/etc
.
Per maggiori informazioni sugli script del manutentore, si veda I file {post|pre}{inst|rm}
, Sezione
5.18.
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.
cron.hourly
- Installato come
/etc/cron.hourly/pacchetto
: viene eseguito una volta
all'ora, ogni ora.
cron.daily
- Installato as
/etc/cron.daily/pacchetto
: viene eseguito una volta al
giorno, di solito ogni mattino.
cron.weekly
- Installato come
/etc/cron.weekly/pacchetto
: viene eseguito una volta a
settimana, di solito ogni mattino di Domenica.
cron.monthly
- Installato come
/etc/cron.monthly/pacchetto
: viene eseguito una volta
al mese, di solito ogni mattino del primo del mese.
cron.d
- Installato come
/etc/cron.d/pacchetto
: per qualsiasi altro periodo
Il formato dei file qui presentati è lo script di shell. L'unico che
differisce dagli altri è pacchetto.cron.d
che segue il
formato di crontab(5)
.
Si noti che qui non è stata illustrata la rotazione dei log; a questo proposito
si veda dh_installlogrotate(1)
e logrotate(8)
.
dirs
Questo file specifica le directory di cui si ha bisogno ma che la normale
procedura di installazione ("make install DESTDIR=..."
chiamata da "dh_auto_install") non crea. 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 Il file
install
, Sezione 5.11
Si raccomanda di provare prima ad eseguire l'installazione ed utilizzare questo file solo se si incorre in problemi. Si noti che non il carattere slash non precede il nome delle directory.
pacchetto.doc-base
Se il pacchetto generato ha altra documentazione oltre alle pagine del manuale
e documenti informativi, 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
il manuale doc-base
, reperibile in
/usr/share/doc/doc-base/doc-base.html/
.
Per ulteriori dettagli su come installare documentazione aggiuntiva, si veda in Installazione in una sotto-directory, Sezione 3.3.
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
, nell'esempio, sono stati inclusi anche
altri files:
BUGS CONFIG-CHANGES CREDITS ONEWS README README.gtkrc TODO
emacsen-*
Se il pacchetto generato contiene file Emacs che possono essere compilati al momento dell'installazione, i file emacsen-* possono essere usati per impostarne la compilazione
Tali file sono installati nella directory temporanea con
dh_installemacsen(1)
.
Se non se ne ha bisogno, possono essere eliminati.
Il file pacchetto.examples
Il comando dh_installexamples(1)
installa i file e le directory
elencati al suo interno come file di esempio.
package.init
and package.default
filesSe il pacchetto generato è un demone che deve partire all'avvio del sistema, hai chiaramente ignorato le mie raccomandazioni iniziali, vero? :-)
Il file pacchetto.init
viene installato come lo script
/etc/init.d/pacchetto
. La sua struttura abbastanza
generica è fornita dal comando dh_make
come
init.d.ex
. Probabilmente si dovrà rinominare e modificare un bel
po', cercando di assicurarsi di fornire degli header che rispettino gli
standard della gerarchia dei filesystem (si veda
/usr/share/doc/debian-policy/fhs/
). Il file viene installato
nella directory temporanea con dh_installinit(1)
.
Il file pacchetto.default
viene installato in
etc/default/pacchetto
. Questo file imposta delle
variabili che vengono caricate dallo script di init. La maggioranza delle
volte questo file predefinito viene utilizzato per disabilitare l'esecuzione di
un demone, impostare degli argomenti predefiniti oppure dei timeout. Se lo
script di init ha alcune caratteristiche configurabili si dovrà
installare queste nel file predefinito, non nello script di init.
Se il pacchetto originario 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/init
. Comunque se lo script di init
originario 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.
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)
.[32]
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 non è stato installato, in questo caso il file
install
dovrebbe essere:
src/foo/mybin usr/bin
Questo significa che quando il pacchetto verrà installato, ci sarà un file
binario /usr/bin/mybin
.
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).
pacchetto.info
Se il pacchetto generato ha delle pagine informative, queste andrebbero
installate utilizzando il comando dh_installinfo(1)
ed elencandole
nei file pacchetto.info
.
{pacchetto.|source/}lintian-overrides
Se il pacchetto lintian
segnala degli errori di diagnostica in un
caso in cui esista una policy che ammette delle eccezioni alle regole, si
possono utilizzare i file pacchetto.lintian-overrides
o
source/lintian-overrides
per inibire le segnalazioni. Si legga
/usr/share/doc/lintian/lintian.html/index.html
e si eviti di farne
un uso eccessivo.
Il file pacchetto.lintian-overrides
è ovviamente
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.
manpage.*
I programmi creati dovrebbero avere una pagina che faccia da manuale. In caso
contrario ciascuno di questi file contiene un modello che può essere riempito.
Il comando dh_make
crea diversi file modello per la pagina del
manuale. Questi devono essere rinominati e modificati. Si faccia attenzione a
rimuovere i file modello non utilizzati.
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:
Section | Description | Notes 1 User commands Executable commands or scripts. 2 System calls Functions provided by the kernel. 3 Library calls Functions within system libraries. 4 Special files Usually found in /dev 5 File formats E.g. /etc/passwd's format 6 Games Or other frivolous programs 7 Macro packages Such as man macros. 8 System administration Programs typically only run by root. 9 Kernel routines Non-standard calls and internals.
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.
You can use the help2man
command to generate a man page out of
"--help" and "--version" output
of each program, too. [33]
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
manpage.xml.ex
Se si preferisce l'XML all'SGML, si può utilizzare il modello manpage.xml.ex . se si sceglie questa via 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
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
.
menu
Gli utenti dell'X Window System solitamente hanno un gestore di finestre che
può essere personalizzato per lanciare programmi. Se hanno installato il
pacchetto menu
, verrà creato un set di menu per ogni programma
del sistema.
Questo è il modello del file menu.ex
che il comando
dh_make
crea:
?package(gentoo):needs="X11|text|vc|wm" \ section="Applications/see-menu-manual"\ title="gentoo" command="/usr/bin/gentoo"
Il primo campo dopo i due punti è needs, e specifica il tipo di interfaccia di cui ha bisogno il programma. Questo valore può essere cambiato con una delle alternative elencate, ad esempio text o X11.
Il campo successivo è section, in cui dovrebbero apparire le voci
del menu e del sottomenu. L'attuale lista delle sezioni [34] si trova in:
/usr/share/doc/debian-policy/menu-policy.html/ch2.html#s2.1
Il campo title indica il nome del programma. Se si vuole si può scrivere in maiuscolo. Basta che si mantenga corto.
Infine, il campo command indica il comando che manda in esecuzione il programma.
Si può quindi cambiare il file menu
e la voce del menu nel modo
seguente:
?package(gentoo): needs="X11" \ section="Applications/Tools" \ title="Gentoo" command="gentoo"
Si possono anche aggiungere altri campi come longtitle,
icon, hints ecc. Si veda
dh_installmenu(1)
, menufile(5)
,
update-menus(1)
e
/usr/share/doc/debian-policy/menu-policy.html/
per maggiori
informazioni.
NEWS
Il comando dh_installchangelogs(1)
installa questo file.
{post|pre}{inst|rm}
I files postinst
, preinst
, postrm
e
prerm
[35] 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 non si è data retta e si sono 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.
The ucf
package provides conffile-like handling
infrastructure to preserve user changes for files that may not be labeled
conffiles such as ones managed by the maintainer scripts.
This should minimize issues associated with them.
Questi script del manutentore sono delle migliorie di Debian che fanno capire come mai le persone scelgano Debian. Bisogna stare molo attenti a non infastidirle a causa loro.
TODO
Il comando dh_installdocs(1)
installa questo file.
watch
Questo file è utilizzato per configurare il programma uscan(1)
(nel pacchetto devscripts
). Questo viene utilizzato per
controllare il sito da cui sono stati presi i sorgenti originali. Viene
utilizzato anche da Debian External
Health Status (DEHS)
.
Questo è ciò che si può mettere al suo interno:
# watch control file for uscan version=3 http://sf.net/gentoo/gentoo-(.*)\.tar\.gz debian uupdate
Normally with this watch
file, the URL at
"http://sf.net/gentoo" is downloaded and searched for
links of the form "<a href=...>". The base name
(just the part after the final "/") of these linked URLs
are matched against Perl regexp (see perlre(1)
) pattern
"gentoo-(.*)\.tar\.gz". Out of matched files, the file
with the greatest version number is downloaded and the uupdate
program is run to create the updated source tree from them.
Although this is true for other sites, the SourceForge download service at
http://sf.net
is an exception. When
the watch
file has an URL matching with the Perl regexp
"^http://sf\.net/", the uscan
program
substitutes it with "http://qa.debian.org/watch/sf.php/"
and then applies this rule. The URL redirector service at this http://qa.debian.org/
is designed to
offer a stable redirect service to the desired file for the watch
file having
"http://sf.net/project/tar-name-(.+)\.tar\.gz".
This solves issues related to the periodically changing URL there.
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) for Debian native packages or
3.0 (quilt) for everything else.
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. [36]
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.[37]
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.
patches/*
Il vecchio formato sorgente 1.0 creava un singolo, grosso file
diff.gz
file che conteneva tutti i file di manutenzione del
pacchetto che stavano in debian
ed i file di patch del sorgente.
Un pacchetto così è un poco ingombrante da ispezionare per capire
successivamente la sequenza delle modifiche. Per questo tale formato non è
considerato soddisfacente.
The newer 3.0 (quilt) source format stores patches in
debian/patches/*
files using the quilt
command.
These patches and other package data which are all constrained under the
debian
directory are packaged as the debian.tar.gz
file. Since the dpkg-source
command can handle quilt
formatted patch data in the 3.0 (quilt) source without the
quilt
package, it does not need to Build-Depends: on
the quilt
package. [38]
The quilt
command is explained in quilt(1)
. It
records modifications to the source as a stack of -p1 patch files
in the debian/patches
directory and the source tree is untouched
outside of the debian
directory. The order of these patches are
recorded in the debian/patches/series
file. You can apply
(=push), un-apply (=pop), and refresh patches easily. [39]
Per Primi passi, Capitolo 2, sono state create 3
patch in debian/patches
.
Dal momento che le patch di Debian sono posizionate in
debian/patches
, si prega di impostare correttamente il comando
quilt
come descritto in TODO "ref
id="quiltrc"".
Quando una qualsiasi persona 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 $ quilt import ../foo.patch $ quilt push $ quilt refresh $ quilt header -e ... describe patch
Le patch salvate nel nuovo formato sorgente 3.0 (quilt) devono essere prive di fuzz. Bisogna quindi assicurarsi di ciò eseguendo "quilt pop -a; while quilt push; do quilt refresh; done".
[ precedente ] [ Contenuti ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ successivo ]
Guida per il nuovo Maintainer
version 1.2.19, 2010-05-31 13:48:35 UTCjoy-mg@debian.org
kalos@nerdrug.org
jacopo.reggiani@gmail.com