[ precedente ] [ Contenuti ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ A ] [ successivo ]


Guida per il nuovo Maintainer
Capitolo 4 - Materiale richiesto sotto debian/


C'è adesso una nuova sotto-directory nella directory principale del programma (`gentoo-0.9.12'), il cui nome è `debian'. Ci sono un certo numero di file in questa directory che dovremo modificare allo scopo di adattare il comportamento del pacchetto. I più importati fra loro sono `control', `changelog', `copyright' e 'rules', che sono richiesti per tutti i pacchetti.


4.1 Il file `control'

Questo file contiene vari valori che dpkg, dselect e altri pacchetti useranno per la gestione del pacchetto.

Questo è il file control che dh_make crea per noi.

       1  Source: gentoo
       2  Section: unknown
       3  Priority: optional
       4  Maintainer: Josip Rodin <joy-mg@debian.org>
       5  Build-Depends: debhelper (>> 3.0.0)
       6  Standards-Version: 3.5.2
       7
       8  Package: gentoo
       9  Architecture: any
       10 Depends: ${shlibs:Depends}
       11 Description: <insert up to 60 chars description>
       12  <insert long description, indented with spaces>

(I numeri di riga sono aggiunti).

Le righe 1-6 sono le informazioni di controllo per il pacchetto sorgente.

La riga 1 è il nome del pacchetto sorgente.

La riga 2 è la sezione della distribuzione in cui il pacchetto è incluso.

Come ti sarai reso conto, Debian è diviso in sezioni: main (il software free), non-free (il software non esattamente free) e contrib (software free che dipende da software non free). Al di sotto di queste ci sono delle sotto-sezioni logiche che descrivono in breve di che genere di pacchetto si tratta. Così abbiamo `admin' per programmi da amministratore, `base' per gli strumenti di base, `devel' per gli strumenti per programmatori, `doc' per la documentazione, `libs' per le librerie, `mail' per programmi e demoni di posta elettronica, `net' per applicazioni e demoni di rete, `x11' per programmi specifici per X11, e molte altre.

Modifichiamo quindi la sezione in x11. (Un prefisso "main/" è implicito per cui lo omettiamo.)

La riga 3 descrive quanto sia importante che l'utente installi tale pacchetto. Leggi il manuale della Policy per una guida su come configurare questi campi. La priorità "optional" generalmente funzionerà per nuovi pacchetti.

Sezioni e priorità sono usati effettivamente solo da dselect dselect quando ordina i pacchetti e seleziona i default. Una volta caricato il pacchetto in Debian, il valore di questi due campi possono essere modificati dai maintainer dell'archivio FTP, nel qual caso ne sarai informato via email.

Dal momento che si tratta di un pacchetto a priorità normale, lasciamo il campo al valore "optional".

La riga 4 è nome e e-mail del maintainer. Assicurati che questo campo contenga un campo "To: " valido per una email, perché dopo averlo caricato il sistema di tracciamento delle anomalie lo userà per inviarti le email relativi a errori. Evita l'uso di virgole, '&' e parentesi.

La riga 5 è la versione degli standard di Debian Policy che questo pacchetto segue, la versione del manuale di Policy che leggi mentre costruisci i pacchetti.

