Capitolo 2. Primi passi

# Capitolo 2. Primi passi

È 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.

Iniziamo a creare un pacchetto (o, meglio ancora, adottiamone uno già esistente).

## 2.1. Flusso di lavoro per la costruzione dei pacchetti Debian

Se si sta facendo un pacchetto Debian con un programma, il flusso di lavoro tipico per la costruzione di pacchetti Debian comporta la generazione di diversi file indicati in modo specifico per ogni passo come segue:

- Procuriamoci una copia del programma, di solito in formato tar compresso.

  - ``pacchetto`-`versione`.tar.gz`

- Aggiungiamo le modifiche specifiche per il pacchetto Debian del programma, nella directory `debian`, e creiamo un archivio sorgente non nativo (ovvero con l'insieme di file di input utilizzati per la creazione del pacchetto) in formato `3.0 (quilt)`.

  - ``pacchetto`_`versione`.orig.tar.gz`
  - ``pacchetto`_`versione`-`revisione`.debian.tar.gz` [4]
  - ``pacchetto`_`versione`-`revisione`.dsc`

- Costruiamo i pacchetti binari Debian, che sono normali pacchetti installabili nel formato `.deb` (o nel formato `.udeb`, usato dall'installer Debian) dal sorgente del pacchetto Debian.

  - ``pacchetto`_`versione`-`revisione`_`arch`.deb`

Si prega di notare che il carattere di separazione tra ``pacchetto`` e ``versione`` è stato modificato da `-` (trattino) nel nome dell'archivio, a `_` (trattino basso) nel nome del pacchetto Debian.

Nel file di nomi di cui sopra, sostituire la parte relativa al ``pacchetto`` con il nome del pacchetto, la ``versione`` con la versione originale, la ``revisione`` con la revisione Debian, e l'``architettura`` con l'architettura del pacchetto, come definito nel manuale delle Policy di Debian. [5]

Ogni passo di questo schema è spiegato con esempi dettagliati nelle sezioni successive.

## 2.2. Scegliamo il programma

Probabilmente avete già scelto il pacchetto da creare. La prima cosa da fare è controllare se il pacchetto è già presente negli archivi della distribuzione, utilizzando i seguenti strumenti:

- il comando aptitude

- la pagina web Pacchetti Debian

- the Debian Package Tracker web page

Se il pacchetto esiste già, bene, basta installarlo! :-) Se dovesse essere orfano (cioè, se il maintainer è Debian QA Group), lo si può prendere in carico se è ancora disponibile. Si può adottare anche un pacchetto per il quale il suo manutentore ha presentato una richiesta di adozione (RFA).[6]

Ci sono diverse risorse per controllare lo stato di appartenenza dei pacchetti:

- Il comando wnpp-alert dal pacchetto `devscripts`

- Work-Needing and Prospective Packages

- Registri di Debian delle segnalazioni dei bug: bug nello pseudo-pacchetto `wnpp` in `unstable`

- Pacchetti Debian che hanno bisogno d'amore

- Sfogliare i bug di `wnpp` basati su debtags

Come nota a margine, è importante sottolineare che Debian ha già i pacchetti per la maggior parte dei programmi e che il numero di pacchetti presenti nell'archivio Debian è molto più grande di quello dei contribuenti con permessi di caricamento. Pertanto, i contributi sui pacchetti già presenti in archivio sono molto più apprezzati dagli altri sviluppatori (ed è molto più probabile che si ottenga una sponsorizzazione). [7]. Si può contribuire in diversi modi:

- adottando dei pacchetti orfani, ma ancora attivamente utilizzati

- entrando a far parte dei team di pacchettizzazione

- aiutando nella risoluzione dei bug di pacchetti molto popolari

- preparando QA o caricando NMU

Appena ci si sente in grado di adottare un pacchetto, bisogna scaricare i sorgenti (con qualcosa tipo `apt-get source `pacchetto``) ed esaminarli. Questo documento purtroppo non include tutte le informazioni che riguardano l'adozione dei pacchetti. Fortunatamente non sarà difficile capire come funziona il pacchetto dal momento che qualcuno avrà già effettuato la configurazione iniziale. Continua comunque a leggere, molti dei suggerimenti qui di seguito saranno utili per il nostro scopo.

Se il pacchetto è nuovo, e si pensa che sarebbe bello entrare a far parte di Debian, ecco come procedere:

- Prima di tutto bisogna capire se il programma funziona in modo corretto, e averlo provato per almeno un po' di tempo e dimostrarne l'utilità.

- Bisogna controllare nella lista dei pacchetti sui quali si lavora che nessun altro stia lavorando sullo stesso pacchetto. Se nessuno ci sta lavorando, si può segnalare un bug di tipo ITP (Intent To Package) allo pseudo-pacchetto `wnpp` usando il programma reportbug. Se qualcuno ci sta lavorando e si ritiene necessario si potrebbe contattare il maintainer. Altrimenti — si potrebbe trovare un altro programma interessante che è non manutenuto.

- Il programma deve avere una licenza.

  - I programmi nella sezione `main`, devono essere completamente compatibili con le Linee Guida per il Software Libero Debian (DFSG, Debian Free Software Guidelines) (vedere DSFG) e non devono richiede nessun pacchetto che non sia presente nella sezione `main`, per la compilazione o l'esecuzione. Questo è il caso preferito.

  - I programmi nella sezione `contrib`, devono essere conformi alle DFSG, ma potrebbero richiedere, per la compilazione o l'esecuzione, un pacchetto che non è presente nella sezione `main`.

  - I programmi nella sezione `non-free`, possono non essere conformi alle DFSG, ma devono poter essere distribuibili.

  - Se non si è sicuri su quale sezione il pacchetto dovrebbe essere incluso, si può mandare il testo della licenza alla mailing list debian-legal@lists.debian.org e chiedere consigli.

- Il programma non dovrebbe introdurre problemi si sicurezza e di manutenzione al il sistema Debian.

  - Il programma dovrebbe essere ben documentato e il suo codice facilmente comprensibile (ad es. non offuscato).

  - Si dovrebbe contattare l'autore o gli autori del programma per verificare che siano d'accordo con la sua pacchettizzazione. È importante essere in grado di consultarsi con l'autore/i sul programma nel caso di problemi specifici del programma, per questo è meglio non provare a pacchettizzare programmi non più manutenuti.

  - Il programma non dovrebbe certamente girare come setuid root, o meglio, non dovrebbe per niente richiedere di essere setuid o setgid.

  - Il programma non dovrebbe essere un daemon, o essere installato nelle directory `*/sbin`, o aprire una porta come root.

Ovviamente queste sono solo misure di sicurezza, fatte per salvarti dall'ira degli utenti se si commette qualche errore in qualche daemon setuid… Una volta acquisita esperienza nella pacchettizzazione, sarai in grado di creare pure quel tipo di pacchetti.

Visto che si è alle prime armi come maintainer, si consiglia di acquisire un po' d'esperienza creando dei pacchetti semplici cercando di evitare quelli più complicati.

- Pacchetti semplici

  - pacchetto binario singolo, arch = all (collezione di dati, come le immagini di sfondo)

  - pacchetto binario singolo, arch = all (eseguibili scritti in un linguaggio interpretato come lo shell POSIX)

- Pacchetti di media difficoltà

  - pacchetto binario singolo, arch = any (binari ELF eseguibili compilati da linguaggi come C e C++)

  - pacchetti binari multipli, arch = any + all (pacchetti per binari ELF eseguibili + documentazione)

  - sorgente originale in un formato diverso da `tar.gz` o `tar.bz2`

  - l'archivio dei sorgenti originale ha contenuti non distribuibili

- Pacchetti complessi

  - pacchetto di un modulo di un interprete utilizzato da altri pacchetti

  - libreria ELF generica utilizzata da altri pacchetti

  - pacchetti binari multipli che includono un pacchetto di una libreria ELF

  - pacchetto con molteplici sorgenti originali

  - pacchetti di moduli del kernel

  - pacchetti di patch del kernel

  - ogni pacchetto con degli script di manutenzione non banali

Creare pacchetti complessi non è troppo difficile, ma richiede un po' più di conoscenza. Si dovrebbe cercare una guida specifica per ogni caratteristica complessa. Ad esempio, alcuni linguaggi hanno dei loro documenti con le loro linee guida:

- Perl policy

- Python policy

- Java policy

C'è un altro vecchio detto latino che dice: fabricando fit faber (la pratica rende perfetti). Si tratta di una pratica vivamente consigliata, sperimentate tutte le fasi di pacchettizzazione Debian con un pacchetto semplice durante la lettura di questo tutorial. Un archivio compresso banale come `hello-sh-1.0.tar.gz` creato come segue, può offrire un buon punto di partenza:[8]

    $ mkdir -p hello-sh/hello-sh-1.0; cd hello-sh/hello-sh-1.0
    $ cat > hello <<EOF
    #!/bin/sh
    # (C) 2011 Foo Bar, GPL2+
    echo "Hello!"
    EOF
    $ chmod 755 hello
    $ cd ..
    $ tar -cvzf hello-sh-1.0.tar.gz hello-sh-1.0

## 2.3. Prendere il programma e provarlo

La prima cosa da fare è trovare e scaricare il codice sorgente originale del programma. Supponendo che si è recuperato il file dal sito web dell'autore. Generalmente il codice sorgente dei programmi liberi per Unix e derivati sono in formato tar+gzip con estensione `.tar.gz`, oppure in formato tar+bzip2 con estensione `.tar.bz2`. Di solito, questi file, contengono la sottodirectory dal nome ``pacchetto`-`versione`` con tutti i sorgenti.

Se è presente un sistema di controllo di versione (VCS) come Git, Subversion o CVS, è possibile scaricare l'ultima versione del codice sorgente con `git clone`, `svn co`, o `cvs co` e comprimerlo in formato tar+gzip utilizzando l'opzione `--exclude-vcs`.

Se il codice sorgente è in qualche altro formato di archiviazione (per esempio, con estensione `.Z` o `.zip`[9]), scompattarlo con i programmi appropriati, e ricomprimerlo.

Se il sorgente del programma viene fornito con alcuni contenuti che non sono conformi con il DFSG, si dovrebbe scompattarlo, rimuovere questi contenuti e ricomprimerlo con una versione modificata dei sorgenti originali contenenti `dfsg` .

A titolo di esempio, verrà utilizzato il programma gentoo, un gestore file grafico basato su GTK+.[10]

È buona regola creare una sottodirectory nella directory home e nominarla `debian` o `deb` o qualsiasi altro nome appropriato (ad es. in questo caso `~/gentoo` andrebbe più che bene). Scaricare l'archivio e scompattarlo (con il comando `tar xzf gentoo-0.9.12.tar.gz`). Bisogna assicurarsi che non ci siano errori, per quanto in apparenza irrilevanti, perché potrebbero causare problemi nell'estrazione dell'archivio sul sistema di altre persone, alcuni strumenti di estrazione a volte ignorano queste anomalie. Nella console dovrebbe esserci quanto segue:

    $ mkdir ~/gentoo ; cd ~/gentoo
    $ wget http://www.example.org/gentoo-0.9.12.tar.gz
    $ tar xvzf gentoo-0.9.12.tar.gz
    $ ls -F
    gentoo-0.9.12/
    gentoo-0.9.12.tar.gz

A questo punto si avrà un'altra sottodirectory, dal nome `gentoo-0.9.12`. Spostarsi in questa directory e leggere attentamente la documentazione fornita. Di solito si avranno dei file come `README*`, `INSTALL*`, `*.lsm` o `*.html`. È necessario trovare istruzioni su come compilare e installare correttamente il programma (si potrebbe supporre di installare il programma nella directory `/usr/local/bin`, ma questo non è il comportamento corretto, tratteremo l'argomento più avanti Sezione 3.3, «Installazione dei file nei loro percorsi»).

