[ precedente ] [ Contenuti ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ successivo ]
Proviamo a creare un pacchetto.
La prima cosa da fare, dopo quella di scegliere il programma per cui creare il
pacchetto, è controllare se il pacchetto è già presente negli archivi della
distribuzione, utilizzando aptitude
.
Si possono controllare le informazioni sui pacchetti anche nella pagina di ricerca dei
pacchetti
e nel sistema di tracciamento
dei bug di Debian
.
Se il pacchetto esiste già, allora non rimane che installarlo! :-) Se invece divenisse orfano -- ovvero se il suo maintainer è configurato come "Debian QA Group", si può sempre prenderlo in carico.
Si può consultare nel sito web Debian la lista dei pacchetti che hanno bisogno
di un nuovo manutentore e dei futuri pacchetti Debian
e gli ultimi aggiornamenti sui pacchetti da adottare e
orfani
.
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 a leggere comunque, molti dei suggerimenti qui di seguito saranno ancora utili al caso.
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 su 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 in accordo
con le Linee Guida per il Software Libero Debian (DFSG, Debian Free Software
Guidelines) (vedere http://www.debian.org/social_contract#guidelines
)
e non devono richiede nessun pacchetto che non sia presente nella
sezione main, per la compilazione o l'esecuzione, come
previsto dalla policy di Debian. Questo è il caso preferito.
I programmi nella sezione contrib, devono essere conformi alle DSFG, 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 DSFG, 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 girare come setuid root, o meglio, non dovrebbe richiedere di essere setuid o setgid per nessun utente.
il programma non dovrebbe essere un daemon, o qualcosa che debba essere
installato nelle directory */sbin
, o aprire una porta come root.
il programma dovrebbe essere in formato binario eseguibile, le librerie sono più difficili da gestire.
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.
Ovviamente queste sono solo misure di sicurezza, fatte per salvare il futuro
maintainer dall'ira degli utenti se si commette qualche errore in qualche
daemon setuid... Una volta acquisita esperienza nella pacchettizzazione, si
riuscirà a creare pure quel tipo di pacchetti, ma anche lo sviluppatore più
esperto consulta la mailing list debian-mentors@lists.debian
quando ha qualche dubbio. E i partecipanti saranno lieti di dare una mano.
Per maggiori informazioni, consulta la Guida di riferimento per
lo sviluppatore
.
La prima cosa da fare è trovare e scaricare il codice sorgente del programma.
Supponendo che si è recuperato il file dal sito web dell'autore. Generalmente
il codice sorgente di 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 programma-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
[3]), scompattarlo con i programmi
appropriati, e comprimerlo di nuovo.
A titolo di esempio, verrà utilizzato il programma gentoo
, un
gestore file per X basato su GTK+.[4]
È 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 Installazione in una sotto-directory,
Sezione 3.3).
Simple programs come with a Makefile
file in them and can be
compiled simply with "make". Some of them support
"make check", which runs included self-checks.
Installation to the destination directories is usually done with
"make install".
Adesso si provi a compilare ed eseguire il programma, assicurandosi che funzioni correttamente e niente sia andato male 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.
A lot of Free programs use the GNU Build System known
as the GNU Autotools
, whose most important components are Autoconf,
Automake, Libtool, and Gettext to make them portable across different
platforms. You can notice such sources by the configure.ac
,
Makefile.am
, and Makefile.in
files. [5]
The first step of Autotools work flow is usually that the upstream runs "autoreconf -i -f" in the source and distributes this source with generated files.
configure.ac-----+-> autoreconf -+-> configure Makefile.am -----+ | +-> Makefile.in src/Makefile.am -+ | +-> src/Makefile.in | +-> config.h.in automake aclocal aclocal.m4 autoheader
Editing configure.ac
and Makefile.am
files requires
some knowledge of autoconf
and automake
. See
"info autoconf" and "info
automake".
The second step of Autotools work flow is usually that the user obtains this
distributed source and runs "./configure &&
make" in the source to compile program into a
binary
.
Makefile.in -----+ +-> Makefile -----+-> make -> binary src/Makefile.in -+-> ./configure -+-> src/Makefile -+ config.h.in -----+ +-> config.h -----+ | config.status -+ config.guess --+
You can change many things in the Makefile
file such as the
default file install location using the command option, e.g.
"./configure --prefix=/usr
".
Although it is not required, updating the configure
and other
files with "autoreconf -i -f" as the user may improve
the compatibility of the source.
Si dovrebbe iniziare la fase di pacchettizzazione con la directory dei sorgenti completamente ripulita, o semplicemente partendo da una nuova estrazione dall'archivio dei sorgenti.
Per costruire correttamente il pacchetto, si deve convertire in minuscolo il
nome del programma originale (se non lo fosse), e rinominare la directory dei
sorgenti in pacchetto-versione
.
Se il nome del programma è formato da più di una parola, si deve contrarlo in
una sola parola, o abbreviarlo. Per esempio, il pacchetto del programma
"John's little editor for X" potrebbe essere chiamato
johnledx
, o jle4x
, o qualsiasi altra cosa attinente,
che riesca a stare sotto un numero ragionevole di caratteri, ad esempio 20.
Bisogna controllare inoltre l'esatta versione del programma (che deve essere
inclusa nella versione del pacchetto). Se il programma non usa una numerazione
delle versioni tipo X.Y.Z, ma qualche tipo di data, si può
utilizzare tale data come numero di versione, a condizione che la numerazione
vada ad aumentare. Anche se è meglio utilizzare lo stesso numero di versione
usato dal programma, se il formato è 09Oct23 potrebbe essere
necessario convertirlo nel formato YYYYMMDD, la data di prima
quindi diventerebbe 20091023, questo è utile per garantire il
corretto ordine di aggiornamento con il programma dpkg
. [6]
Alcuni programmi non usano alcun tipo di numerazione, in questo caso si dovrebbe contattare l'autore del programma, per controllare se viene usato qualche altro metodo di revisione.
Una delle prime cose da fare è impostare le variabili d'ambiente $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. Ecco come fare.
$ cat >>~/.bashrc <<EOF DEBEMAIL=il.vostro.indirizzo.email@example.org DEBFULLNAME="Nome Cognome" export DEBEMAIL DEBFULLNAME EOF
Adesso si può iniziare la debianizzazione eseguendo il programma
dh_make
come segue:
$ . ~/.bashrc $ cd ~/gentoo/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. [7] Vedere
dh_make(1)
per i dettagli.
Verranno visualizzate alcune informazioni. Verrà chiesto che tipo di pacchetto
creare. Gentoo è un singolo pacchetto binario - 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".
[8]
Dopo l'esecuzione di dh_make
, verrà eseguita 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 il 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).
C'è .orig
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 File richiesti nella directory
debian
, Capitolo 4 e Altri file
nella directory debian
, Capitolo 5. Dovreste aver capito che
la pacchettizzazione non è un processo automatico. È necessario modificare il
sorgente originale per Debian come descritto in Modificare i sorgenti, Capitolo 3. Dopo tutti
questi passaggi, è necessario creare i pacchetti Debian in maniera appropriata
come descritto in Costruzione del pacchetto,
Capitolo 6, controllarli come descritto in Controllare il pacchetto per errori, Capitolo 7,
e caricarli come descritto in Caricamento del
pacchetto, Capitolo 8. Verranno approfonditi tutti questi passaggi.
Ancora una volta, visto che si è alle prime armi come maintainer non è consigliato creare pacchetti complessi, ad esempio:
pacchetti binari multipli,
pacchetti di libreria,
pacchetti di moduli del kernel,
pacchetti di patch del kernel,
pacchetti i cui sorgenti non sono in formato tar.gz. o tar.bz2, oppure
l'archivio dei sorgenti ha contenuti non distribuibili.
Non è difficile, ma richiede un po' più di conoscenze, per cui non ne parleremo in questo documento.
Se accidentalmente viene cancellato qualche modello di file mentre ci si
lavora, è possibile recuperarlo eseguendo dh_make
con l'opzione
--addmissing nella directory già debianizzata.
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 Aggiornamento del pacchetto, Capitolo 9.
[ precedente ] [ Contenuti ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ successivo ]
Guida per il nuovo Maintainer
version 1.2.19, 2010-05-31 13:48:35 UTCjoy-mg@debian.org
kalos@nerdrug.org
jacopo.reggiani@gmail.com