La sesta riga include la lista dei pacchetti richiesti per creare il tuo pacchetto. Alcuni pacchetti come gcc e make sono impliciti, vedi il pacchetto build-essential per dettagli. Se qualche compilatore non standard o altri strumenti sono necessari per compilare il tuo pacchetto, dovresti aggiungerlo alla riga `Build-Depends'. Valori multipli sono separati con virgole; leggi più avanti la spiegazione delle dipendenze binarie per saperne di più della sintassi di questo campo.

Qui puoi anche avere Build-Depends-Indep, Build-Conflicts e altri campi. Questi dati saranno usati dal software di costruzione automatica dei pacchetti per creare pacchetti binari per altre piattaforme di computer. Vedi il manuale della Policy per altre informazioni sulle build-dependencies e la Guida di Riferimento dello Sviluppatore per informazioni su tali piattaforme (architetture) e come portare il software su di esse.

Ecco un trucco che puoi usare per trovare quali pacchetti il tuo pacchetto richiede per la creazione:

       strace -f -o /tmp/log ./configure
       # o make invece di ./configure, se il pacchetto non usa autoconf
       for x in `dpkg -S $(grep open /tmp/log|\
                           perl -pe 's!.* open\(\"([^\"]*).*!$1!' |\
                           grep "^/"| sort | uniq|\
                           grep -v "^\(/tmp\|/dev\|/proc\)" ) 2>/dev/null|\
                           cut -f1 -d":"| sort | uniq`; \
             do \
               echo -n "$x (>=" `dpkg -s $x|grep ^Version|cut -f2 -d":"` "), "; \
             done

Per trovare manualmente le esatte dipendenze per la compilazione di /usr/bin/foo, esegui

       objdump -p /usr/bin/foo | grep NEEDED

e per ogni libreria elencata, per es. libfoo.so.6, esegui

       dpkg -S libfoo.so.6

A questo punto usa la versione -dev di ogni pacchetto come valore di `Build-deps'. Se usi ldd a questo scopo, ti verranno indicate anche tutte le librerie di dipendenza indiretta, col problema di un numero eccessivo di dipendenze per la compilazione.

Gentoo sembra richiedere xlibs-dev, libgtk1.2-dev e libglib1.2-dev per compilare, per cui li aggiungiamo dopo debhelper.

La riga 8 è il nome del pacchetto binario. Questo è generalmente lo stesso nome del sorgente, ma non deve necessariamente essere così.

La riga 9 descrive l'architettura di CPU per la quale il pacchetto binario è stato compilato. Possiamo lasciare il valore "any" perché dpkg-gencontrol(1) lo riempirà con il valore appropriato per qualsiasi macchina sulla quale questo pacchetto è stato compilato.

Se il tuo pacchetto è indipendente dalla architettura (per esempio, uno script di shell o Perl, o un documento) modifica questo campo in "all", e leggi oltre in Il file `rules', Sezione 4.4 sull'uso del metodo `binary-indep' invece di `binary-arch' per costruire un pacchetto.

La riga 10 mostra una della più potenti caratteristiche del sistema di pacchettizzazione Debian. I pacchetti possono far riferimento l'uno all'altro in vari modi. Oltre a Depends:, altri campi di relazione sono Recommends:, Suggests:, Pre-Depends:, Conflicts:, Provides:, e Replaces:.

Gli strumenti di gestione dei pacchetti generalmente si comportano nello stesso modo quando trattano queste relazioni; se così non è, viene spiegato. (vedi dpkg(8), dselect(8), apt(8), aptitude(1) ecc.)

Questo è ciò che le dipendenze significano:

Tutti questi campi hanno una sintassi uniforme. Sono una lista di nomi di pacchetti separati da virgole. Questi nomi di pacchetti possono anche essere liste di nomi di pacchetti alternativi, separati da una barra verticale | (simbolo di pipe).

Questi campi possono restringere la propria applicabilità a una particolare versione di ciascun pacchetto. Tali versioni sono elencate in parentesi dopo ogni nome di pacchetto, e dovrebbero contenere una relazione fra le possibili qui in elenco, seguita da un numero di versione. Le relazioni consentite sono: <<, <=, =, >= e >> che stanno per strettamente precedente, precedente o uguale, esattamente uguale, successiva o uguale, e strettamente successiva, 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 hai necessità di conoscere è $(shlibs:Depends). Dopo che il tuo pacchetto sarà stato generato e installato nella directory temporanea, dh_shlibdeps(1) lo esaminerà alla ricerca di binari e librerie, determinerà le dipendenze da librerie condivise e stabilirà in quali pacchetti queste si trovano, come libc6 o xlib6g. Questo programma passerà la lista a dh_gencontrol(1) che li metterà al posto giusto, e tu non dovrai preoccuparti di specificarle da solo.

