[ precedente ] [ Contenuti ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ successivo ]
debian
C'è una nuova sottodirectory all'interno della cartella contenente i sorgenti
del programma ed è chiamata debian
. All'interno di questa vi
sono una serie di file che dovranno essere modificati per personalizzare il
comportamento del pacchetto. I più importanti fra tutti questi sono i file
control
, changelog
, copyright
e
rules
, che vengono richiesti per tutti i pacchetti.
control
Questo file contiene diversi valori che dpkg
,
dselect
, apt-get
, apt-cache
,
aptitude
, ed altri strumenti utilizzeranno per gestire il
pacchetto. Il tutto è definito nel Manuale
delle policy di Debian, 5 'File di controllo e loro campi'
.
Questo è il file di controllo che dh_make
crea:
1 Source: gentoo 2 Section: unknown 3 Priority: extra 4 Maintainer: Josip Rodin <joy-mg@debian.org> 5 Build-Depends: debhelper (>= 7.0.50~) 6 Standards-Version: 3.8.4 7 Homepage: <insert the upstream URL, if relevant> 8 9 Package: gentoo 10 Architecture: any 11 Depends: ${shlibs:Depends}, ${misc:Depends} 12 Description: <insert up to 60 chars description> 13 <insert long description, indented with spaces>
(Sono stati aggiunti i numeri di riga.)
Le righe 1-6 contengono informazioni di controllo per il pacchetto sorgente.
La riga 1 contiene il nome del pacchetto sorgente.
La riga 2 indica la sezione della distribuzione in cui il pacchetto sorgente dovrà andare.
Come si sarà notato, l'archivio Debian è diviso in sezioni: main
(software libero), non-free (software non propriamente libero) e
contrib (software libero che dipende da software non libero).
All'interno di queste esistono delle sottosezioni che descrivono brevemente
quali pacchetti vi si possono trovare. Quindi si hanno le sezioni
admin per i programmi legati all'amministrazione di sistema,
base per gli strumenti di base, devel per gli
strumenti di sviluppo, doc per la documentazione,
libs per le librerie, mail per client di posta e
server associati, net per applicazioni e servizi di rete,
x11 per programmi X11 che non appartengono alle altre categorie, e
tanti altri. Si legga Manuale
delle policy di Debian, 2.4 'Sezioni'
e List of sections in
'sid'
per maggiori informazioni.
Si può quindi cambiare il valore alla seconda riga in x11. (Il prefisso main/ è implicito e può essere omesso.)
La riga numero 3 indica quanto sia importante per l'utente installare questo
pacchetto. Si legga Manuale
delle policy di Debian, 2.5 'Priorità'
per maggiori informazioni.
La priorità optional solitamente viene usata per i nuovi pacchetti che non vanno in conflitto con altri pacchetti con priorità required, important o standard.
La priorità extra solitamente viene usata per i nuovi pacchetti, che andrebbero in conflitto con altri pacchetti che non hanno questa priorità
Le sezioni e le priorità vengono solitamente utilizzate da interfacce come
aptitude
in cui i pacchetti vengono suddivisi e vengono
selezionati quelli predefiniti. Una volta caricato il pacchetto in Debian, il
valore di ciascuno di questi due campi può essere sovrascritto dai manutentori
dell'archivio, in tal caso si verrà avvertiti via mail.
Dal momento che il pacchetto trattato ha una priorità normale e non va in conflitto con altri, si cambierà la priorità a "optional".
La riga 4 indica il nome e l'indirizzo email del manutentore. Ci si assicuri che questo campo includa una testata "To" valida per un indirizzo mail, perché una volta caricato il pacchetto, il sistema di rilevazione bug la userà per inviare le mail contenenti i bug. Si eviti di utilizzare virgole, 'e' commerciali e parentesi.
La quinta linea include la lista dei pacchetti richiesti per costruire il
pacchetto, ad es. il campo Build-Depends. Si può, inoltre,
avere una riga contenente il campo Build-Depends-Indep. (vedere
il Manuale
delle policy di Debian, 7.7 'Relazione tra pacchetti sorgenti e binari -
Build-Depends, Build-Depends-Indep, Build-Conflicts,
Build-Conflicts-Indep'
). Alcuni pacchetti come gcc
e
make
sono richiesti implicitamente, dal pacchetto
build-essential
. Se si ha la necessità di avere altri strumenti
per costruire il pacchetto, questi devono essere aggiunti negli appositi campi.
I campi multipli sono separati con le virgole; si legga una spiegazione sulle
dipendenze binarie per scoprirne di più sulla sintassi di queste righe.
Per tutti i pacchetti creati utilizzando il comando dh
nel file
debian/rules
, è necessario avere "debhelper
(>=7.0.50~)" nel campo Build-Depends, per aderire
alle policy di Debian che richiedono per l'obiettivo clean.
I sorgenti dei pacchetti che hanno qualche pacchetto binario con il campo "Architecture: any", devono essere ricompilati dal sistema di auto-costruzione.
Per i soli sorgenti dei pacchetti che hanno come pacchetti binari "Architecture: all", il campo Build-Depends-Indep elenca tutti i pacchetti necessari, se non sono già elencati nel campo Build-Depends, per essere conforme alle linee guida di Debian riguardanti il target clean.
Se non si è sicuri sul campo da utilizzare, si può scegliere il campo Build-Depends.[16]
Per scoprire di quali pacchetti si ha bisogno per la compilazione si può eseguire il comando:
$ dpkg-depcheck -d ./configure
Per scoprire manualmente le esatte dipendenze per
/usr/bin/foo
, si esegue
$ objdump -p /usr/bin/foo | grep NEEDED
e per ogni libreria elencata, ad esempio, libfoo.so.6
, si esegue
$ dpkg -S libfoo.so.6
A questo punto si indica la versione -dev di ogni pacchetto come
voce Build-Depends. Se si usa ldd
per questo scopo,
verranno considerate anche le dipendenze indirette, il che potrà portare ad
avere un numero eccessivo di dipendenze.
Il pacchetto gentoo
richiede anche xlibs-dev
,
libgtk1.2-dev
e libglib1.2-dev
per poter essere
costruito, quindi tali dipendenze si aggiungeranno subito dopo
debhelper
.
La riga 6 indica la versione delle delle linee guida
Debian
che il pacchetto deve rispettare, che corrisponde a quello
che si legge quando lo si crea.
Nella riga 7 si può inserire l'URL della pagina del programma originale.
La riga 9 indica il nome del pacchetto binario. Questo è normalmente lo stesso nome del pacchetto sorgente, ma non deve essere necessariamente così.
Alla riga 10 viene descritta l'architettura CPU per cui può essere compilato
il pacchetto binario. Si lascerà "any" perché
dpkg-gencontrol(1)
riempa questo campo con un valore adeguato per
ciascuna macchina in cui il pacchetto viene compilato.
Se il pacchetto è indipendente dall'architettura (per esempio, uno script
shell o Perl, o un documento), si cambi questo valore in
"all", e si legga in seguito in Il
file rules
, Sezione 4.4 riguardo l'utilizzo della regola
binary-indep al posto di binary-arch per costruire il
pacchetto.
La riga 11 mostra una delle caratteristiche più potenti del sistema di pacchettizzazione Debian. Ovvero la possibilità di creare vari tipi di relazioni tra i pacchetti. A parte la già nota relazione Depends, le altre sono Recommends, Suggests, Pre-Depends, Conflicts, Provides, e Replaces.
Gli strumenti di gestione dei pacchetti solitamente si comportano allo stesso
modo quando si occupano di tali relazioni; in caso contrario, il comportamento
verrà spiegato. (si legga dpkg(8)
, dselect(8)
,
apt(8)
, aptitude(1)
ecc.)
Questo è il significato delle relazioni:
Depends
Il pacchetto non verrà installato a meno che tutti i pacchetti da cui dipende vengono installati. Si usi questa relazione se il programma non funzionerà assolutamente (o sarà praticamente inutilizzabile) a meno della presenza di particolari pacchetti.
Recommends
Si usi questa relazione per pacchetti che non sono strettamente necessari ma
sono solitamente utilizzati dal programma. Quando un utente installa il
programma, tutte le interfacce probabilmente chiederanno l'installazione dei
pacchetti raccomandati. aptitude
e apt-get
installano i pacchetti raccomandati insieme al pacchetto principale (ma
l'utente può disabilitare questo comportamento predefinito).
dpkg
ignorerà questo campo.
Suggests
Si usi questa relazione per pacchetti che funzionano bene con il programma ma
non sono per niente necessari. Quando un utente installa il programma, tutte
le interfacce probabilmente chiederanno l'installazione dei pacchetti
consigliati. aptitude
può essere configurato per installare i
pacchetti consigliati insieme al pacchetto principale ma questo non è il
comportamento predefinito. dpkg
ed apt-get
ignoreranno questo campo.
Pre-Depends
Questa relazione è più forte di Depends. Il pacchetto non
verrà installato a meno che i pacchetti da cui pre-dipende sono stati
installati e correttamente configurati. Si usi questa relazione con
molta parsimonia e solo dopo averne discusso sulla mailing list
debian-devel@lists.debian.org
. Leggasi: non utilizzarla affatto. :-)
Conflicts
Il pacchetto non verrà installato a meno che tutti i pacchetti con i quali va in conflitto siano rimossi. Si usi questa relazione se il programma non funzionerà o causerà gravi problemi se un certo pacchetto è presente.
Breaks
Il pacchetto verrà installato, mentre tutti gli altri pacchetti saranno marcati come "guasti". Normalmente la voce Breaks si ha per via della clausola di versione "prima di". Per risolvere il problema, generalmente, basta aggiornare la lista dei pacchetti utilizzando uno strumento di gestione di alto livello, del sistema di pacchettizzazione.
Provides
Per alcuni tipi di pacchetto in cui vi sono molteplici alternative sono stati
definiti dei nomi virtuali. Si può trovare la lista completa nel file
/usr/share/doc/debian-policy/virtual-package-names-list.txt.gz
.
Si usi questa relazione se il programma fornisce la funzione di un pacchetto
virtuale esistente.
Replaces
Si usi questa relazione quando il programma rimpiazza i file di un altro pacchetto, o lo rimpiazza completamente (utilizzato in congiunzione con Conflicts). I file dei pacchetti indicati saranno sovrascritti con i file del nuovo pacchetto.
Tutti i campi qui descritti hanno una sintassi uniforme. Sono costituiti da una lista contenente i nomi dei pacchetti separati da virgole. Questi possono essere anche costituiti da liste di nomi di pacchetto alternativi, separati da barre verticali "|" (simboli pipe).
I campi possono limitare la loro applicabilità a particolari versioni di ogni pacchetto indicato. Queste versioni sono elencate tra parentesi dopo ogni singolo nome di pacchetto, e dovrebbero contenere una relazione presa dalla lista qui sotto seguita dal numero di versione. Le relazioni permesse sono: <<, <=, =, >= e >> per strettamente inferiore, inferiore o uguale, esattamente uguale, superiore o uguale e strettamente superiore, rispettivamente. Per esempio,
Depends: foo (>= 1.2), libbar1 (= 1.3.4) Conflicts: baz Recommends: libbaz4 (>> 4.0.7) Suggests: quux Replaces: quux (<< 5), quux-foo (<= 7.6)
L'ultima caratteristica che si deve conoscere riguarda
${shlibs:Depends}, ${perl:Depends},
${misc:Depends}, ecc. Queste voci sono sostituite dalle liste
generate da altri componenti di debhelper
quando il comando
dh_gencontrol(1)
viene eseguito.
dh_shlibdeps(1)
farà la scansione alla ricerca di binari e
librerie per determinare le loro dipendenze da altre librerie e individuare in
quali pacchetti si trovano, come libc6
o xlib6g
, dopo
che il pacchetto sia stato costruito ed installato nella directory temporanea.
Questa lista di dipendenze di libreria condivise è utilizzata per
${shlibs:Depends}.
La lista di pacchetti generata da dh_perl(1)
viene utilizzata per
${perl:Depends}.
Alcuni comandi debhelper
possono far si che il pacchetto generato
abbia bisogno di dipendere da altri pacchetti. Questa lista di pacchetti
richiesti è utilizzata per ${misc:Depends}.
Avendo detto ciò, si può lasciare la riga Depends esattamente
come è ora, si può inserire un'altra riga dopo questa che dica
"Suggests: file", perché gentoo
può
utilizzare alcune caratteristiche fornite dal pacchetto file
.
La riga 12 contiene una breve descrizione del pacchetto. La maggioranza degli schermi degli utenti è larga 80 colonne quindi il contenuto non dovrebbe superare i 60 caratteri. Si cambia questo valore in "fully GUI-configurable, two-pane X file manager".
Nella riga 13 va messa la descrizione lunga. Questa dovrebbe consistere in un paragrafo che fornisce più dettagli sul pacchetto. La prima colonna di ogni riga dovrebbe essere vuota. Non ci dovrebbero essere linee vuote, ma si può mettere un singolo "." (punto) in una colonna per simularle. Inoltre non ci dovrebbe essere più di una linea vuota dopo questa descrizione.
Si inseriscono quindi i campi Vcs-* documentati su Developer's
Reference, 6.2.5. 'Version Control System location'
tra la linea 6
e 7. Si supponga che il pacchetto gentoo
è posizionato nel
Debian Alioth Git Service su
git://git.debian.org/git/collab-maint/gentoo.git.
Infine, ecco come appare il file di controllo aggiornato:
1 Source: gentoo 2 Section: x11 3 Priority: optional 4 Maintainer: Josip Rodin <joy-mg@debian.org> 5 Build-Depends: debhelper (>= 7.0.5), xlibs-dev, libgtk1.2-dev, libglib1.2-dev 6 Standards-Version: 3.8.4 7 Vcs-Git: git://git.debian.org/git/collab-maint/gentoo.git 8 Vcs-browser: http://git.debian.org/?p=collab-maint/gentoo.git 9 Homepage: http://www.obsession.se/gentoo/ 10 11 Package: gentoo 12 Architecture: any 13 Depends: ${shlibs:Depends}, ${misc:Depends} 14 Suggests: file 15 Description: fully GUI-configurable, two-pane X file manager 16 gentoo is a two-pane file manager for the X Window System. gentoo lets the 17 user do (almost) all of the configuration and customizing from within the 18 program itself. If you still prefer to hand-edit configuration files, 19 they're fairly easy to work with since they are written in an XML format. 20 . 21 gentoo features a fairly complex and powerful file identification system, 22 coupled to a object-oriented style system, which together give you a lot 23 of control over how files of different types are displayed and acted upon. 24 Additionally, over a hundred pixmap images are available for use in file 25 type descriptions. 26 . 29 gentoo was written from scratch in ANSI C, and it utilises the GTK+ toolkit 30 for its interface.
(Sono stati aggiunti i numeri di riga.)
copyright
Questo file contiene le informazioni sulle risorse del pacchetto, il copyright
e la licenza. Il suo formato non è definito dal Manuale delle policy di
Debian, ma il contenuto si trova in (Manuale
delle policy di Debian, 12.5 'Informazioni di copyright'
). Si può
anche consultare DEP-5:
Machine-parseable debian/copyright
.
dh_make
può fornire un modello di file del
copyright
, basta utilizzare l'opzione --copyright per
selezionare quello giusto, se si desidera rilasciare il pacchetto
gentoo
sotto licenza GPL-2.
Si devono inserire le informazioni mancanti per completare questo file, come la
fonte utilizzata per recuperare il pacchetto, le informazioni attuali di
copyright e la licenza. Per le licenze più comuni relative al software libero
come, GNU GPL-1, GNU GPL-2, GNU GPL-3, LGPL-2, LGPL-2.1, LGPL-3, GNU FDL-1.2,
GNU FDL-1.3, Apache-2.0 o la licenza Artistic, è possibile fare riferimento al
file appropriato nella directory /usr/share/common-licenses/
presente su ogni sistema Debian. In alternativa è necessario includere la
licenza completa.
Brevemente, ecco come il file di copyright
del pacchetto
gentoo
dovrebbe apparire:
1 Format-Specification: http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file&rev=135 2 Name: gentoo 3 Maintainer: Josip Rodin <joy-mg@debian.org> 4 Source: http://sourceforge.net/projects/gentoo/files/ 5 6 Copyright: 1998-2010 Emil Brink <emil@obsession.se> 7 License: GPL-2+ 8 9 Files: icons/* 10 Copyright: 1998 Johan Hanson <johan@tiq.com> 11 License: GPL-2+ 12 13 Files: debian/* 14 Copyright: 1998-2010 Josip Rodin <joy-mg@debian.org> 15 License: GPL-2+ 16 17 License: GPL-2+ 18 This program is free software; you can redistribute it and/or modify 19 it under the terms of the GNU General Public License as published by 20 the Free Software Foundation; either version 2 of the License, or 21 (at your option) any later version. 22 . 23 This program is distributed in the hope that it will be useful, 24 but WITHOUT ANY WARRANTY; without even the implied warranty of 25 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 26 GNU General Public License for more details. 27 . 28 You should have received a copy of the GNU General Public License along 29 with this program; if not, write to the Free Software Foundation, Inc., 30 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. 31 . 32 On Debian systems, the full text of the GNU General Public 33 License version 2 can be found in the file 34 `/usr/share/common-licenses/GPL-2'.
(Sono stati aggiunti i numeri di riga.)
Si prega di seguire l'HOWTO fornito da ftpmasters ed inviato a
debian-devel-announce: http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html
.
changelog
Questo è un file obbligatorio, che ha un formato speciale descritto nel
Manuale
delle policy di Debian, 4.4 'debian/changelog'
. Questo formato è
utilizzato da dpkg
ed altri programmi per ottenere il numero di
versione, revisione, distribuzione ed urgenza del pacchetto.
Tale file è anche utile allo scopo di aver documentato tutti i cambiamenti che
sono stati fatti. Sarà inoltre d'aiuto agli utenti che scaricano il pacchetto
per vedere se ci sono problemi di cui dovrebbero essere al corrente. Il file
verrà salvato come /usr/share/doc/gentoo/changelog.Debian.gz
nel
pacchetto binario.
dh_make
ne crea uno predefinito, ecco come appare:
1 gentoo (0.9.12-1) unstable; urgency=low 2 3 * Initial release (Closes: #nnnn) <nnnn is the bug number of your ITP> 4 5 -- Josip Rodin <joy-mg@debian.org> Mon, 22 Mar 2010 00:37:31 +0100 6
(Sono stati aggiunti i numeri di riga.)
La riga 1 indica il nome del pacchetto, la versione, la distribuzione e l'urgenza. Il nome deve corrispondere al nome del pacchetto sorgente, mentre la distribuzione dovrebbe essere unstable (o anche experimental) [17] , e l'urgenza non dovrebbe essere cambiata in qualcosa di più alto di low. :-)
Le righe 3-5 sono una voce del registro, in cui vengono documentati i
cambiamenti fatti nella revisione del pacchetto (non dei cambiamenti del
pacchetto originario - c'è un file apposta per questo scopo, creato dagli
autori originali, che verrà installato successivamente
/usr/share/doc/gentoo/changelog.gz
). Supponiamo che il numero di
servizio del ticket ITP fosse "12345". Nuove righe
devono essere aggiunte appena prima della riga più in alto che comincia con
"*" (asterisco). Ciò si può fare con
dch(1)
, o manualmente con un editor testuale.
Alla fine si avrà qualcosa del genere:
1 gentoo (0.9.12-1) unstable; urgency=low 2 3 * Initial Release. Closes: #12345 4 * This is my first Debian package. 5 * Adjusted the Makefile to fix $(DESTDIR) problems. 6 7 -- Josip Rodin <joy-mg@debian.org> Mon, 22 Mar 2010 00:37:31 +0100 8
(Sono stati aggiunti i numeri di riga.)
Si possono leggere ulteriori informazioni sull'aggiornamento del file changelog successivamente in Aggiornamento del pacchetto, Capitolo 9.
rules
Ora si darà uno sguardo alle regole esatte che
dpkg-buildpackage(1)
userà per creare il pacchetto. In realtà
questo file non è che un altro Makefile
, ma diverso da quelli
della sorgente originale. Differentemente dagli altri file sotto
debian
, questo qui è marcato come eseguibile.
rules
Ogni file rules
, come qualsiasi altro Makefile
,
consiste di diversi obiettivi e regole che specificano come gestire il
sorgente. Manuale
delle policy di Debian, 4.9 'Script principale per la creazione:
debian/rules'
ne spiega i dettagli.
La spiegazione breve degli obiettivi è la seguente.
obiettivo clean: ripulire tutti i file compilati, generati ed inutili nella struttura di cartelle del pacchetto. (richiesto)
obiettivo build: costruire tutti i sorgenti per ottenere programmi compilati e documenti formattati nell'albero delle cartelle del pacchetto. (richiesto)
obiettivo install: installare i file in una struttura ad albero
per ogni pacchetto binario nella directory debian
. Se definito,
tutti gli obiettivi binary* dipenderanno effettivamente da
quest'ultimo. (opzionale)
obiettivo binary: creare tutta una serie di pacchetti binari (combinando gli obiettivi binary-arch e binary-indep). (richiesto)[18]
obiettivo binary-arch: creare una serie di pacchetti binari dipendenti dall'architettura (Architecture: any) nella directory padre. (richiesto)[19]
obiettivo binary-indep: creare una serie di pacchetti binari indipendenti dall'architettura (Architecture: all) nella directory padre. (richiesto)[20]
obiettivo get-orig-source: ottenere la versione più recente del pacchetto sorgente originale dal relativo sito. (optional)
Le regole che si vogliono applicare vengono applicate come parametri da linea di comando (per esempio, "./debian/rules build" o "fakeroot make -f debian/rules binary"). Dopo il nome dell'obiettivo si può scrivere il nome della dipendenza, programma o file da cui dipende la regola. Dopo aver fatto questo ci può essere un qualsiasi numero di comandi, separati da TAB. Una nuova regola comincia con la dichiarazione dell'obiettivo nella prima colonna. Le righe vuote e le righe che cominciano con "#" (cancelletto) vengono trattate come commenti e rimosse.
È probabile che adesso ci sia un po' di confusione, ma sarà tutto più chiaro
una volta esaminato il file rules
che dh_make
fornisce in modo predefinito. Inoltre si consiglia di leggere "info
make" per maggiori informazioni.
rules
predefinito
Le nuove versioni di dh_make
generano un file rules
molto semplice ma potente utilizzando il comando dh
:
1 #!/usr/bin/make -f 2 # -*- makefile -*- 3 # Sample debian/rules that uses debhelper. 4 # This file was originally written by Joey Hess and Craig Small. 5 # As a special exception, when this file is copied by dh-make into a 6 # dh-make output file, you may use that output file without restriction. 7 # This special exception was added by Craig Small in version 0.37 of dh-make. 8 9 # Uncomment this to turn on verbose mode. 10 #export DH_VERBOSE=1 11 12 %: 13 dh $@
(Sono stati aggiunti i numeri di riga. Nel vero file rules
, gli
spazi vengono sostituiti da TAB.)
Probabilmente si sarà già familiari con le righe tipo la prima che ricordano
gli script shell e Perl. In pratica indica al sistema operativo che il file
andrà elaborato con /usr/bin/make
.
La riga 10 può essere decommentata per impostare la variabile
DH_VERBOSE ad 1. In tal caso, lo strumento debhelper
fornirà più informazioni come risultato. Questo aiuta a capire cosa stia
succedendo dietro questo semplice file rules
ed ad analizzarne i
problemi. Questo nuovo comando dh
è una parte cruciale dello
strumento debhelper
e non nasconde nulla all'utente.
Tutto il lavoro è svolto nelle righe 12 e 13. Il simbolo della percentuale
significa che ogni target esegue una chiamata ad un singolo programma,
dh
con il nome del terget stesso. [21] Il comando dh
è
uno script wrapper, che esegue una sequenza appropriata di programmi
dh_*
in base all'argomento passato. [22]
"debian/rules clean" esegue "dh clean"; che a sua volta esegue i seguenti:
dh_testdir dh_auto_clean dh_clean
"debian/rules build" esegue "dh build"; che a sua volta esegue i seguenti:
dh_testdir dh_auto_configure dh_auto_build dh_auto_test
"fakeroot debian/rules binary" esegue "fakeroot dh binary"; che a sua volta esegue i seguenti[23]:
dh_testroot dh_prep dh_installdirs dh_auto_install dh_install dh_installdocs dh_installchangelogs dh_installexamples dh_installman dh_installcatalogs dh_installcron dh_installdebconf dh_installemacsen dh_installifupdown dh_installinfo dh_pysupport dh_installinit dh_installmenu dh_installmime dh_installmodules dh_installlogcheck dh_installlogrotate dh_installpam dh_installppp dh_installudev dh_installwm dh_installxfonts dh_bugfiles dh_lintian dh_gconf dh_icons dh_perl dh_usrlocal dh_link dh_compress dh_fixperms dh_strip dh_makeshlibs dh_shlibdeps dh_installdeb dh_gencontrol dh_md5sums dh_builddeb
"fakeroot debian/rules binary-arch" esegue "fakeroot dh binary-arch"; che a sua volta esegue la stessa sequenza di "fakeroot dh binary" ma con l'opzione "-a" aggiunta ad ogni comando.
"fakeroot debian/rules binary-indep" esegue
"fakeroot dh binary-indep"; che a sua volta esegue la
stessa sequenza di "fakeroot dh binary" ma escludendo
dh_strip
, dh_makeshlibs
, e dh_shlibdeps
con l'opzione "-i" aggiunta ad ogni comando rimanente.
Le funzioni dei comandi dh_*
sono quasi auto-esplicative dai loro
nomi. [24] Ci sono una serie
di appunti da fare in questa spiegazione semplificata che assume un ambiente di
costruzione tipico basato su Makefile
. [25]
dh_auto_clean
normalmente esegue i seguenti comandi se nel
Makefile
è presente il target distclean.[26]
make distclean
dh_auto_configure
normalmente esegue i seguenti comandi se esiste
il file ./configure
(argomenti abbreviati for una maggiore
leggibilità).
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var ...
dh_auto_build
normalmente lancia il seguente comando per eseguire,
se esiste, il primo obiettivo del Makefile
.
make
dh_auto_clean
normalmente esegue i seguenti comandi con
l'obiettivo distclean se esiste il file Makefile
.[27]
make test
dh_auto_install
normalmente esegue il seguente comando con
l'obiettivo install se esiste il file Makefile
(riga
spezzata per aumentare la leggibilità).
make install \ DESTDIR=/path/to/package_version-revision/debian/package
Gli obiettivi che richiedono il comando fakeroot
contengono
dh_testroot
. Se non si sta fingendo di essere root utilizzando
questo comando, questo terminerà con un errore.
La cosa importante da sapere riguardo al file rules
creato da
dh_make
, è che il suo contenuto contiene dei semplici consigli.
Funzionerà per la maggior parte dei pacchetti ma per i più complicati non si
esiti a personalizzarlo secondo le proprie esigenze. Le uniche cose che non
vanno cambiate sono i nomi delle regole, perché tutti gli strumenti utilizzano
questi nomi, così come è indicato dalle policy di Debian.
Anche se l'obiettivo "install" non è richiesto, è
comunque supportato. "fakeroot dh install" si comporta
come "fakeroot dh binary" ma si ferma dopo
dh_fixperms
.
rules
Verrà qui spiegata la personalizzazione del file rules
, creato
con il nuovo comando dh
.
Il comando "dh $@" può essere personalizzato come segue. [28]
Aggiunge il supporto per il comando dh_pysupport
. (La scelta
migliore per Python) [29]
Installa il pacchetto python-support
in
Build-Depends".
Utilizza "dh $@" normalmente. (Questo è abilitato in modo predefinito)
Gestisce i moduli Python utilizzando l'infrastruttura
python-support
.
Aggiunge il supporto al comando dh_pycentral
.
Installa il pacchetto python-central
in
"Build-Depends".
Utilizza in alternativa "dh --with python-central $@"
Disattiva anche il domando dh_pysupport
Gestisce i moduli Python utilizzando l'infrastruttura
python-central
.
Aggiunge il supporto al comando dh_installtex
Installa il pacchetto tex-common
in
"Build-Depends".
Utilizza in alternativa "dh --with tex $@"
Registra i caratteri Type 1, le regole di sillabazione, o i formati con TeX.
Aggiunge il supporto ai comandi dh_quilt_patch
e
dh_quilt_unpatch
.
Installa il pacchetto quilt
in
"Build-Depends".
Utilizza in alternativa "dh --with quilt $@"
Applica e rimuove le patch al sorgente originale dai file nella directory
debian/patches
per i sorgenti dei pacchetti 1.0.
Non è necessario se si utilizza il nuovo sorgente del pacchetti 3.0 (quilt).
Aggiunge il supporto al comando dh_dkms
.
Installa il pacchetto dkms
in
"Build-Depends".
Utilizza in alternativa "dh --with dkms $@".
Gestisce in maniera corretta DKMS, usato dal pacchetto del modulo del kernel.
Aggiunge il supporto ai comandi dh_autotools-dev_updateconfig
e
dh_autotools-dev_restoreconfig
.
Installa il pacchetto autotools-dev
in
"Build-Depends".
Utilizza in alternativa "dh --with autotools-dev $@".
Aggiorna e ripristina i file config.sub
and
config.guess
.
Aggiunge il supporto ai comandi dh_autoreconf
e
dh_autoreconf_clean
.
Installa il pacchetto dh-autoreconf
in
"Build-Depends".
Utilizza in alternativa "dh --with autoreconf $@".
Aggiorna i file del sistema di compilazione GNU e ripristina i file dopo la sua compilazione.
Aggiunge il supporto alla funzionalità di completamento di bash
Installa il pacchetto bash-completion
in
"Build-Depends".
Utilizza in alternativa "dh --with bash-completion $@".
Installa il completamento per bash
utilizzando il file di
configurazione debian/package.bash-completion
.
Per i sorgenti che utilizzano Autotools, utilizzare il comando "dh --with autotools-dev --with autoreconf $@" per essere aggiornati con il sistema di compilazione GNU.
Molti comandi del tipo dh_*
, invocati da dh
, possono
essere personalizzati modificando i rispettivi file di configurazione nella
directory debian
. Si veda Altri file
nella directory debian
, Capitolo 5 per la personalizzazione di
tali caratteristiche.
Alcuni comandi del tipo dh_*
, invocati da dh
, possono
richiedere la propria esecuzione con alcuni parametri o in aggiunta ad altri
comandi da eseguire contestualmente o al posto dei comandi originali. In tali
casi viene creato nel file rules
l' obiettivo
override_dh_foo aggiungendo una regola solo per il
comando dh_foo
che si intende modificare.
Fondamentalmente tale regola dice "esegui me al posto di".
[30]
Si noti che i comandi dh_auto_*
tendono a fare più di quanto si
sia qui illustrato in questa ultra-semplificata spiegazione per tenere in conto
tutti casi limite. L'utilizzo di comandi semplificati nell'obiettivo
override_dh_* è una cattiva idea in quanto potrebbe annullare
molte delle caratteristiche utili di debhelper
.
Se si vogliono registrare i dati di configurazione di sistema del pacchetto
gentoo
nella directory /etc/gentoo
invece che nella
solita directory /etc
, si può sovrascrivere il parametro
predefinito --sysconfig=/etc dato dal comando
dh_auto_configure
al comando ./configure
nel modo
seguente. [31]
override_dh_auto_configure: dh_auto_configure -- --sysconfig=/etc/gentoo
I parametri immessi dopo -- vengono aggiunti dopo i parametri
predefiniti dei programmi eseguiti pr sovrascriverli. Utilizzare il comando
dh_auto_configure
è preferibile rispetto al comando
./configure
dal momento che sovrascriverà esclusivamente il
parametro --sysconfig e manterrà gli altri parametri del comando
./configure
.
Se il Makefile
del sorgente per il pacchetto gentoo
necessita che venga specificato l'obiettivo build per essere
costruito [32], basterà creare
l'obiettivo override_dh_auto_build pe abilitarlo.
override_dh_auto_build: dh_auto_build -- build
Questo ci assicura che $(MAKE) verrà eseguito con tutti i parametri
predefiniti del comando dh_auto_build
ed il parametro di
build.
Se il Makefile
del sorgente di gentoo
necessita che
venga specificato il target packageclean per la pulizia del
pacchetto Debian al posto dei target distclean o
clean, basterà creare un target
override_dh_auto_clean per abilitarlo.
override_dh_auto_clean: $(MAKE) packageclean
Se il Makefile
di un sorgente per il pacchetto gentoo
contiene l'obiettivo test che non vuole essere eseguito nel
processo di costruzione del pacchetto Debian, si può utilizzare l'obiettivo
override_dh_auto_test per saltarlo.
override_dh_auto_test:
Se il programma originale gentoo
contiene un inusuale file di
changelog chiamato FIXES
, dh_installchangelogs
non
installerà questo file in modo predefinito. Il comando
dh_installchangelogs
richiede che venga fornito il parametro
FIXES
per installarlo.[33]
override_dh_installchangelogs: dh_installchangelogs FIXES
Quando si usa il nuovo comando dh
, l'utilizzo di target espliciti
come quelli elencanti in Obiettivi del file
rules
, Sezione 4.4.1, tranne il target
get-orig-source, possono rendere difficile capire i loro effettivi
effetti. Si prega di limitare i target espliciti in favore dei target
override_dh_* e, se possibile, quelli completamente indipendenti.
[ precedente ] [ Contenuti ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ successivo ]
Guida per il nuovo Maintainer
version 1.2.25, 2010-12-22 12:44:34 UTCjoy-mg@debian.org
kalos@nerdrug.org
jacopo.reggiani@gmail.com