Differences between revisions 28 and 29
Revision 28 as of 2013-12-15 14:26:43
Size: 32255
Comment: sync with English master
Revision 29 as of 2014-03-22 13:30:32
Size: 32566
Comment: sync with English master + minor fixes
Deletions are marked like this. Additions are marked like this.
Line 192: Line 192:
Il primo descrive '''il pacchetto sorgente''':

  "Source:":: fornisce il nome del pacchetto sorgente.
  "Maintainer:":: fornisce il nome e l'e-mail della persona reponsabile del pacchetto.
  "Priority:":: fornisce la priorità del pacchetto (una tra "required", "important", "standard", "optional" o "extra"). In generale un pacchetto è "optional" (opzionale) a meno che non sia "essential" (essenziale) per un sistema standard funzionante, cioè per l'avvio o il funzionamento della rete. Un pacchetto dovrebbe essere "extra" invece di "optional", se va in conflitto con un altro pacchetto "optional" oppure se non è pensato per essere usato su un'installazione desktop standard. Esempi degni di nota di pacchetti "extra" sono i pacchetti per il debug. (Nota aggiunta da Sebastian Tennant).
  "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 primo paragrafo descrive '''il pacchetto sorgente''' con questi campi:

  Source:: Il nome del pacchetto sorgente.
  Maintainer:: Il nome e l'indirizzo di posta elettronica della persona responsabile del pacchetto.
  Priority:: La priorità del pacchetto (una tra "required", "important", "standard", "optional" o "extra"). In generale un pacchetto è "optional" (opzionale) a meno che non sia "essential" (essenziale) per un sistema standard funzionante, cioè per l'avvio o il funzionamento della rete. Un pacchetto dovrebbe essere "extra" invece di "optional", se va in conflitto con un altro pacchetto "optional" oppure se non è pensato per essere usato su un'installazione desktop standard. Esempi degni di nota di pacchetti "extra" sono i pacchetti per il debug. (Nota aggiunta da Sebastian Tennant).
  Build-Depends:: L'elenco dei pacchetti che devono essere installati per creare il pacchetto; possono essere necessari per usare il pacchetto oppure no.
Line 199: Line 199:
Il secondo paragrafo descrive il '''pacchetto binario''' creato dai sorgenti. Di fatto, è possibile creare molti pacchetti binari dallo stesso sorgente.

  "Package:"
:: è il nome del pacchetto binario. Il nome può essere differente dal pacchetto sorgente.
  "Architecture:":: ind