Detto ciò possiamo lasciare la riga Depends: come è ora, e inserire un'altra riga dopo questa che dice Suggests: file, perchè gentoo può usare alcune funzionalità offerte da quel programma/pachetto.

La riga 12 è una breve descrizione. Gli schermi di molte persone sono larghi 80 colonne, per cui non dovrebbe essere di più di 60 caratteri. Modificherai tale campo in "fully GUI configurable X file manager using GTK+".

La riga 13 contiene una descrizione estesa. Dovrebbe essere un paragrafo dove vengono dati più dettagli sul pacchetto. La colonna 1 di ogni riga dovrebbe essere vuota. Non ci devono essere righe vuote in mezzo, ma puoi mettere un . (punto) in una colonna, per simularle. Inoltre, non ci deve essere più di una riga vuota dopo la descrizione.

Questo è il file control aggiornato:

       1  Source: gentoo
       2  Section: x11
       3  Priority: optional
       4  Maintainer: Josip Rodin <joy-mg@debian.org>
       5  Build-Depends: debhelper (>> 3.0.0), xlibs-dev, libgtk1.2-dev, libglib1.2-dev
       6  Standards-Version: 3.5.2
       7
       8  Package: gentoo
       9  Architecture: any
       10 Depends: ${shlibs:Depends}
       11 Suggests: file
       12 Description: fully GUI configurable GTK+ file manager
       13  gentoo is a file manager for Linux written from scratch in pure C. It
       14  uses the GTK+ toolkit for all of its interface needs. gentoo provides
       15  100% GUI configurability; no need to edit config files by hand and re-
       16  start the program. gentoo supports identifying the type of various
       17  files (using extension, regular expressions, or the 'file' command),
       18  and can display files of different types with different colors and icons.
       19  .
       20  gentoo borrows some of its look and feel from the classic Amiga file
       21  manager "Directory OPUS" (written by Jonathan Potter).

(Ho aggiunto i numeri di riga.)


4.2 Il file `copyright'

Questo file contiene le informazioni sui riferimenti, copyright e licenza del pacchetto upstream. Il suo formato non è dettato dalla Policy, ma i contenuti lo sono (sezioni 13.6 "Informazioni di Copyright").

dh_make ne ha creato uno di default, quello di seguito:

       1  This package was debianized by Josip Rodin <joy-mg@debian.org> on
       2  Wed, 11 Nov 1998 21:02:14 +0100.
       3
       4  It was downloaded from <fill in ftp site>
       5
       6  Upstream Author(s): <put author(s) name and email here>
       7
       8  Copyright:
       9
       10 <Must follow here>

(Ho aggiunto i numeri di riga.)

Le cose importanti da aggiungere a questo file sono l'indirizzo da cui il pacchetto è stato preso e l'effettiva nota di copyright e licenza. Devi includere la licenza completa, a meno che non sia una delle comuni licenze di free software, come la GNU GPL o LGPL, la BSD o l'Artistic, nel quale caso puoi semplicemente fare riferimento all'opportuno file in /usr/share/common-licenses/ che esiste su tutti i sistemi Debian.

In breve, ecco come il file copyright di gentoo appare:

       1  This package was debianized by Josip Rodin <joy-mg@debian.org> on
       2  Wed, 11 Nov 1998 21:02:14 +0100.
       3
       4  It was downloaded from: ftp://ftp.obsession.se/gentoo/
       5
       6  Upstream author: Emil Brink <emil@obsession.se>
       7
       8  This software is copyright (c) 1998-99 by Emil Brink, Obsession
       9  Development.
       10
       11 You are free to distribute this software under the terms of
       12 the GNU General Public License.
       13 On Debian systems, the complete text of the GNU General Public
       14 License can be found in /usr/share/common-licenses/GPL file.

(Ho aggiunto i numeri di riga.)


4.3 Il file `changelog'

