Translation(s): English - Español - Italiano
Contents
Introduzione
Questo tutorial è basato sul tutorial live in IRC di Debian Women tenuto da Gürkan Sengün.
È stato lievemente modificato per adattarsi allo stile del web, e mantenere anonimi i nomi dei partecipanti.
Requisiti
Questo corso si rivolge a persone che non hanno mai fatto un pacchetto Debian, ma hanno compilato loro stessi del software dai sorgenti. Verrà creato un piccolo pacchetto Debian. Per questo saranno necessari alcuni strumenti di Debian, usare:
apt-get install build-essential devscripts dh-make
pacchettizzazione
Si può pacchettizzare per Debian (sezione main) qualunque cosa sia Software Libero (conforme alle DFSG).
Prima di pacchettizzare qualcosa per Debian, è una buona idea verificare se non l'abbia già fatto qualcun altro: fare una rapida ricerca su Google e quindi cercare se c'è un ITP. Una volta che si è sicuri che il software non sia pacchettizzato, si dovrebbe compilare un ITP.
Chiunque può lavorare a Debian, le persone che fanno dei pacchetti per Debian li possono mettere online (su un server web). Se poi chi ha creato il pacchetto trova uno sponsor (ovvero un Debian Developer, abbreviato DD, che verifica quel pacchetto e lo introduce in Debian), può diventare un Debian Maintainer (DM) e apparire su: http://www.debian.org/devel/people.
Quando un nuovo pacchetto viene caricato in Debian, esso dapprima appare nella "Debian new queue" (la si può trovare con Google). Successivamente appare su http://buildd.debian.org
Flusso di lavoro della pacchettizzazione
Procurarsi il software
Questo tutorial farà riferimento al pacchetto wmplopfork (una piccola dockapp, che mostra graficamente l'utilizzo della CPU).
I passaggi da seguire e le indicazioni generali fornite si applicano a qualunque altro programma.
Si può scaricare il software utilizzato in questo tutorial da: http://hules.free.fr/wmforkplop/
È una buona idea quando si fanno pacchetti avere una directory chiamata "debian" nella propria $HOME (o magari "sources/debian" o "src/debian", il concetto è quello), e scaricare in quella directory il codice sorgente dei programmi originali.
Quindi, una volta scaricato il codice sorgente, lo si deve spacchettare (nel nostro caso con tar -xzvf wmforkplop-0.9.1.tar.gz ).
Come si può vedere, wmforkplop si spacchetta per bene in wmforkplop-0.9.1, ma non tutto il software è disponibile in questa bella forma, a volte fanno pasticci e si spacchettano nella stessa directory. Si può dare un'occhiata al file tar facendo tar -tvf tarfile.tar.gz o usando mc.
Debianizzazione con dh
Definire nel proprioo script di login (.bashrc, .zshenv, ecc.) le variabili d'ambiente:
export DEBEMAIL=vostro@indirizzo.email` e `export DEBFULLNAME="Vostro Nome"`.
Assicurarsi di avere esportato tali variabili prima di proseguire, saranno utilizzate da dh_make.
Ora è la volta di entrare nella nuova directory ed eseguire
dh_make
Questo programma farà alcune domande e aiuterà a creare il nuovo pacchetto.
Type of package: single binary, multiple binary, library, or kernel module? [s/m/l/k]
Sta chiedendo che tipo di pacchetto si vuole creare. Selezionare "s" per un singolo binario. È il pacchetto con cui solitamente si comincia. È meglio cominciare con le cose semplici e poi fare pacchetti più complicati quando si ha più esperienza.
Mostrerà delle altre informazioni e aspetterà un <Invio> di conferma: confermare.
Preparazione del pacchetto
dh_make fa un gran bel lavoro aiutando a cominciare con il pacchetto, ma c'è ancora tanto lavoro da fare, specialmente dentro la directory debian/.
README e INSTALL
È buona prassi leggere come prima cosa i file README e INSTALL forniti con il pacchetto originale.
Questo consentirà di sapere come dev'essere installato il programma, e di sapere se ha delle dipendenze impreviste. In più, se il file INSTALL non è quello classico di AutoTools, potrebbe essere necessario leggerlo nel dettaglio per scoprire cosa si deve fare per installarlo.
Nel caso di wmforkplop, il README dice che sono necessari altri software per poterlo creare: imlib2 e libgtop2; è fatto anche notare che il pacchetto sorgente ha un tipo di carattere: Vera.ttf, dal momento che questo è un carattere che è fornito da un altro pacchetto (lo si può verificare utilizzando http://packages.debian.org) dipenderemo da quest'ultimo pacchetto.
Il file INSTALL dice che wmforkplop utilizza autotools, e dunque non c'è bisogno di toccare alcun Makefile. Nel caso di un software che non usa gli autotools, potrebbe esser necessario modificare il Makefile per renderlo adatto a Debian. È necessario installarlo nella directory debian/ utilizzando $(DESTDIR).
.ex
Entrare nella directory debian/ e guardare i molti file creati da dh_make, se ne possono cancellare subito parecchi. Molti di essi sono file .ex (da example); non dovrebbe restare alcun file .ex alla fine della creazione del pacchetto.
Si può rimuovere
init.d.ex : questo software non è un demone,
emacsen* : non ha nulla a che fare con emacs,
conffile.ex : non ci sono conffile,
post*.ex, pre*.ex, cron.d.ex e manpage.*ml.ex : non sono necessari in questo caso,
README.Debian : non si sono note da comunicare agli utenti (al momento).
Dopo tutte le rimozioni, dovrebbero essere rimasti 10 file.
debian/manpage.1.ex: Questo è un esempio di pagina man.
Il pacchetto che si sta creando non contiene la pagina man necessaria per il comando, perciò si deve modificarlo.
Il binario, una volta compilato, si chiama wmforkplop, perciò si deve rinominare manpage.1.ex in wmforkplop.1.
Se ci si sta chiedentdo "Perché .1?", eseguire man man.
Non verranno spiegati i dettagli della modifica della pagina di manuale in questo tutorial, basta cambiare SECTION in 1 e fare quante modifiche si ha voglia di fare.
debian/menu.ex: Questo è un esempio di file di menu per il pacchetto menu.
- Questo pacchetto riguarda uno strumento grafico ed è necessario un file di menu.
Perciò rinominare menu.ex in menu. È possibile aggiungere icone alle proprie applicazioni.
debian/watch.ex: Questo è un esempio di file watch.
Può essere rimosso senza problemi, benché sia piuttosto utile. Si può usare uscan per controllare se esiste una nuova versione originale.
Esaminando nell'ordine i rimanenti file, si ha:
debian/changelog
In questo file si vede il pacchetto, l'archivio delle versioni debian-version e l'urgenza, qualcosa del tipo
wmforkplop (0.9.1-1) unstable; urgency=low
dove
0.9.1 è la versione del programma,
-1 è la revisione Debian,
unstable è l'archivio su ci si caricherà il pacchetto,
urgency=low indica per quanto tempo il pacchetto rimarrà in unstable prima di essere destinato a migrare in testing,
normalmente viene usato il valore "low" (che corrisponde a 10 giorni), anche se sono disponibili anche i valori "medium" e "high".
Se si fosse compilato un ITP, si sarebbe ottenuto un numero di bug ITP da bugs.debian.org, qualcosa come #123456. È possibile chiudere il bug con il caricamento di tale pacchetto, aggiungendo nel changelog:
* Initial Release. (Closes: #123456)
Il file debian/changelog può sembrare innocente, ma è uno dei più importanti.
È letto da molti bot (il bot per i bug, il bot buildd, ecc.);
è il solo file in cui viene indicata la versione del pacchetto: è l'informazione che sarà conservata con ciascun rilascio.
debian/control
Questo file controlla
- il nome del pacchetto sorgente,
- il nome del pacchetto binario,
- in che sezione viene inseritoil pacchetto,
- chi è il manutentore (qui possono anche essere definiti co-manutentori),
- se il pacchetto ne sostituisce un altro,
- se suggerisce o raccommanda altre cose,
- la definizione delle dipendenze (sorgenti così come binarie).
La parte iniziale contiene le informazioni sul pacchetto sorgente (Source) documentate in: http://www.nl.debian.org/doc/debian-policy/ch-controlfields.html
Source: il nome sorgente suggerito solitamente va bene,
Section: unknown deve essere cambiato. (Significa "Sezione: sconosciuta", NdT.) Per wmforkplop si è scelto x11.
Priority: optional va bene.
Si possono guardare altri pacchetti usando apt-cache show per scoprire quale priorità abbiano. Per esempio, apt-cache show bash.
Maintainer: Dopo questo campo è possibile inserire una nuova riga che dica:
Uploaders: Nome amico <indirizzo@posta.ru>, questo indica chi sono i co-manutentori.
È importante notare che il campo Uploaders non viene mostrato quando si usa apt-cache show unqualchepacchetto, ma appare se si usa apt-cache showsrc unqualchepacchetto.
Build-Depends è uno dei campi più importanti. Elenca i pacchetti che sono necessari perché il pacchetto possa essere compilato.
Per wmforkplop, è necessario fare apt-cache search libgtop dev, e si trova: libgtop2-dev: questo è ciò che si deve aggiungere alla riga Build-Depends.
Fare anche apt-cache search imlib dev e aggiungere quindi libimlib2-dev alla riga Build-Depends. Ora dovrebbe essere così:
Build-Depends: debhelper (>= 4.0.0), libgtop2-dev, libimlib2-dev
Ci si potrebbe chiedere a che serva il (>= 4.0.0); quella viene chiamata dipendenza di compilazione con versione. A volte un software necessita di una libreria abbastanza nuova per funzionare correttamente (o del tutto) ed è a questo che è utile quell'indicazione.
Standards-Version dovrebbe indicare 3.x.x, con la versione più recente della Debian Policy: dpkg -l debian-policy (se la si ha installata, se non è così la si dovrebbe installare).
Ora iniziano le informazioni sul pacchetto binario:
Package: wmforkplop; Il nome del pacchetto binario dovrebbe essere a posto.
Architecture: any indica che il pacchetto dovrà essere compilato su ogni (any) architettura (cioè sarà compilato su i386, sparc, powerpc, alpha, ecc.).
A volte si hanno dati (grafica, suoni) o script di shell che non necessitano di compilazione, in quel caso si cambia il campo in all (tutte), dato che una volta creato è utile per tutte (all) le architetture.
Depends: questo campo per il pacchetto binario ha lo scopo di indicare quali pacchetti devono essere presenti come installati quando viene eseguito il software.
Qui dovrebbe essere aggiunto il pacchetto dei tipi di carattere, quello che ha il file Vera.ttf; è possibile trovarlo usando dpkg -S Vera.ttf: ttf-bitstream-vera. Perciò la riga dovrebbe essere:
Depends: ${shlibs:Depends}, ${misc:Depends}, ttf-bitstream-veraLe voci ${...} sono sostituzioni; vengono rimpiazzate da altri valori che sono calcolati automaticamente da altri strumenti quando viene creato il pacchetto.
Le voci in shlibs:Depends sono dipendenze da librerie calcolate automaticamente quando si esegue dh_shlibdeps nel file rules,
le voci misc:Depends sono calcolate da debhelper.
Description:; la prima riga è la descrizione breve, dalla riga successiva in avanti c'è la descrizione lunga.
La descrizione breve dovrebbe dare un'idea di base di che cos'è il pacchetto, seguendo la sintassi: [pacchetto] è un [descrizione breve].
La descrizione lunga deve cominciare con una nuova frase (cioè NON prosegue la descrizione breve),
si deve lasciare uno spazio all'inizio di ogni riga e, se si vuole lasciare una riga vuota, vi si deve collocare uno spazio seguito da un punto.
Per wmforkplop, una buona descrizione sarebbe:
dockapp displaying processes and forking activity Each time a new process is created, and each time another one dies, a spot light appears on the applet and evolves. wmforkplop also displays the top cpu consuming processes, just like wmtop. It also has a process browser (click in the applet to bring it), which gives more informations about each process, and ability to kill a specific process, or "killall" all process who have the same name.
debian/copyright
In questo file si dovrebbe dichiarare
- l'autore originale,
- da dove è stato preso il software,
- la licenza del programma.
Se il software ha licenza GPL si può semplicemente mettere una breve nota che dichiari "on Debian GNU/Linux systems you can find the complete GPL licence in /usr/share/common-licences/GPL" (sui sistemi Debian GNU/Linux si può trovare la licenza GPL completa in /usr/share/common-licenses/GPL).
Ma se non è GPL (o BSD), si dovrebbe includere qui l'intera licenza.
Se alcune parti del software sono GPL e altre hanno qualche altra licenza, si dovrebbe indicare in modo molto chiaro di che parti si tratta, e copiare la licenza alla lettera nel file copyright.
debian/docs
Questo file comprende i file che saranno copiati in /usr/share/doc/pacchetto quando il pacchetto viene installato.
Nel caso di wmforkplop, si può rimuovere la riga Vera.txt dato che è già stata aggiunta la dipendenza.
Si dovrebbe quindi dare un'occhiata ai file ../{NEWS, README, TODO}.
Se ci sono soltanto istruzioni per l'installazione/compilazione non sono desiderabili per l'utente nel pacchetto binario, quindi rimuovere anch'esse.
Se ci sono informazioni importanti o interessanti in quei file, lasciarli al loro posto.
debian/compat
Questo file indica il livello di compatibilità con debhelper.
Debhelper ha subito numerose revisioni, alcune delle quali rompono la compatibilità; si può usare il numero di compat per specificare la revisione di debhelper che il pacchetto in questione richiede o supporta.
È già stato stabilito che è necessario dehelper (>= 4.0.0), dunque compat dovrebbe essere 4.
Si potrebbe avere un pacchetto vecchio che utilizza una sintassi di debhelper vecchia e potrebbe essere compat 1 o compat 2.
Si raccomanda comunque di usare l'ultima versione.
debian/manpages
Questo file stabilisce dove sono le pagine man. Non è stato creato da debhelper: è necessario crearselo da soli.
Nella directory debian/ eseguire:
echo "debian/wmforkplop.1" > manpages
debian/rules
Questo file è simile a un Makefile: ha regole (rules) per lo svolgimento di una serie di compiti.
Debhelper l'ha già riempito con molte regole e compiti, alcuni dei quali sono in forma di commento.
Una volta finite le modifiche, non vi dovrebbero più essere righe di commento. Il che equivale a dire che si dovrebbero decommentare quelle che servono e cancellarle quelle che non servono.
Lettura suggerita sui Makefile:
Proprio in fondo al file si troveranno tre comandi in forma di commento: dh_perl, dh_python, dh_makeshlibs; possono essere tutti rimossi, dato che non si sta usando Perl, né Python, né si stanno facendo shlib.
Si può poi rimuovere anche dh_installinfo, dh_cron, dh_init, dh_mime, dh_pam, dh_emacsen, dh_logrotate, dh_debconf e dh_install, per analoghe ragioni.
Si dovrebbe usare:
dh_debconf se ci fossero domande per debconf da fare all'utente;
dh_install per copiare file dentro la directory temporanea di creazione del pacchetto, ma in questo caso non si fa nessuna copia extra.
Però decommentare dh_installmenu (dato che c'è un file menu).
Creazione dei pacchetti
La preparazione del pacchetto è quasi completa, il prossimo grande passo è crearlo.
Lo si fa utilizzando il comando debuild. Se non si ha la propria chiave GPG a portata di mano, si può creare il pacchetto senza firmarlo usando:
debuild -us -uc
ma ricordarsi che è una buona idea avere la propria chiave GPG pronta quando si creano pacchetti.
Il comando potrebbe lamentarsi della mancanza delle necessarie dipendenze di compilazione; se ciò accade, installarle.
Quando si crea il pacchetto, si possono incontrare errori come:
E: wmforkplop: description-contains-tabs
W: wmforkplop: description-starts-with-leading-spaces
W: wmforkplop: manpage-section-mismatch.
Ciò è comune, perciò non demoralizzarsi; correggere gli errori e riprovare.
Una volta finita la creazione del pacchetto, ci si dovrebbe spostare nelle directory genitrice (quella $HOME/debian) e visualizzare l'elenco dei file al suo interno. Ci dovrebbero essere
- un diff.gz,
- un .dsc,
- un file orig.tar.gz;
il pacchetto binario : un file .deb;
- altri file (si può dare loro un'occhiata)
- .build
- .changes
Ora si può eseguire lintian sul pacchetto, per controllare che sia in buono stato:
lintian -Ivi wmforkplop_0.9.1-1_i386.deb
o qualunque sia il nome del file che si è creato.
Probabilmente mostrerà un elenco di errori e avvertimenti che andranno corretti per poi ricreare il pacchetto.
Una volta corretti gli errori e gli avvertimenti per il .deb, si potrebbe eseguire lintian su
- il file .dsc (ovvero sul pacchetto sorgente),
- o direttamente sul file .changes (il che eseguirà lintian su tutti i file lì elencati: utile se si hanno molti pacchetti binari).
Installazione ed esecuzione
L'ultimo test per il pacchetto è la sua installazione ed esecuzione. Per installarlo si dovrebbe usare:
dpkg -i wmforkplop_0.9.1-1_i386.deb
Dopo che è installato provare le cose che sono state pacchettizzate: provare
- man wmforkplop`,
a eseguire wmforkplop,
- a testare il programma (eseguire un find / e in wmforkplop selezionare la macchia più grossa, quindi selezionare "kill" e poi "gently".)
Condividere il pacchetto
Anche se non si mette il proprio pacchetto in Debian, lo si può comunque condividere con altri mettendolo nella propriaa directory serverweb/debian/.
Domande e risposte
Queste sono le domande fatte e le risposte date durante la sessione su IRC.
Si spera diano una risposta a molte delle comuni domande che potrebbero nascere quando si legge questo tutorial.
Che cosa significa 'ITP' e a che cosa serve?
ITP significa "Intent To Package" (Proposito di pacchettizzare).
È un tipo speciale di bug, che indica che chi lo invia (o qualcun altro) ha intenzione di pacchettizzare un certo software.
Lo scopo degli ITP è di far sì che nessun lavoro sia fatto due volte, così se qualcuno sta pacchettizzando un programma che si vorrebbe pacchettizzare, non sarà necessario farlo due volte.
È buona prassi segnalare un bug ITP (usando reportbug o un client di posta) prima di pacchettizzare del software.
Questo "assicura" che non si sprechi lavoro (che altre persone impacchettino lo stesso software, se controllano il database degli ITP).
Per maggiori informazioni vedete http://www.nl.debian.org/devel/wnpp/.
Che cosa sono gli autotools? Che cos'è lo script `./configure`?
Gli autotools sono un insieme di utilità per aiutare nella compilazione di un programma su ogni piattaforma.
Il ./configure cerca di rilevare su che piattaforma è, e genera un Makefile adatto all'ambiente, o se non può ci rinuncia.
È davvero una manna dal cielo, un tempo sarebbe stato necessario modificare il Makefile da soli.
Se la propria piattaforma non era menzionata nel Makefile, era necessario indovinare i valori da utilizzare per far sì che il programma si compilasse.
Spesso era necessario modificare un po' anche i sorgenti.
Come pacchettizzo i pacchetti che non si compilano? (documentazione, pagine web, script di shell)
Non c'è un tutorial su questo, a causa della miriade di possibilità; ci sono così tanti differenti tipi di pacchetti non compilati che è arduo dare degli indirizzi generali su di essi.
Si possono guardare però dei pacchetti di esempio, per esempio ttf-junicode (Architecture: all) o supertux (all e i386). Provare apt-get source qualchepacchetto e dare un'occhiata a com'è fatto.
Vedere anche
Packaging è la pagina che raccoglie tutto ciò che concerne la pacchettizzazione in questo wiki.