• Diff for "it/Packaging/Intro"

Translation(s): English - Italiano

Introduzione alla pacchettizzazione per Debian

Seminario online tenuto da Lars Wirzenius per Debian Women, 18-Nov-2010

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

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

Requisiti

In questa guida si presume che:

• si sappia installare pacchetti binari;

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

Requisiti tecnici:

• build-essential

• devscripts

• debhelper version 7

I tre concetti centrali

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 altro 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), esattamente ciò che Debian prende e dal quale costruisce un pacchetto. Quando si ha un tarball upstream, il passo successivo è creare un pacchetto sorgente per Debian, dal quale sia possibile creare il pacchetto binario che è quello che effettivamente verrà installato.

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

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

3. 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 pacchettizzazione normalmente è questo:

1. rinominare il tarball upstream in modo che segua uno specifico modello di denominazione.
2. estrarre il tarball upstream
3. aggiungere i file di pacchettizzazione di Debian (in una sotto-directory 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 questo tarball.

Fase 1: rinominare il tarball

Gli strumenti per la pacchettizzazione 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. Il nome del pacchetto sorgente dovrebbe 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 lasciare 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.

Si noti che c'è un underscore 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

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

In questo caso, il developer upstream ha creato il tarball usando la 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 usando la prima versione, non c'è nessun cambiamento da registrare. Tuttavia, abbiamo comunque bisogno del file "changelog", perchè gli strumenti per la pacchettizzazione ne traggono alcune informazioni, 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.

• La destinazione di upload viene chiamata UNRELEASED. 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.

• Ignora urgency=low per adesso.

• Il (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 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 è necessario preoccuparsi 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 persona 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 ad esse è 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 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 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.

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 concentreremo solo sugli aspetti tecnici. Possiamo tornare su debian/copyright più tardi.

debian/rules

Dovrebbe essere simile a questo:

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

• Nota: L'ultima linea dovrebbe essere indentata solo con un TAB, non da spazi.

Questo file è un makefile, e il TAB è ciò che vuole il comando make.

debian/rules potrebbe essere un file difficile da comprendere, tuttavia grazie al comando dh in debhelper 7 è possibile renderlo, in alcuni casi, meno complicato.

debian/source/format

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

Questo è il numero di versione per il formato del pacchetto sorgente, che potrebbe sembrare lo stessa della versione upstream, ma è solo una coincidenza.

Fasi 4 e 5: compilare il pacchetto

Ora possiamo costruire il pacchetto. Il comando da lanciare è il seguente:

debuild -us -uc

Ci sono molti comandi che possiamo usare per creare un pacchetto, ma questo è l'unico che useremo. Se questo comando verrà lanciato, il risultato ottenuto sarà simile a questo:

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 si ottiene 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 alcune cose da fare qui: ma prima cerchiamo di capire, almeno sommariamente, come funziona la pacchettizzazione in Debian. Quando un programma viene compilato, ed è "installato", non viene installato in "/usr" o in "/usr/local" come avviene di solito, ma da qualche parte nella directory debian/.

Creeremo un sottoinsieme del filesystem in debian/hithere e che poi verrà inserita 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 abbiamo bisogno di modificare il file "debian/rules" per far sì che il programma venga installato 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 processi che avvia 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 linea finale nel nuovodebian/rules è una tecnica usata per invocare il Makefile upstream debian/rules con gli argomenti giusti.

Proviamo a creare di nuovo il pacchetto, e noteremo che il processo fallirà ancora.

Questa volta il comando sbagliato è:

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

Stiamo provando ad installare i binari nel posto giusto, ma questo non esiste. Per correggere questo problema dobbiamo dire al programma di pacchettizzazione di creare prima la directory.

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

Fortunatamente il programma per la pacchettizzazione (nello specifico debhelper) ci 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 linea crea una directory per il manuale, ne avremmo bisogno più tardi. Ora la creazione del pacchetto riesce, ma ci sono ancora alcuni piccoli problemini.

debuild lancia lo strumento lintian, che controlla se il pacchetto è stato creato con alcuni errori non gravi. Ne vengono riportati molti per questo pacchetto.

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.

Normalmente dovrebbero essere corretti, ma nessuno di questi sembra essere un problema nel caso volessimo provare il pacchetto. Quindi ignoriamoli per ora.

Dando un'occhiata alla directory superiore troveremo 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.diff.gz
hithere_1.0-1_amd64.changes  hithere_1.0-1.dsc

I seguenti comandi installeranno il pacchetto che hai creato, non eseguirli sul tuo computer! Generalmente, è meglio creare pacchetti su un computer di cui stato stati fatti dei backup, sempre che non ti piaccia reinstallare tutto se le cose vanno per il verso sbagliato.

Le macchine virtuali sono un buon posto per lo sviluppo.

# sudo dpkg -i ../hithere_1.0-1_amd64.deb

E questo è il risultato:

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 possiamo testare il pacchetto? Eseguendo il comando.

# hithere

Funziona! Ma non è perfetto. Ricorda, litian ci ha restituito degli avvertimenti (es."debian/copyright" vuoto etc).

Ora abbiamo un pacchetto pronto, ma non abbastanza per gli alti standard di qualità richiesti da Debian.

Conclusioni

Una volta che hai creato i tuoi pacchetti, vorrai probabilmente sapere come creare il tuo repository apt, così da fare in modo che i pacchetti siano semplici da installare. Lo strumento migliore per farlo è reprepro.

Per eseguire più test sul tuo pacchetto puoi usare lo strumento chiamato piuparts (è stato scritto originariamente da me e non sono mai stati riscontrati problemi di nessun genere).

E se finalmente inizierai ad apportare cambiamenti ai sorgenti upstream, forse ti piacerebbe conoscere lo strumento quilt.

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

Domande e risposte

DOMANDA: posso generare un pacchetto per più architetture?

RISPOSTA: non credo che Debian supporti la creazione di un pacchetto che funzioni su diverse architettura, tranne naturalmente i programmi scritti in modo da essere portabili ( "Architecture: all" ).

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

RISPOSTA: per i pacchetti binari "blob", devi trattare il tarball con i "blob" come pacchetto sorgente, e fare in modo da evitare il processo di compilazione; però non ho mai avuto a che fare questo tipo di problema.

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: ho bisogno di ricreare il tarball originale se non contiene il modello di denominazione corretto?

RISPOSTA: penso che tu non abbia bisogno di ricreare il pacchetto. È stato necessario per diversi anni, ma adesso con il comando "dpkg-source -x" è possibile rinominare la directory nel modo corretto.

DOMANDA: ho notato che i 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 originali sono solo nel pacchetto sorgente.

DOMANDA: Liw ha detto che il file compact deve contenere il numero 7, immagino quindi che basti crearlo semplicemente con il comando 'echo 7 >debian/compat'.

RISPOSTA: si, è sufficiente avere il singolo carattere 7 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.

DOMANDA: quando il comando "dpkg-source -x" viene lanciato? 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 dal mio i386, e c'è un modo facile per farlo?

RISPOSTA: questa dovrebbe essere 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 dovrei usare solo Depends invece che Build-Depends?

RISPOSTA: Build-Depends è necessario solo durante la creazione del pacchetto mentre viene compilato, e quando la sua test suite viene lanciata. Depends è necessario solo quando il pacchetto deve venire usato, dopo essere stato installato. A volte alcune di queste dipendenze devono essere presenti sia durante la compilazione sia durante l'uso del programma, e in questo caso tu devi inserirle 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 andrà a cercarlo solo in Depends, non Build-Depends.

Tuttavia, se lo script PHP viene usato per un test e non viene includo 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 corrispondono a quelle in Depends? Sto pensando alle librerie linkate staticamente.

RISPOSTA: Build-Depends e Depends sono due cose completamente separate, ed è perfettamente corretto (da un punto dal punto di vista della pacchettizzazione) avere dipendenze in una e non in un'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) nessuno, ma la prima linea del changelog dovrebbe essere "Non-maintainer upload"

DOMANDA: quando creo un pacchetto con il campo "Architecture: all", alcuni dei file risultanti (b.build, .changes) continuano ad avere 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: puoi modificare il pacchetto sorgente ed eseguire un comando per creare un pacchetto binario fuori 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 alcun motivo di creare il pacchetto su un'architettura particolare, se dice solo i386 e amd64, non ha alcun senso compilarlo su un amd64.

DOMANDA: l'esempio 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à compilato senza nessuna aggiunta.

DOMANDA: l'euristica è una cosa buona, ma se voglio passare --una-opzione-speciale a ./configure o qualche argomento per cmake, l'euristica si occupa di 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 sovrascrivere _dh_auto_configure <TAB>dh_auto_configure -- --tuo-parametro

dh ha un meccanismo di estensione/sovrascrittura che ti permette di sovrascrivere particolari parti; è davvero semplice da usare, una volta che hai letto la documentazione ovviamente.

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

RISPOSTA: dh esegue una specifica sequenza di comandi per compilare i pacchetti; ogni comando inizia con i caratteri "_dh", e ognuno di questi può essere sovrascritto avendo una voce all'interno di "debian/rules" chiamata override_dh_REGOLA.

È possibile aggiungere l'opzione --no-act al comando dh in debian/rules per vedere quali comandi vengono eseguiti, devi anche leggere il manuale di quel comando per vedere se puoi configurarlo (tramite file come debian/hithere.dirs), o se hai bisogno di sovrascriverlo.

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: Ho sempre lanciato i comandi di pacchettizzazione in hithere-1.0, e avevo 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). L'unica cosa da fare è sovrascrivere _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") e provare a compilare e correggere ogni tipo di errore. Non è un buon processo, ma per qualcosa di meglio dovresti imparare ad usare quilt, e possibilmente anche usare una 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'unico problema è che il mio pacchetto configura gli altri pacchetti in una certa maniera in modo che si adatti alle esigenze di alcune persone. Per fare questo apporta anche alcuni cambiamenti critici al sistema, come attivare il routing del network e così via... c'è qualche regola seconda la quale un pacchetto ufficiale ha il permesso di fare una cosa o no? Un pacchetto del genere può diventare un pacchetto ufficiale?

RISPOSTA: http://www.debian.org/doc/debian-policy/ è la migliore documentazione 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 l'altro pacchetto non fornisca un'interfaccia documentata per farlo.

Vedi anche

• http://www.debian.org/devel/

• http://www.debian.org/doc/debian-policy/

• http://liw.fi/manpages/