Questo è un file obbligatorio, che ha un formato speciale descritto nella Policy alla sezione 4.4 "debian/changelog". Tale formato è usato da dpkg e altri programmi per ricavare il numero di versione, revisione, distribuzione e livello di urgenza del tuo pacchetto.

Per te è ugualmente importante dal momento che è una buona cosa aver documentato tutte le modifiche apportate. Questo aiuterà chi scarica il tuo pacchetto a vedere velocemente se ci sono problemi non risolti con il pacchetto, che dovrebbe sapere. Sarà salvato come `/usr/share/doc/gentoo/changelog.Debian.gz' nel pacchetto binario.

dh_make ne crea uno di default, che appare così:

       1  gentoo (0.9.12-1) unstable; urgency=low
       2
       3   * Initial Release.
       4
       5  -- Josip Rodin <joy-mg@debian.org> Wed, 11 Nov 1998 21:02:14 +0100
       6
       7  Local variables:
       8  mode: debian-changelog
       9  End:

(Ho aggiunto i numeri di riga.)

La riga 1 è il nome del pacchetto, versione, distribuzione e livello di urgenza. Il nome deve corrispondere al nome del pacchetto sorgente, la distribuzione dovrebbe essere `unstable' o `experimental' (per ora), e il livello non dovrebbe essere modificato in qualcosa maggiore di `low'. :-).

Le righe 3-5 sono voci di log, dove documenti le modifiche fatte nella revisione del pacchetto (non le modifiche di upstream - c'è un file speciale a tale scopo, creato dall'autore di upstream, installato come /usr/share/doc/gentoo/changelog.gz). Le nuove righe devono essere inserite prima della riga più in alto, che inizia con un asterisco (`*'). Puoi farlo con dch(1), emacs(1) o a mano con un editor di testo.

Devi metterci qualcosa di questo genere:

       1  gentoo (0.9.12-1) unstable; urgency=low
       2
       3   * Initial Release.
       4   * This is my first Debian package.
       5   * Adjusted the Makefile to fix $DESTDIR problems.
       6
       7  -- Josip Rodin <joy-mg@debian.org> Wed, 11 Nov 1998 21:02:14 +0100
       8

(Ho aggiunto i numeri di riga.)

Puoi leggere altro sull'aggiornamento del file changelog più oltre in Aggiornamento del pacchetto, Capitolo 9.


4.4 Il file `rules'

Ora occorre dare una occhiata alle regole esatte che dpkg-buildpackage(1) userà per creare effettivamente il pacchetto. Questo file è in effetti un altro Makefile, ma diverso da quello dei sorgenti upstream. Diversamente da altri file in debian/, questo è marcato come eseguibile.

Tutti i file `rules', come ogni Makefile, consistono di diverse regole che specificano come gestire i sorgenti. Ogni regola consiste di target e nomi di file o nomi di azione che devono essere intraprese (per es. `build:' o `install:'.) Le regole che tu vuoi siano eseguite sono invocate come argomenti a riga di comando (per esempio, `./debian/rules build' o `make -f rules install'.) Dopo il nome del target, puoi fornire i nomi delle dipendenze, il programma o file da cui dipende quella regola. A seguire, ci può essere un qualsiasi numero di comandi (indentati con <tab>!), finché si trova una riga vuota. Da quel punto inizia un'altra regola. Righe vuote multiple e linee che iniziano con `#' (hash) sono trattate come commenti e ignorate