Si dovrebbe iniziare la pacchettizzazione con la directory dei sorgenti completamente ripulita, o semplicemente partendo da una nuova estrazione dall'archivio dei sorgenti.

## 2.4. Sistemi di compilazione semplici

I programmi più semplici sono dotati di un file `Makefile`, e possono essere compilati semplicemente con il comando `make`.[11] Alcuni supportano `make check`, che esegue dei controlli automatici. Per installare il programma nella directory di destinazione, di solito basta eseguire `make install`.

Adesso si provi a compilare ed eseguire il programma, assicurandosi che funzioni correttamente e che niente sia andato storto durante l'installazione o l'esecuzione.

Di solito, per ripulire la directory di compilazione, si usa il comando `make clean` (o meglio ancora `make distclean`). Talvolta c'è anche il comando `make uninstall` che serve a rimuovere tutti i file installati.

## 2.5. Sistemi di compilazione portabili più utilizzati

Molti programmi liberi sono scritti utilizzando i linguaggi di programmazione C e C++. Molti di questi utilizzano Autotools o CMake per essere portabili su diverse piattaforme. Questi strumenti vengono utilizzati per generare il `Makefile` e altri file sorgenti necessari. Dopo di questo, i programmi vengono compilati utilizzando il solito `make; make install`.