ica con quale 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 ad esse è cruciale; il campo "Architecture:" può contenere nomi di particolari architetture, ma di solito contiene uno tra due valori speciali.
    "any":: (come nell'esempio) significa che il pacchetto può essere costruito per qualsiasi architettura. In altre parole il codice è stato scritto per essere portabile, in modo che non ci sia bisogno di fare troppe supposizioni sul tipo di hardware. Tuttavia, il pacchetto binario deve comunque essere pacchettizato per ogni architettura separatamente.
    "all":: significa che il medesimo pacchetto binario funzionerà su tutte le architetture, senza dover essere creato separatamente per ciascuna. Per esempio, un pacchetto contenente solamente script per la shell avrebbe il valore "all"; gli script per la shell funzionano nello stesso modo ovunque e non necessitano di essere compilati.
  "Depends:":: elenca i pacchetti che devono essere installati affinché i programmi nel pacchetto binario funzionino.
  Elencare queste dipendenze manualmente è noioso ed è facile fare errori. Per fare funzionare la cosa deve essere presente il campo magico '''''${shlibs:Depends}'''''. Il campo shlibs indica le dipendenze da librerie condivise. L'altro campo magico è invece usato 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; è pensata per essere utile agli utenti.
Tutti i paragrafi dopo il primo descrivono i '''pacchetti binari''' creati dai sorgenti. Possono esserci molti pacchetti binari creati dallo stesso sorgente; nell'esempio qui riportate ce n'è uno solo. Vengono usati i seguenti campi:

  Package::
Il nome del pacchetto binario; può essere diverso da quello del pacchetto sorgente.
  Architecture:: Specifica con quale 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 ad esse è cruciale; il campo "Architecture" può contenere nomi di particolari architetture, ma di solito contiene uno tra due valori speciali.
    any:: (come nell'esempio) significa che il pacchetto può essere costruito per qualsiasi architettura. In altre parole il codice è stato scritto per essere portabile, in modo che non ci sia bisogno di fare troppe supposizioni sul tipo di hardware. Tuttavia, il pacchetto binario deve comunque essere pacchettizato per ogni architettura separatamente.
    all:: significa che il medesimo pacchetto binario funzionerà su tutte le architetture, senza dover essere creato separatamente per ciascuna. Per esempio, un pacchetto contenente solamente script per la shell avrebbe il valore "all"; gli script per la shell funzionano nello stesso modo ovunque e non necessitano di essere compilati.
  Depends:: L'elenco dei pacchetti che devono essere installati affinché i programmi nel pacchetto binario funzionino.
  Elencare queste dipendenze manualmente è noioso ed è facile fare errori. Per fare funzionare la cosa deve essere presente il campo magico '''''${shlibs:Depends}'''''. L'altro campo magico è invece usato da debhelper: '''''${misc:Depends}'''''. Il campo shlibs indica le dipendenze da librerie condivise, il campo misc è per alcune cose fatte da debhelper. Per altre dipendenze, queste devono essere aggiunte manualmente ai campi Depends o Build-Depends e la sintassi magica ${...} funziona solo con il campo Depends.
  Description:: La descrizione completa del pacchetto; è pensata per essere utile agli utenti. La prima riga è usata come breve riassunto (sinossi) e il resto della descrizione deve essere una descrizione indipendente più lunga del pacchetto.

Translation(s): English - Español - Italiano - Català - Română - Русский



Introduzione alla pacchettizzazione per Debian

Seminario online tenuto in IRC da Lars Wirzenius per Debian Women il 18 novembre 2010,

  • con un paio di piccoli aggiunte, chiaramente indicate, da parte di Sebastian Tennant (a seguito del mio corso intensivo sulla pacchettizzazione in Debian da parte di Daniel Baumann al DebCamp 2011, Banja Luka)

Questa è una lezione introduttiva alla [Packaging|creazione di pacchetti per Debian]] quindi non verranno spiegati i meccanismi più complessi della pacchettizzazione, ma mostrato invece come creare pacchetti per programmi semplici da pacchettizzare.

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

Requisiti

In questa guida si presume che:

  • si sappia installare pacchetti binari;
  • si conosca l'uso di base della riga di comando e l'utilizzo di un editor di testo a scelta (emacs, vim, gedit, kate, etc.);

Requisiti tecnici:

I tre concetti centrali

I tre concetti centrali sono

  • archivio upstream:

    • Di solito le persone pacchettizzano software che qualcun altro, chiamato "sviluppatore upstream", ha scritto.
    • Lo sviluppatore ustream rilascia una versione del suo programma e il risultato è il "pacchetto dei sorgenti upstream" o "tarball".
    • Un tarball è il file .tar.gz o .tgz creato dall'autore upstream originale (la parola tarball fa parte del gergo informatico), e può anche essere compresso come .tar.bz2,.tb2 o .tar.xz; è esattamente ciò che Debian prende e dal quale costruisce un pacchetto.

  • pacchetto sorgente:

    • quando si ha l'archivio tar originale, il passo successivo è creare il pacchetto sorgente Debian.

  • pacchetto binario:

    • da tale pacchetto sorgente si può poi creare il pacchetto binario Debian che è ciò che viene di fatto installato.

Il pacchetto sorgente consiste, nella sua forma più semplice, di tre file:

  • Il tarball upstream, rinominato in modo che segua un modello sistematico
  • una directory debian, con tutte le modifiche al sorgente upstream, più tutti i file creati per il pacchetto Debian. Questo ha estensione .debian.tar.gz

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

Tutto questo può sembrare a prima vista più complicato del necessario; potrebbe sembrare più semplice avere tutto in un unico file.

  • Tuttavia, mantenere l'archivio upstream separato da tutti i cambiamenti specifici per Debian ha come risultato un risparmio di spazio sul disco e di banda.
  • Così è anche più facile tenere traccia di ciò che è stato necessario cambiare per Debian.

Processo di pacchettizzazione

Il processo di pacchettizzazione normalmente è questo:

  • Fase 1: rinominare il tarball upstream
  • Fase 2: estrarre il tarball upstream
  • Fase 3: aggiungere i file di pacchettizzazione di Debian
  • Fase 4: creare il pacchetto
  • Fase 5: installare il pacchetto

A questo punto si può testare il pacchetto sul proprio computer.

I pacchetti sorgente e binario possono essere caricati sui server Debian.

Per questa guida Lars ha usato questo tarball.

Fase 1: rinominare il tarball originale

Gli strumenti per la pacchettizzazione di Debian assumono che il tarball abbia un nome estremamente specifico. Deve seguire un modello specifico per l'assegnazione dei nomi.

Il nome è composto dal nome del pacchetto sorgente, un trattino basso (underscore, _), il numero di versione upstream seguito da .orig.tar.gz. Il nome del pacchetto sorgente dovrebbe essere tutto minuscolo e può contenere lettere, cifre e trattini. Sono permessi anche alcuni altri caratteri.

Se il developer upstream usa un nome idoneo come nome per il pacchetto sorgente Debian, si dovrebbe lasciare quello. In caso contrario, si dovrebbe cambiare il nome il minimo necessario per renderlo adatto a Debian. Nel caso considerato, il nome è stato scelto saggiamente in modo appropiato, "hithere", quindi ci si può non preoccupare del nome.

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

Si noti che c'è un trattino basso (_) nel nome, e non un trattino (-). Questo è importante in quanto gli strumenti per la pacchettizazione sono pignoli.

  • $ mv hithere-1.0.tar.gz hithere_1.0.orig.tar.gz

Fase 2: spacchettare il tarball originale

In generale, i sorgenti dovrebbero essere messi in una directory chiamata con il nome del pacchetto sorgente e la versione upstream, con un trattino (e non un trattino basso) tra i due; perciò idealmente la tarball upstream verrà spacchettata in una directory chiamata "hithere-1.0".

In questo caso, il developer upstream ha fatto sì che il tarball si spacchettasse nella directory giusta.

  • $ tar xf hithere_1.0.orig.tar.gz

Fase 3: aggiungere i file di pacchettizzazione di Debian

Tutti i file vanno nella sottodirectory debian/ all'interno della directory 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, anche se può essere utile agli utenti riepilogare questi cambiamenti. Dato che stiamo creando la prima versione, non c'è nessun cambiamento da registrare. Tuttavia, abbiamo comunque bisogno di una voce all'interno del file "changelog", perché gli strumenti per la pacchettizzazione leggono alcune informazioni da tale file, in particolare 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 parte 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.

  • UNRELEASED è ciò che viene definita destinazione di upload. Dice al programma di caricamento dove il pacchetto binario deve essere caricato. UNRELEASED significa che il pacchetto non è pronto per essere caricato. È una buona idea lasciare UNRELEASED così non verrà caricato nulla per sbaglio.

  • Ignorare urgency=low per adesso, ma lasciarlo dov'è.

  • La parte (Closes: #XXXXXX) serve per chiudere i 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 sistema di tracciamento dei bug lo nota e segna il bug come chiuso. Si può rimuovere la parte (Closes...). Oppure no. Non è importante per il momento.

  • La riga 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 può essere configurato con le informazioni giuste. Vedere la pagina di manuale dch(1) per i dettagli.

debian/compat

Questo file dovrebbe contenere il numero 9. Questo è un numero magico. Non inserire nessun altro numero.

9

debian/compat specifica "il livello di compatibilità" per il programma debhelper. Per ora non è necessario sapere cosa significa.

debian/control

Il file "control" descrive i pacchetti sorgente e binario, e fornisce anche alcune informazioni su di essi, come il loro nome, chi è il maintainer del pacchetto, etc. Questo sottostante è un esempio di come potrebbe essere.

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

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

Ci sono molti campi obbligatori, ma per ora non è necessario preoccuparsi del loro significato. In debian/control, ci sono due paragrafi.

Il primo paragrafo descrive il pacchetto sorgente con questi campi:

Source
Il nome del pacchetto sorgente.
Maintainer
Il nome e l'indirizzo di posta elettronica della persona responsabile del pacchetto.
Priority
La priorità del pacchetto (una tra "required", "important", "standard", "optional" o "extra"). In generale un pacchetto è "optional" (opzionale) a meno che non sia "essential" (essenziale) per un sistema standard funzionante, cioè per l'avvio o il funzionamento della rete. Un pacchetto dovrebbe essere "extra" invece di "optional", se va in conflitto con un altro pacchetto "optional" oppure se non è pensato per essere usato su un'installazione desktop standard. Esempi degni di nota di pacchetti "extra" sono i pacchetti per il debug. (Nota aggiunta da Sebastian Tennant).
Build-Depends
L'elenco dei pacchetti che devono essere installati per creare il pacchetto; possono essere necessari per usare il pacchetto oppure no.

Tutti i paragrafi dopo il primo descrivono i pacchetti binari creati dai sorgenti. Possono esserci molti pacchetti binari creati dallo stesso sorgente; nell'esempio qui riportate ce n'è uno solo. Vengono usati i seguenti campi:

Package
Il nome del pacchetto binario; può essere diverso da quello del pacchetto sorgente.
Architecture
Specifica con quale 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 ad esse è cruciale; il campo "Architecture" può contenere nomi di particolari architetture, ma di solito contiene uno tra due valori speciali.
any
(come nell'esempio) significa che il pacchetto può essere costruito per qualsiasi architettura. In altre parole il codice è stato scritto per essere portabile, in modo che non ci sia bisogno di fare troppe supposizioni sul tipo di hardware. Tuttavia, il pacchetto binario deve comunque essere pacchettizato per ogni architettura separatamente.
all
significa che il medesimo pacchetto binario funzionerà su tutte le architetture, senza dover essere creato separatamente per ciascuna. Per esempio, un pacchetto contenente solamente script per la shell avrebbe il valore "all"; gli script per la shell funzionano nello stesso modo ovunque e non necessitano di essere compilati.
Depends
L'elenco dei pacchetti che devono essere installati affinché i programmi nel pacchetto binario funzionino.

Elencare queste dipendenze manualmente è noioso ed è facile fare errori. Per fare funzionare la cosa deve essere presente il campo magico ${shlibs:Depends}. L'altro campo magico è invece usato da debhelper: ${misc:Depends}. Il campo shlibs indica le dipendenze da librerie condivise, il campo misc è per alcune cose fatte da debhelper. Per altre dipendenze, queste devono essere aggiunte manualmente ai campi Depends o Build-Depends e la sintassi magica ${...} funziona solo con il campo Depends.

Description
La descrizione completa del pacchetto; è pensata per essere utile agli utenti. La prima riga è usata come breve riassunto (sinossi) e il resto della descrizione deve essere una descrizione indipendente più lunga del pacchetto.

debian/copyright

È un file molto importante, ma per ora ci basterà lasciarlo vuoto.

Per Debian, questo file è usato per tenere traccia del copyright e delle informazioni legate ad esso. Tuttavia, non è importante da un punto di vista tecnico. Per adesso ci si concentrerà solo sugli aspetti tecnici; si potrà tornare in seguito su debian/copyright.

debian/rules

Dovrebbe essere simile a questo:

#!/usr/bin/make -f
%:
        dh $@
  • <!> Nota: L'ultima riga dovrebbe essere fatta rientrare solo con una tabulazione (TAB), non con spazi.

Questo file è un makefile e la tabulazione è ciò che vuole il comando make.

debian/rules può essere un file piuttosto complesso, tuttavia grazie al comando dh in debhelper 7 è possibile mantenerlo semplice come in questo esempio per molti casi.

debian/source/format

L'ultimo file richiesto è debian/source/format, e dovrebbe contenere il numero di versione "3.0 (quilt)".

        3.0 (quilt)

Questo è il numero di versione per il formato del pacchetto sorgente, e anche se è lo stesso della versione upstream, questa è solo una coincidenza.

Fase 4: compilare il pacchetto

Primo tentativo

Ora si può costruire il pacchetto.

Ci sono molti comandi utilizzabili ma questo è quello che verrà usato. Eseguendo il comando si otterrà un output simile al seguente:

  • $ debuild -us -uc

make[1]: Entering directory `/home/liw/debian-packaging-tutorial/x/hithere-1.0'
install hithere /home/liw/debian-packaging-tutorial/x/hithere-1.0/debian/hithere/usr/local/bin
install: cannot create regular file `/home/liw/debian-packaging-tutorial/x/hithere-1.0/debian/hithere/usr/local/bin': No such file or directory
make[1]: *** [install] Error 1
make[1]: Leaving directory `/home/liw/debian-packaging-tutorial/x/hithere-1.0'
dh_auto_install: make -j1 install DESTDIR=/home/liw/debian-packaging-tutorial/x/hithere-1.0/debian/hithere returned exit code 2
make: *** [binary] Error 29
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2
debuild: fatal error at line 1325:
dpkg-buildpackage -rfakeroot -D -us -uc failed

Qualcosa è andato storto. Questo è quello che accade di solito, si fa del proprio meglio per creare i file debian/* , ma c'è sempre qualcosa che non viene fatta nel modo giusto. Le cose sono andate nel verso sbagliato in questo pezzo:

install hithere /home/liw/debian-packaging-tutorial/x/hithere-1.0/debian/hithere/usr/local/bin

Il Makefile upstream sta tentando di installare il programma compilato in un posto sbagliato.

Ci sono diverse cose in ballo: una riguarda il modo in cui funziona la pacchettizzazione in Debian.

Correzione

Quando il programma viene compilato, ed è "installato", non viene installato in usr o in /usr/local come avviene di solito, ma da qualche parte nella sottodirectory debian/.

Viene creato un sottoinsieme dell'intero file system in debian/hithere che poi verrà inserito nel pacchetto binario. Quindi .../debian/hithere/usr/local/bin è la posizione giusta, a parte il fatto che non dovrebbe essere installato in usr/local, ma direttamente in usr.

Quindi è necessario modificare il file debian/rules per far sì che dica al Makefile di installare il programma nella giusta directory (debian/hithere/usr/bin):

#!/usr/bin/make -f
%:
        dh $@

override_dh_auto_install:
        $(MAKE) DESTDIR=$$(pwd)/debian/hithere prefix=/usr install

Per capire cosa fa il codice riportato sopra bisogna sapere come funzionano i Makefile e i vari passi dell'esecuzione di debhelper.

Per ora basta dire che c'è un comando che viene lanciato dal debhelper che si occupa di installare i file upstream, e che questo passaggio si chiama dh_auto_install.

Abbiamo bisogno di sovrascrivere questo passaggio con la regola in debian/rules chiamata override_dh_auto_install.

La riga finale nel nuovo debian/rules è una tecnica degli anni '70 usata per invocare il Makefile upstream debian/rules con gli argomenti giusti.

Riprovare

  • $ debuild -us -uc

Fallisce ancora!

Questa volta il comando sbagliato è:

install hithere /home/liw/debian-packaging-tutorial/x/hithere-1.0/debian/hithere/usr/bin

Si sta tentando di installare i binari nel posto giusto, ma questo non esiste. Per correggere questo problema è necessario dire agli strumenti di pacchettizzazione di creare prima la directory.

Normalmente, il Makefile upstream la creerebbe esso stesso, ma in questo caso lo sviluppatore upstream è stato troppo pigro per farlo.

Un'altra correzione

Il programma per la pacchettizzazione (nello specifico debhelper) fornisce un modo per farlo.

  • Basta creare un file chiamato debian/hithere.dirs, con il seguente contenuto:

usr/bin
usr/share/man/man1

La seconda riga crea una directory per la pagina di manuale, che sarà necessaria più avanti. Si deve porre attenzione nella manutenzione di questi file *.dirs perché possono dare origine a directory vuote nelle versioni future del proprio pacchetto, se le voci elencate in questi file non sono più valide.

Un'altra prova

  • $ debuild -us -uc

Ora la creazione del pacchetto riesce, ma ci sono ancora alcuni piccoli problemini.

debuild lancia lo strumento lintian, che controlla la presenza nel pacchetto creato di alcuni errori comuni. Per questo pacchetto ne vengono riportati diversi.

Now running lintian...
W: hithere source: out-of-date-standards-version 3.9.0 (current is 3.9.1)
W: hithere: copyright-without-copyright-notice
W: hithere: new-package-should-close-itp-bug
W: hithere: wrong-bug-number-in-closes l3:#XXXXXX
Finished running lintian.

Prima o poi dovrebbero essere corretti, ma nessuno di questi sembra essere un problema nel caso si volesse provare il pacchetto. Quindi possono essere ignorati per ora.

Cercando nella directory superiore si trova il pacchetto che è stato creato.

  • $ ls ..

hithere-1.0                  hithere_1.0-1_amd64.deb  hithere_1.0.orig.tar.gz
hithere_1.0-1_amd64.build    hithere_1.0-1.debian.tar.gz
hithere_1.0-1_amd64.changes  hithere_1.0-1.dsc

Fase 5: installare il pacchetto

Il seguente comando installerà il pacchetto che è stato creato.

NON dovrebbe essere eseguito su un computer che non si vuole danneggiare!

  • Generalmente, è meglio fare lo sviluppo dei pacchetti su un computer di cui sono stati fatti dei backup e sul quale non è un problema reinstallare tutto da zero nel caso le cose vadano veramente per il verso sbagliato.

Le macchine virtuali sono un buon posto per lo sviluppo.

  • $ sudo dpkg -i ../hithere_1.0-1_amd64.deb

liw@havelock$ sudo dpkg -i ../hithere_1.0-1_amd64.deb
[sudo] password for liw: 
Selecting previously deselected package hithere.
(Reading database ... 154793 files and directories currently installed.)
Unpacking hithere (from ../hithere_1.0-1_amd64.deb) ...
Setting up hithere (1.0-1) ...
Processing triggers for man-db ...
liw@havelock$ 

Come si può testare il pacchetto? Eseguendo il comando

  • $ hithere

Funziona! Ma non è perfetto. Ricordarsi del fatto che lintian ha restituito degli avvertimenti e che debian/copyright è vuoto, ecc.

Il pacchetto adesso funziona, ma non è abbastanza per gli alti standard di qualità richiesti da Debian per i suoi pacchetti.

Conclusioni

Una volta che si siano creati i propri pacchetti, si vorrà probabilmente sapere come creare un proprio repository apt, in modo che i pacchetti siano semplici da installare. Lo strumento migliore per farlo è reprepro.

Per eseguire più test sul pacchetto si può usare lo strumento chiamato piuparts (è stato scritto originariamente dall'autore di questa lezione perciò è perfetto e non è mai stato trovato alcun bug.... più o meno :)

Da ultimo, se si inizia ad apportare cambiamenti ai sorgenti upstream, si vorrà conoscere lo strumento quilt.

Un'altra serie di letture utili possono essere trovate nella pagina http://www.debian.org/devel/ .

Domande e risposte

DOMANDA: potresti chiarirmi come pacchettizzare programmi che si trovano già in forma binaria, come ad esempio i blob nvidia o simili?

RISPOSTA: per i pacchetti binari "blob", si deve trattare il tarball con i "blob" come pacchetto sorgente, ed evitare la loro compilazione dai sorgenti; però non ho mai avuto a che fare con questo tipo di pacchetti.

DOMANDA: esiste qualcosa di simile a PPA di ubuntu?

RISPOSTA: Debian non ha un servizio PPA come Ubuntu, però esistono gli strumenti per creare repository apt, c'è solo molto da configurare.

DOMANDA: è necessario ricreare il tarball originale se non contiene una cartella con il modello di denominazione corretto?

RISPOSTA: penso che al giorno d'oggi non sia necessario ricreare il pacchetto. Era necessario molti molti anni fa, ma adesso con il comando "dpkg-source -x" è possibile rinominare la directory nel modo corretto se necessario.

DOMANDA: alcuni pacchetti DEB "ufficiali" in /var/cache/apt/archives sono senza changelog e file compact. Perché?

RISPOSTA: i pacchetti .deb in /var/cache/apt/archives sono pacchetti binari: il changelog è incluso, ma con un nome differente, i file compat originali sono solo nel pacchetto sorgente.

DOMANDA: Liw ha detto che il file compact deve contenere il numero 9, immagino quindi che basti un file di un solo carattere creato semplicemente con il comando 'echo 9 >debian/compat'.

RISPOSTA: sì, è sufficiente avere il singolo carattere 9 in debian/compat.

DOMANDA: ho sentito di un specifico formato per "non maintainer" per i numeri di revisione di debian.

RISPOSTA: penso che tu intenda il formato "pacchetto nativo" (in cui il numero di versione è solo 1.0, e non 1.0-1), oppure il formato "upload da non maintainer", che per questa sessione è troppo complesso per essere spiegato nel modo giusto ma che avrebbe un formato tipo "1.0-1.1".

DOMANDA: quando viene lanciato il comando "dpkg-source -x"? Deve essere fatto manualmente?

RISPOSTA: "dpkg-source -x" è il comando per spacchettare un pacchetto sorgente Debian che è già stato creato (solitamente da qualcun altro); non viene usato di norma per la creazione di un pacchetto.

DOMANDA: come faccio a determinare quali pacchetti sono necessari per essere usati da Build-Depends?

RISPOSTA: di norma uso due metodi: a) con tentativi ed errori e b) leggendo il codice del programma. Entrambi sono di solito necessari.

DOMANDA: posso creare un pacchetto armel sul mio i386, e c'è un modo facile per farlo?

RISPOSTA: questa sarebbe una cross-compilazione, e non credo ci sia un modo facile per farla; ci sono strumenti per farla, ma non ho familiarità con loro, mi spiace.

DOMANDA: qual è la differenza tra Depends e Build Depends, in quali casi si deve usare solo Depends invece di Build-Depends?

RISPOSTA: le dipendenze Build-Depends sono necessarie solo durante la creazione del pacchetto mentre viene compilato, e quando la sua test suite viene lanciata. Le dipendenze Depends sono necessarie solo quando il pacchetto viene usato, dopo essere stato installato. Alcune di queste dipendenze devono essere presenti sia durante la compilazione sia durante l'uso del programma, e in questo caso devono essere inserite sia in Build-Depends e sia in Depends.

Ad esempio, se un pacchetto contiene uno script PHP, ma questo non viene lanciato quando il pacchetto viene creato, PHP dovrà essere inserito solo nel campo Depends, non Build-Depends.

Invece, se lo script PHP viene usato solo per un test e non viene incluso nel pacchetto binario, la dipendenza dovrà essere presente solo in Build-Depends e non in Depends.

DOMANDA: posso avere delle dipendenze in Build-Depends che non hanno una corrispondenza con quelle in Depends? Sto pensando alle librerie con link statico.

RISPOSTA: Build-Depends e Depends sono due cose completamente separate, ed è perfettamente corretto (dal punto di vista della pacchettizzazione) avere dipendenze in una e non nell'altra, o in entrambe.

DOMANDA: se volessi fare un NMU (non-maintainer upload), dovrei scrivere il mio nome nel campo Uploader, in quello del Maintainer, o in nessuno dei due?

RISPOSTA: (da parte di dapal) in nessuno, ma la prima riga del changelog dovrebbe essere "Non-maintainer upload"

DOMANDA: quando creo un pacchetto con il campo "Architecture: all", alcuni dei file risultanti (b.build, .changes) hanno comunque l'architettura con cui sono stati creati nel nome. È un comportamento corretto?

RISPOSTA: certo, è un comportamento corretto, non preoccuparti di questo.

DOMANDA: c'è un altro pacchetto come pacchetto sorgente o è lo stesso del pacchetto binario? Devo creare e mantenere due pacchetti? (binario e sorgente)?

RISPOSTA: devi modificare il pacchetto sorgente ed eseguire un comando per creare un pacchetto binario a partire dal pacchetto sorgente.

DOMANDA: non mi è ancora chiaro se l'opzione "Architecture" ha effetto sul pacchetto sorgente (nel processo di compilazione) o sul pacchetto binario (installazione ed esecuzione).

RISPOSTA: il campo "Architecture:" dice a chi sta creando il pacchetto se vi sia un senso nel creare il pacchetto su un'architettura particolare; se dice solo i386, non ha alcun senso compilarlo su un AMD64.

DOMANDA: l'esempio di file debian/rules contiene solo #!make -f , che fine ha fatto ./configure , o cmake o scons o gli altri strumenti di configurazione?

RISPOSTA: dh ha molta euristica, quindi un pacchetto con lo script ./configure, o uno degli altri consueti metodi per creare i pacchetti, verrà normalmente compilato senza bisogno di nessuna aggiunta.

DOMANDA: l'euristica è una cosa buona, ma se voglio passare --una-opzione-speciale come argomento per ./configure o cmake, l'euristica riesce a gestire i pacchetti sorgente che hanno bisogno ./waf o di altri stumenti di compilazione?

RISPOSTA: mi piace la risposta di dapal: <dapal> lilith: usando dh7, se vuoi passare qualche argomento a ./configure, basta usare qualcosa tipo ovverride_dh_auto_configure <TAB>dh_auto_configure -- --tuoi-parametri
dh ha un bel meccanismo di estensione/sovrascrittura che ti permette di sovrascrivere particolari parti; è davvero semplice da usare, una volta letta la documentazione.
<aron> Ho avuto brutte esperienze nel pacchettizzare software che usa waf come sistema di compilazione. Solitamente contiene blob binari che non possono essere estratti con gli strumenti standard (sì, incorpora un tgz nello script); ciò che è critico è che è difficile mantenere il pacchetto Debian con un sistema di compilazione waf perché non è pensato per aiutare gli autori upstream a compilare i proprio pacchetti in un modo sostanzialmente standard, ma solo in un modo "funziona per me". Si dovrebbe davvero suggerire agli autori upstream di prendere in considerazione un altro sistema (uno potente come CMake, Autotools; o uno più semplice come python-distutils-extra), se possibile.

DOMANDA: dove posso trovare la documentazione per sovrascrivere le impostazioni di debhelper 9?

RISPOSTA: dh esegue una specifica sequenza di comandi per compilare i pacchetti; ogni comando ha un nome tipo "dh_qualcosa", e ognuno di questi può essere sovrascritto con una voce "override_dh_qualcosa" all'interno di "debian/rules".

È possibile aggiungere l'opzione --no-act al comando dh in debian/rules per vedere quali comandi vengono eseguiti, poi si deve leggere il manuale di quel comando per vedere se è possibile configurarlo (tramite un file tipo debian/hithere.dirs) o se è necessario sovrascriverlo. In practica, usare l'opzione --no-act in combinazione con l'opzione --verbose permette di ottenere più dettagli riguardo a ciò che verrebbe eseguito.

DOMANDA: da dove lanci solitamente i tuoi comandi, all'interno della directory hithere-1.0 o fuori? Ci deve essere un'altra directory chiamata hithere (senza numerazione)?

RISPOSTA: Lancio sempre i comandi di pacchettizzazione in hithere-1.0 e di solito ho anche una directory superiore chiamata hithere, ma non è necessaria, serve solo a tenere i vari progetti più ordinati.

DOMANDA: ho un upstream che ha bisogno di qmake (usa Qt) prima di lanciare make, posso aggiungerlo a debian/rules? Come?

RISPOSTA: (da gregoa) debhelper supporta qmake dalla versione 7.4.12 (quindi non ci sono modifiche aggiuntive da apportare). Prima di quella versione era necessario usare override_dh_auto_configure :\n\tqmake

DOMANDA: qual è il miglior processo per aggiornare un pacchetto alla nuova versione upstream?

RISPOSTA: ah, non sono sicuro quale sia il processo migliore per farlo, ma fondamentalmente: spacchettare il sorgente upstream in una nuova directory, copiare la directory debian/* del vecchio pacchetto, aggiornare debian/changelog ("dch -v 1.2.3-4"), provare a compilare e correggere ogni tipo di errore. Non è esattamente un buon processo, ma per qualcosa di meglio dovresti imparare ad usare quilt, e possibilmente anche ad usare un sistema di revisione con la pacchettizzazione debian, ma è un argomento troppo ampio per essere trattato in questa sessione.

DOMANDA: ho creato un pacchetto debian che dipende da molti altri pacchetti. L'unica cosa che fa realmente il mio pacchetto è configurarne altri in una certa maniera in modo che si adattino alle esigenze di alcune persone. Per fare questo apporta anche alcuni cambiamenti critici al sistema, come attivare l'instradamento di rete nel kernel e così via... c'è una qualche regola su cosa un pacchetto ufficiale ha il permesso di fare e cosa no? Un pacchetto del genere può diventare un pacchetto ufficiale?

RISPOSTA: http://www.debian.org/doc/debian-policy/ è il migliore insieme di regole disponibile per sapere cosa un pacchetto Debian ufficiale ha il permesso o l'obbligo di fare.

I pacchetti Debian non sono autorizzati a modificare le configurazioni di altri pacchetti, a meno che questi non forniscano un'interfaccia documentata per farlo.

Vedi anche


CategoryPackaging