• Diff for "it/Packaging/Intro"

Introduzione alla pacchettizzazione per Debian

~- Sessione di training su IRC del "Debian Women" tenuta da Lars Wirzenius, 18-Nov-2010

Questo è una lezione introduttiva alla creazione di pacchetti per Debian quindi non verranno spiegati i meccanismi più complessi della pacchetizzazione per Debian, ma verrà mostrato come creare pacchetti per programmmi semplici da pacchettizare.

Per questo motivo, verrà usato solo il comando dh da debhelper 7.

Requisiti

In questa guida si presume che:

• tu sappia installare pacchetti binari;

• tu conosca l'uso di base della linea di comando e l'utilizzo di un editor di testo a tua scelta (emacs, vim, gedit, kate, etc.);

Requisiti tecnici:

• build-essential

• devscripts

• debhelper version 7

Three central concepts

I tre concetti centrali sono "archivio upstream", "pacchetto sorgente" e "pacchetto binario", la maggior parte delle persone pacchettizza programmi che qualcun'altro ha scritto: questo qualcun'anltro si chiama "upstream developer". L'upstream developer rilascerà una versione del suo programma e il risultato sarà "il pacchetto dei sorgenti upstream" o "tarball".

Un tarball è un file che ha estensione ".tar.gz" o ".tgz" ( la parola "tarball" fa parte del gergo informatico) Il tarball è esattamente ciò che Debian prende e dal quale costruisce un pacchetto. Quanto tu hai un tarball upstream, il passo successivo è creare pacchetto sorgente per Debian, da quale tu puoi creare "il pacchetto binario che è quello che effettivamente verrà installato.

• il pacchetto sorgente è composto, nella sua forma più semplice, da tre file:

• Il tarball upstream, rinominato in modo che segua un modello sistematico.
• Un patch file, con tutti le modifiche al sorgente upstream, più tutti i file creati per il pacchetto Debian. Questo ha estensione ".diff.gz".

• Un file descrizione (con estensione .dsc), che elenca gli altri due file.

Tutto questo può suonare più complicato del necessario, a prima vista potrebbe sembrare più semplice avere tutto in un unico file. Tuttavia, risulta che in questo modo ci sia maggior spazio sul disco e maggiore banda per mantenere l'archivio upstream separato da tutti i cambiamenti specifici.

È anche più semplice tenere traccia di cosa è necessario cambiare per Debian.

Processo di pacchettizzazione

Il processo di pacchetizzazione normalmente è questo:

1. rinominare il tarball upstream in modo che segua uno specifico modello di denominazione.
2. estrarre tarball upstrean
3. aggiungere i file di pacchettizzazione di Debian (in una sotto-cartella chiamata "debian"), e apportare altre modifiche necessarie
4. creare il pacchetto sorgente
5. creare il pacchetto binario
6. caricare il pacchetto sorgente e quello binario sui server Debian

Per questa guida Lars ha usato this tarball.

Passo 1: rinominare il tarball

Gli strumenti per la pacchettizzazzione di Debian assumono che il tarball abbia un nome specifico.

Il nome è composto dal nome del pacchetto sorgente, un underscore, il numero di versione upstream seguito da .orig.tar.gz. I l nome del pacchetto sorgente sovrebbe essere minuscolo e può contenere lettere, cifre e trattini.

Se il developer upstream usa un nome idoneo come nome per il pacchetto sorgente Debian, si dovrebbe usare quello.

In caso contrario, si dovrebbe cambiare il nome quanto basta per renderlo adatto a Debian.

Nel nosro caso, abbiamo un nome appropiato, "hithere", quindi non preoccupiamoci di questo.

Quindi il risultato dovrebbe essere un file chiamato hithere_1.0.orig.tar.gz.

Osserva che c'è un underscore nel nome, e non un trattino. Questo è importante in quanto gli strumenti per la pacchettizazzione sono pignoli.

# mv hithere-1.0.tar.gz hithere_1.0.orig.tar.gz

Passo 2: spacchettare il tarball

Dovremmo avere una cartella chiamata "hithere-1.0". In generale, i sorgenti dovrebbero andare in una cartella chiamata con il nome del pacchetto sorgente e la versione upstream, con un trattino ( e non un underscore ) tra i due.

This is again because the packaging tools are picky.

In questo caso, il developer upstream ha creato il tarball usando la directory giusta

 # tar xf hithere_1.0.orig.tar.gz

Passo 3: aggiungere i file di pacchettizzazione di debian

Tutti i file vanno nella sottocartella debian/ all'interno della cartella sorgente

# cd hithere-1.0
# mkdir debian

Ci sono molti file da fornire, guardiamoli in ordine.

debian/changelog

Il primo file è debian/changelog. Questo è il log dei cambiamenti del pacchetto Debian.

In questo file non c'è bisogno di elencare tutte le modifiche apportate al codice upstream, It does not need to list everything that has changed in upstream code, anche se può essere utile agli utenti riepilogare questi cambiamenti..