Autotools è il sistema di compilazione della GNU, che comprendere Autoconf, Automake, Libtool, e gettext. Per capire meglio ciò che avviene, si possono leggere i seguenti file sorgenti: `configure.ac`, `Makefile.am`, e `Makefile.in`. [12]

Il primo passo del flusso di lavoro degli Autotools consiste solitamente nell'esecuzione del comando `autoreconf -i -f` per i sorgenti che verranno successivamente distribuiti insieme ai file generati.

    configure.ac-----+-> autoreconf -+-> configure
    Makefile.am -----+        |      +-> Makefile.in
    src/Makefile.am -+        |      +-> src/Makefile.in
                              |      +-> config.h.in
                          automake
                          aclocal
                          aclocal.m4
                          autoheader

La modifica dei file `configure.ac` e `Makefile.am` richiede una minima conoscenza di autoconf e automake. Vedere`info autoconf` e `info automake`.

Il passo successivo da compiere con Autotools, di solito, consiste nel procurarsi il sorgente del programma e nel compilarlo nella directory `binary` tramite l'esecuzione dei comandi `./configure && make` all'interno della directory dei sorgenti stessi.

    Makefile.in -----+                +-> Makefile -----+-> make -> binary
    src/Makefile.in -+-> ./configure -+-> src/Makefile -+
    config.h.in -----+                +-> config.h -----+
                     |
      config.status -+
      config.guess --+

