Capitolo 2. Primi passi

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.

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:

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:

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:

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.

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:

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

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.

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.

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

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:

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.

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

$ 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:

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»).