Sarai probabilmente confuso ora, ma sarà tutto più chiaro dopo l'esame del file `rules' che dh_make fornisce come default. Dovresti anche leggere la voce `make' in info per maggiori informazioni.

La cosa importante da capire, a proposito del file rules creato da dh_make, è che si tratta solo di un suggerimento. Funzionerà per semplici pacchetti, ma per i più complicati non avere remore nell'aggiungere o togliere qualcosa ad esso, per accomodarlo alle tue necessità. L'unica cosa che non devi modificare sono i nomi delle regole, perché gli strumenti usano tutti gli stessi nomi, come richiesto dalla Policy.

Ecco (approssimativamente) come appare il file di default debian/rules che dh_make ha generato:

       1  #!/usr/bin/make -f
       2  # Sample debian/rules that uses debhelper.
       3  # GNU copyright 1997 to 1999 by Joey Hess.
       4
       5  # Uncomment this to turn on verbose mode.
       6  #export DH_VERBOSE=1
       7
       8  # This is the debhelper compatibility version to use.
       9  export DH_COMPAT=4
       10 
       11 CFLAGS = -g
       12 ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
       13 CFLAGS += -O0
       14 else
       15 CFLAGS += -O2
       16 endif
       17
       18 build: build-stamp
       19 build-stamp:
       20        dh_testdir
       21
       22        # Add here commands to compile the package.
       23        $(MAKE)
       24        #docbook-to-man debian/gentoo.sgml > gentoo.1
       25
       26        touch build-stamp
       27
       28 clean:
       29        dh_testdir
       30        dh_testroot
       31        rm -f build-stamp
       32
       33        # Add here commands to clean up after the build process.
       34        -$(MAKE) clean
       35
       36        dh_clean
       37
       38 install: build
       39        dh_testdir
       40        dh_testroot
       41        dh_clean -k
       42        dh_installdirs
       43
       44        # Add here commands to install the package into debian/gentoo.
       45        $(MAKE) install DESTDIR=$(CURDIR)/debian/gentoo
       46
       47 # Build architecture-independent files here.
       48 binary-indep: build install
       49 # We have nothing to do by default.
       50
       51 # Build architecture-dependent files here.
       52 binary-arch: build install
       53        dh_testdir
       54        dh_testroot
       55 #      dh_installdebconf
       56        dh_installdocs
       57        dh_installexamples
       58        dh_installmenu
       59 #      dh_installlogrotate
       60 #      dh_installemacsen
       61 #      dh_installpam
       62 #      dh_installmime
       63 #      dh_installinit
       64        dh_installcron
       65        dh_installman
       66        dh_installinfo
       67 #      dh_undocumented
       68        dh_installchangelogs ChangeLog
       69        dh_link
       70        dh_strip
       71        dh_compress
       72        dh_fixperms
       73 #      dh_makeshlibs
       74        dh_installdeb
       75 #      dh_perl
       76        dh_shlibdeps
       77        dh_gencontrol
       78        dh_md5sums
       79        dh_builddeb
       80
       81 binary: binary-indep binary-arch
       82 .PHONY: build clean binary-indep binary-arch binary install

(Ho aggiunto i numeri di riga.)

Hai probabilmente familiarità con righe come la prima, dagli script di shell e Perl. Essa dice al sistema operativo che questo file deve essere processato usando /usr/bin/make.

Il senso delle variabili DH_* menzionate alle righe 6 e 9 dovrebbe essere evidente dalla breve descrizione. Per maggiori informazioni su DH_COMPAT leggi la sezione "livelli di compatibilità di Debhelper" della debhelper(1)pagina di manuale.

Le righe da 11 a 16 sono schemi di supporto per i parametri DEB_BUILD_OPTIONS, descritti nella sezione 11.1 "Binari" della Policy. Di base queste cose controllano se i binari sono creati con i simboli per il debugging, e se questi possono essere eliminati al momento della installazione. Di nuovo, si tratta solo di uno schema, un suggerimento che dovresti seguire. Dovresti controllare come il sistema di compilazione dell'upstream gestisce l'inclusione di simboli di debugging e la loro cancellazione in installazione e implementare il tutto tu stesso.

Generalmente puoi dire al gcc di compilare con "-g" usando la variabile CFLAGS -- se questo è il caso del tuo pacchetto, propaga la variabile aggiungendo CFLAGS="$(CFLAGS)" alla chiamata $(MAKE) nella regola build (vedi oltre). In alternativa, se il tuo pacchetto usa uno script configure di autoconf, puoi passarlo a configure premettendo la suddetta stringa alla invocazione di ./configure nella regola di build.

A proposito di stripping, i programmi sono configurati comunemente per essere installati non strippati, e spesso senza una opzione per modificare questa cosa. Fortunatamente, hai anche dh_strip(1) che controllerà se il flag DEB_BUILD_OPTIONS=nostrip è configurato e terminerà silenziosamente.

Le righe dalla 18 alla 26 descrivono la regola `build' (e la figlia `build-stamp') che lanciano make con il Makefile proprio della applicazione per compilare il programma. Se il tuo pacchetto usa le utilità di configurazione GNU per creare i binari, assicurati assolutamente di leggere /usr/share/doc/autotools-dev/README.Debian.gz . Parleremo dell'esempio commentato docbook-to-man più avanti in manpage.1.ex, manpage.sgml.ex, Sezione 5.8.