Si possono modificare molte cose nel file `Makefile`, come la posizione predefinita di installazione dei file utilizzando l'opzione ./configure --prefix=/usr.

Nonostante non sia richiesto, l'aggiornamento di `configure` e degli altri file con `autoreconf -i -f` può migliorare la compatibilità del sorgente. [13]

CMake è un alternativo sistema di compilazione. Per conoscerlo meglio si può leggere il file `CMakeLists.txt`.

## 2.6. Nome e versione del pacchetto

Se il sorgente del programma originale è nominato `gentoo-0.9.12.tar.gz`, si può usare `gentoo` come nome pacchetto e `0.9.12` come versione del programma originale. Queste stringhe saranno utilizzate nel file `debian/changelog` come vedremo più avanti nel Sezione 4.3, «`changelog`».

Sebbene questo semplice approccio il più delle volte funzioni, può essere necessario modificare il nome pacchetto e la versione del programma originale rinominando il sorgente originale in qualcosa conforme alla policy di Debian ed alle convenzioni esistenti.

È necessario scegliere il nome del pacchetto utilizzando solo lettere minuscole (`a-z`), cifre (`0-9`), il segno più (`+`) e il segno meno (`-`), e il punto ( `.` ). Il nome deve essere di almeno due caratteri, deve iniziare con un carattere alfanumerico, e non deve essere la stesso di quelli già esistenti. È consigliabile mantenere la lunghezza intorno ai 30 caratteri. [14]