Dato che stiamo usando la prima versione, non c'è nessun cambiamento da registrare. Tuttavia, abbiamo comunque bisogno del file "changelog", perchè gli strumenti per la pacchettizzazione leggono alcune informazioni da esso. Soprattutto, leggono la versione del pacchetto.

debian/changelog ha un formato davvero particolare. Il modo più facile per crearlo è usare il programma dch .

# dch --create -v 1.0-1 --package hithere

Il risultato sarà un file come questo:

hithere (1.0-1) UNRELEASED; urgency=low

  * Initial release. (Closes: #XXXXXX)

 -- Lars Wirzenius <liw@liw.fi>  Thu, 18 Nov 2010 17:25:32 +0000

Nota bene:

• La parte hithere DEVE essere la stessa del nome del pacchetto sorgente.

  • 1.0-1 è la versione. La prte 1.0 è la versione upstream. La parte -1 è la versione Debian : la prima versione del pacchetto Debian della versione upstream 1.0. Se il pacchetto Debian ha un bug, che viene corretto, ma la versione di upstream resta la stessa, la versione successiva del pacchetto verrà chiamata 1.0-2. Quella ancora dopo 1.0-3, e così via.

• La destinazione di upload viene chiamata UNRELEASED. Dice allo programma di caricamento dove il pacchetto binario deve essere caricato. UNRELEASED significa che il pacchetto non è pronro per essere caricato. È una buona idea lasciare UNRELEASED così non caricherai nulla per sbaglio.

• Ignora urgency=low per adesso.

• Il (Closes: #XXXXXX) serve per chiudere bug quando il pacchetto viene caricato. Questo è il modo consueto per chiuedere i bug in Debian: quando il pacchetto che corregge un bug viene caricato, il bug tracker lo avverte e segna il bug come chiuso.

Possiamo rimuovere la parte (Closes...). Oppure no. Non è importante adesso.

• La linea finale nel changelog indica chi ha creato questa versione del pacchetto, e quando. Il programma dch prova ad indovinare il nome e l'indirizzo e-mail, ma puoi configurarlo con le informazioni giuste Guarda la pagina di manuale dch(1) per i dettagli.

debian/compat

Questo file dovrebbe contenere il numero 7. Questo è un numero magico. Non inserire nessun altro numero. debian/compat specifica "il livello di compatibilità" per il programma debhelper. Per ora non abbiamo bisogno di sapere cosa significa.

debian/control

Il file "control" descrive il pacchetto sorgente e binario, e aggiunge anche alcune informazioni su di essi, come il loro nome, chi è il maintainer del pacchetto, etc. Sotto c'è un esempio di come potrebbe essere.

Source: hithere
Maintainer: Lars Wirzenius <liw@liw.fi>
Section: misc
Priority: optional
Standards-Version: 3.9.0
Build-Depends: debhelper (>= 7.3.8)

Package: hithere
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: greet user
 hithere greets the user, or the world.

Ci sono molti campi richiesti, ma per ora non preoccuparti del loro significato In debian/control, ci sono due paragrafi.

Il primo descrive il pacchetto sorgente:

"Source:"

fornisce il nome del pacchetto sorgente.

"Maintainer:"

fornisce il nome e l'e-mail della persone reponsabile del pacchetto.

"Build-Depends:"

elenca i pacchetti che hanno bisogno di essere installati per creare il pacchetto. Pacchetti che sono o non sono necessari per usare il pacchetto

Il secondo paragrafo descrive il pacchetto binario creato dai sorgenti. Attualmente, è possibile creare molti pacchetti binari dallo stesso sorgente.

"Package:"

è il nome del pacchetto binario. Il nome può essere differente dal pacchetto sorgente.

"Architecture:"

indica con qualche architettura del computer il pacchetto binario dovrebbe funzionare: i386 per i processori 32-bit della Intel, amd64 per 64-bit, armel per ARM, e così via. Debian funziona su circa una dozzina di architetture, quindi il supporto alle architetture è cruciale. Il campo "Architecture:" può contenere nomi di particolari architetture, ma di solito contiene uno o due valori speciali.

"any"

(che possiamo vedere nell'esempio) significa che il pacchetto può essere costruito per qualsiasi architettura. In altre parola il codice è stato scritto per essere portabile, quindi non c'è bisogno di troppe necessità per quanto riguarda l'hardware. Tuttavia, il pacchetto binario deve essere pacchettizato per ogni architettura separatamente.

"Depends:"

visualizza i pacchetti che devono essere installati per potere avviare i programmi nel pacchetto binario. Elencare queste dipendenze manualmente può essere noioso.

Per fare questo lavoro, il campo ${shlibs:Depends} deve essere presente. Il campo shlibs viene usato per indicare le librerie condivise, gli altri campi sono invece sono usati da debhelper per altre dipendenze, queste devono essere aggiunte manualmente ai campi Depends o Build-Depends ma la sintassi ${...} funziona solo con il campo Depends

"Description:"

è la descrizione del pacchetto che è molto utile agli utenti.