La regola `clean', come specificata nelle righe 28-36, ripulisce ogni binario non necessario e file autogenerati, lasciati in giro dalla creazione del pacchetto. Questa regola deve lavorare tutte le volte (anche quando l'albero dei sorgenti è già ripulito!), per cui usa le opzioni di forzatura (per es. per rm, è -f), oppure fai in modo che make ignori i valori di ritorno (errori) usando un `-' prima del nome del comando.

Il processo di installazione, la regola `install', inizia a riga 38. Fondamentalmente lancia la regola `install' del Makefile del programma, ma installa nella directory $(CURDIR)/debian/gentoo - questo è il motivo per cui abbiamo specificato $(DESTDIR) come directory radice per l'installazione nel Makefile di gentoo.

Come suggeriscono i commenti, la regola `binary-indep', alla riga 48, è usata per costruire i pacchetti indipendenti dalla architettura. Dal momento che non ne abbiamo, non verrà fatto niente in questo caso.

Fino alla prossima regola - `binary-arch', dalla riga 52 alla 79, lanciamo una serie di piccoli programmi di utilità dal pacchetto debhelper che svolgono varie operazioni sui file del tuo pacchetto per renderlo conforme alla Policy.

Se il tuo pacchetto fosse del tipo `Architecture: all', avresti bisogno di includere tutti i comandi per costruire i pacchetti sotto la regola `binary-indep', e lasciare la regola `binary-arch' vuota, invece.

I nomi dei programmi di debhelper iniziano con dh_, e il resto è la descrizione di cosa fa effettivamente il programma di utilità. È tutto abbastanza auto esplicativo, ma ecco qualche spiegazione addizionale:

Per informazioni più complete su cosa fanno tutti questi script dh_*, e quali sono le loro altre opzioni, leggi le rispettive pagine di manuale. Ci sono alcuni altri, alle volte utili, script dh_*, che non sono menzionati qui. Se ne avessi bisogno, leggi la documentazione di debhelper.

La sezione binary-arch è quella dove dovresti effettivamente commentare qualsiasi riga che richiama funzionalità che non occorrono. Per gentoo, commenterò tutte le righe su examples, cron, init, man and info, semplicemente perché gentoo non le richiede. Inoltre alla linea 68, avrò bisogno di sostituirò `ChangeLog' con `FIXES', perché è il nome reale del file di changelog dell'upstream.

Le ultime due righe (insieme con le altre non spiegate qui) sono solo cose più o meno necessarie, delle quali puoi leggere nel manuale del make e nella Policy. Al momento, non è essenziale conoscerle.


[ precedente ] [ Contenuti ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ A ] [ successivo ]


Guida per il nuovo Maintainer

versione 1.2.3, 18 January 2005.

Josip Rodin joy-mg@debian.org
Traduzione: Francesco P. Lovergine frankie@debian.org