Se il sorgente originale usa un nome troppo generico come `test-suite` è consigliabile rinominarlo, in modo da identificare meglio il suo contenuto e per non rischiare di sporcare il namespace. [15]

Si consiglia di scegliere un nome della versione del programma originale contenente solo caratteri alfanumerici (`0-9A-Za-z`), il segno più (`+`), il simbolo tilde (`~`), e il punto (`.`). Il nome deve iniziare con una cifra (`0-9`). [16] È consigliabile, se possibile, mantenere una lunghezza entro gli 8 caratteri. [17]

Se il programma originale non utilizza un normale sistema di versioning, come ad esempio `2.30.32`, ma utilizza qualche tipo di data, come `11Apr29`, un stringa con un codice casuale, o un valoro di hash di un VCS, bisogna assicurarsi di rimuoverli dalla versione originale. Queste informazioni possono essere registrate nel file `debian/changelog`. Se si ha bisogno di inventare una stringa di versione, bisogna utilizzare il formato `YYYYMMDD`, ad esempio `20110429` come versione originale. Questo fa in modo che dpkg interpreti in modo corretto le versioni successive del programma, per gli aggiornamenti. Se ci si vuole assicurare, in futuro, una transazione indolore ad un normale sistema di versioning, come `0.1`, si utilizzi il formato `0~YYMMDD`, ed esempio `0~110429`, anzichè la versione originale.

Le stringhe di versione [18] possono essere confrontate usando dpkg(1) come segue:

    $ dpkg --compare-versions ver1 op ver2

Le regole per il confronto delle versioni possono essere riassunte in questo modo:

- Le stringhe sono confrontate dall'inizio alla fine (da sinistra verso destra).

- Le lettere hanno più priorità delle cifre.

- I numeri sono confrontati come interi.

- Le lettere sono confrontate in ordine di codice ASCII.

- Ci sono regole speciali per il punto (`.`), il segno più (`+`), e il carattere tilde (`~`), eccole descritte:

  `0.0` < `0.5` < `0.10` < `0.99` < `1` < `1.0~rc1` < `1.0` < `1.0+b1` < `1.0+nmu1` < `1.1` < `2.0`

Un esempio di caso intricato si ha, ad esempio, quando una è presente una pre-release RC come `gentoo-0.9.12-ReleaseCandidate-99.tar.gz` per il programma `gentoo-0.9.12.tar.gz`. In questo caso è necessario assicurarsi che l'aggiornamento funzioni correttamente, rinominando il sorgente originale `gentoo-0.9.12~rc99.tar.gz`.

## 2.7. Configurare dh_make

Una delle prime cose da fare è impostare le variabili d'ambiente della shell `$DEBEMAIL` e `$DEBFULLNAME` visto che molti strumenti di gestione di Debian usano queste variabili per recuperare il nome e l'email da utilizzare nei pacchetti. [19]

    $ cat >>~/.bashrc <<EOF
    DEBEMAIL="your.email.address@example.org"
    DEBFULLNAME="Firstname Lastname"
    export DEBEMAIL DEBFULLNAME
    EOF
    $ . ~/.bashrc

## 2.8. Il primo pacchetto non nativo per Debian

I pacchetti classici per Debian sono pacchetti non-nativi, ovvero non specificamente pensati per debian, come ad esempio qualche programma di manutenzione per Debian. Se si desidera creare un pacchetto Debian non-nativo del programma con il sorgente `gentoo-0.9.12.tar.gz` si può utilizzare il programma dh_make come segue:

    $ cd ~/gentoo
    $ wget http://example.org/gentoo-0.9.12.tar.gz
    $ tar -xvzf gentoo-0.9.12.tar.gz
    $ cd gentoo-0.9.12
    $ dh_make -f ../gentoo-0.9.12.tar.gz

Ovviamente, si deve sostituire il nome del file con il nome dell'archivio dei sorgenti originali. [20] Vedere dh_make(8) per i dettagli.

Verranno visualizzate alcune informazioni e verrà chiesto che tipo di pacchetto creare. Gentoo è un pacchetto binario singolo — crea un solo binario, e quindi un solo file `.deb` — per cui si dovrà selezionare la prima opzione (con il tasto `s`), controllare le informazioni sullo schermo e confermare la scelta con ``ENTER``. [21]

L'esecuzione di dh_make, creerà una copia dell'archivio originale del programma, come nome `gentoo_0.9.12.orig.tar.gz`, nella directory superiore, per consentire, più avanti, la creazione di un pacchetto Debian sorgente non-nativo con nome `debian.tar.gz`:

    $ cd ~/gentoo ; ls -F
    gentoo-0.9.12/
    gentoo-0.9.12.tar.gz
    gentoo_0.9.12.orig.tar.gz

Si presti attenzione a due caratteristiche chiave presenti nel nome del file `gentoo_0.9.12.orig.tar.gz`:

- Il nome del pacchetto e la versione sono separati da `_` (trattino basso).

- La stringa `.orig` è inserita prima di `.tar.gz`.

Si dovrebbe aver notato che nella sottodirectory dei sorgenti `debian` sono stati creati molti modelli di file. Questo verrà trattato in Capitolo 4, File richiesti nella directory `debian` e Capitolo 5, Altri file nella directory `debian`. Dovreste aver capito che la pacchettizzazione non è un processo automatico. È necessario modificare il sorgente originale per Debian (come descritto in Capitolo 3, Modificare i sorgenti). Dopo di questo, è necessario creare i pacchetti Debian in maniera appropriata (Capitolo 6, Costruzione del pacchetto), provarli Capitolo 7, Controllare il pacchetto per errori, e caricarli (Capitolo 9, Caricamento del pacchetto). Tutti i passaggi verranno approfonditi in seguito.

Se accidentalmente viene cancellato qualche modello di file mentre ci si lavora, è possibile recuperarlo eseguendo dh_make con l'opzione `--addmissing` nella directory dei sorgenti del pacchetto Debian.

L'aggiornamento di un pacchetto già esistente può diventare complicato, perché è possibile che si siano usate vecchie tecniche di pacchettizzazione. Per adesso, è consigliabile, concentrarsi sulla creazione di nuovi pacchetti per imparare le basi. Si tornerà ad approfondire l'argomento più avanti su Capitolo 8, Aggiornamento del pacchetto.

Si tenga presente che non è necessario che il file dei sorgenti contenga qualsiasi sistema di creazione, discusso in Sezione 2.4, «Sistemi di compilazione semplici» and Sezione 2.5, «Sistemi di compilazione portabili più utilizzati». Potrebbe essere solo una collezione di file grafici, ecc. L'installazione di questi file può essere effettuata utilizzando solamente i file di configurazione di `debhelper`, come `debian/install` (vedere Sezione 5.11, «`install`»).

[4] Per gli archivi non nativi nel vecchio formato `1.0`, viene utilizzato il nome ``pacchetto`_`versione`-`revisione`.diff.gz`.

[5] Vedere 5.6.1 "Sorgente", 5.6.7 "Pacchetto", e 5.6.12 "Versione". L'architettura del pacchetto è conforme al manuale delle Policy di Debian: 5.6.8 "Architettura" ed è assegnata automaticamente al processo di creazione del pacchetto.

[6] Per maggiori informazioni, consulta la Guida di riferimento per lo sviluppatore Debian 5.9.5. "Adottare un pacchetto".

[7] Detto questo, ovviamente ci sarà sempre qualche nuovo programma che vale la pena pacchettizzare.

[8] Non ci si preoccupi della mancanza dei `Makefile`. È possibile installare il programma hello semplicemente usando il comando debhelper come in Sezione 5.11, «`install`», oppure modificando il sorgente originale aggiungendo un nuovo `Makefile` con la destinazione dell' `install` come in Capitolo 3, Modificare i sorgenti .

[9] Si può utilizzare il comando file per scoprire il formato di archiviazione.

[10] Il programma in questione è già stato pacchettizzato. La versione corrente usa gli Autotools e la sua costruzione e struttura è molto sostanzialmente differente dagli esempi seguenti, che sono basati sulla versione 0.9.12.

[11] Molti programmi moderni sono dotati di uno script `configure` che, una volta eseguito, crea un `Makefile` personalizzato per il proprio sistema.

[12] Autotools è troppo vasto per essere approfondito in questo piccolo tutorial. Questa sezione ha lo scopo di fornire solo i concetti base ed i riferimenti. Assicurarsi di leggere il tutorial Autotools e la copia locale di `/usr/share/doc/autotools-dev/README.Debian.gz`, se si intende usarlo.

[13] Si possono automatizzare queste operazioni utilizzando il pacchetto `dh-autoreconf`. Vedere Sezione 4.4.3, «Personalizzazione del file `rules`».

[14] Il campo di default di aptitude del nome del pacchetto è di 30 caratteri. Oltre il 90% dei pacchetti ha un nome più piccolo di 24 caratteri.

[15] Se si segue la guida dello sviluppatore Debian 5.1. "New packages", il processo di ITP di solito dovrebbe risolvere questo tipo di problemi.

[16] Questa regola dovrebbe aiutare ad evitare confusione con i nome dei file.

[17] La lunghezza predefinita del campo "versione" di aptitude è di 10 caratteri. Di solito le revisioni Debian precedute da un trattino ne utilizzano 2. Per più dell'80% dei pacchetti, la lunghezza della versione dei sorgenti originali è più piccola di 10 caratteri e la revisione Debian è inferiore a 3 caratteri.

[18] La stringa della versione può essere costituita da versione del programma originale (``versione``), revisione Debian (``revisione``), oppure da versione (``versione`-`revisione``). Vedere Sezione 8.1, «Nuova revisione Debian» per conoscere come incrementare il numero della revisione Debian.

[19] Il seguente testo assume che stiate utilizzando Bash come shell di login. Se si utilizza un'altra shell di login, come la Z shell, bisognerà usare i suoi file di configurazione al posto di `~/.bashrc`.

[20] Se i sorgenti originali contengono già la directory `debian` e il suo contenuto, si deve eseguire il comando dh_make con l'opzione `--addmissing`. Il nuovo formato dei sorgenti `3.0 (quilt)` è abbastanza maturo da non danneggiare questi pacchetti. Potrebbe essere necessario aggiornare i contenuti forniti nei sorgenti originali per il pacchetto Debian.

[21] Ecco le varie opzioni: `s` che sta per binario Singolo, `i` per Indipendente dall'architettura, `m` per binario Multiplo, `l` per Libreria, `k` per modulo del Kernel, `n` per patch del kernel e `b` per `cdbs`. Questo documento si basa sull'uso del comando dh (contenuto nel pacchetto `debhelper`) per la creazione di un pacchetto contenente un singolo binario, verrà trattato anche il funzionamento dei pacchetti indipendenti dall'architettura e i pacchetti con binari multipli. Il pacchetto `cdbs` offre un'infrastruttura di script alternativa al comando dh e non rientra nell'ambito di questo documento.

Capitolo 1. Partire nel modo giusto |  | Capitolo 3. Modificare i sorgenti