Translation(s): English - Español - Italiano - Português Brasileiro



Introduzione

Questo tutorial è basato su un Evento "Build it" di Debian Women tenuto da Margarita Manterola (in collaborazione con il progetto OpenHatch) il 07-maggio-2011

Questo tutorial tratta di come prendere un pacchetto esistente, ricompilarlo applicandovi delle modifiche e preparare tali modifiche in modo da poterle inviare come patch per un bug.

Requisiti

Per questo tutorial sono richieste molto poche conoscenze pregresse, ma non si deve aver paura della riga di comando :-)

Requisiti tecnici

Ricordarsi di eseguire:

   sudo apt-get install build-essential fakeroot devscripts

Configurare APT

Una volta che sono stati installati i pacchetti necessari, la cosa successiva da fare è assicurarsi di avere configurato sulla propria macchina alcuni repository per i sorgenti.

Aprire il file /etc/apt/sources.list e controllare che siano presenti una o più righe che iniziano con deb-src.

  • deb-src http://http.us.debian.org/debian unstable main

Queste righe sono necessarie per poter lavorare con i pacchetti sorgenti.

Se non c'è alcuna riga deb-src, è necessario aggiungerne almeno una. Ciò viene solitamente fatto copiando una delle righe deb esistenti e modificandola in deb-src. Lo si può fare usando un editor con i privilegi di amministratore (sudo gedit, sudo kate o sudo vim) aggiungendo questa riga:

Solitamente è una buona idea usare unstable come repository, dato che così si lavorera con la versione più recente del pacchetto, ma se si vuole modificare un pacchetto così come è presente in stable o testing si può usare allo stesso modo una di quelle distribuzioni.

Se si usa stable/testing/quello-che-è come distribuzione in uso, ottenere i sorgenti da unstable non ha effetto su di essa.

Una volta aggiunta la riga, è necessario eseguire

   sudo apt-get update

per aggiornare l'elenco dei pacchetti disponibili per l'installazione.

Creare la directory di lavoro

Una volta aggiunto l'URL per i sorgenti ai propri repository apt, si è in grado di ottenere i sorgenti di qualsiasi pacchetto Debian si desideri.

In questo specifico tutorial, verranno scaricati i sorgenti di un pacchetto a cui verrà fatta una piccola modifica in modo da farlo funzionare meglio.

È sempre una buona idea avere una directory dedicata a lavorare sul software sorgente, separata dalle altre directory usate per altri scopi. In caso non ce ne sia una già presente, è suggerita la creazione di una directory src con al suo interno un'altra chiamata debian:

   mkdir -p src/debian/; cd src/debian

All'interno di questa directory verranno messi i sorgenti del pacchetto su cui si lavorerà.

Scegliere il pacchetto

In questo esempio verrà usato un pacchetto chiamato fdupes, uno strumento per rilevare file duplicati, e verrà risolto il bug Debian #585426.

Si dovrebbe installare il pacchetto (o controllare se è installato e aggiornato alla versione più recente) prima di procedere, dato che sarà necessario avere tutte le dipendenze soddisfatte quando si installerà quello modificato.

Se fdupes non è installato, lo si può installare usando:

   sudo apt-get install fdupes

Controllare che il bug sia ancora presente; lo si può fare eseguendo

   fdupes --help

e controllando che la seconda riga delle informazioni per l'opzione --debug continui a non avere alcun senso.

La pacchettizzazione

Ottenere il pacchetto sorgente

Per poter ottenere i sorgenti di fdupes, ciò che si deve fare è andare nella directory che si è scelta (src/debian in questo esempio) ed eseguire (come utente normale):

   apt-get source fdupes

Sono stati scaricati 3 file (.dsc, .tar.gz, .diff.gz), che insieme creano il pacchetto sorgente Debian.

Probabilmente si è anche stati informati che fdupes è mantenuto via Git.

Una volta che il pacchetto è stato scaricato, si può controllare la directory in cui ci si è spostati, digitando ls, e si può vedere che oltre ai 3 file scaricati c'è anche una directory chiamata fdupes-1.50-PR2. Questi sono i sorgenti non pacchettizzati del pacchetto Debian.

Per entrare in quella directory, digitare: {{{ cd fdupes-1.50-PR2/ }}}

Controllando il contenuto di questa directory (digitando nuovamente ls), si vedono parecchi file di vario tipo ed una directory debian.

Ogni pacchetto Debian (o derivato da Debian) include una directory debian in cui vengono archiviate tutte le informazioni relative al pacchetto Debian. Tutto ciò che è al di fuori di quella directory, è codice originale a monte, cioè il codice originale rilasciato di chiunque abbia programmato il software.

Spostarsi nella directory debian digitando

   cd debian

Questa è la directory che il manutentore del pacchetto ha aggiunto al codice sorgente per creare il pacchetto.

In essa di solito si trovano molti file relativi alla versione Debian del programma, patch specifiche per Debian, pagine man, documentazione e così via. In questa occasione non ci soffermiamo oltre su questi file; guardare il suo contenuto usando ls.

Ricordarsi che

Spostarsi indietro di una directory, usando

   cd ..

Si dovrebbe essere di nuovo in fdupes-1.50-PR2, la directory principale del codice sorgente.

Ottenere le dipendenze di compilazione

Per quasi ogni programma, per poterlo compilare è necessaria l'installazione di alcune dipendenze. Le dipendenze sono i programmi o le librerie necessari per compilare il programma in questione. Solitamente si tratta di svariati pacchetti che finiscono in -dev, ma possono essere comprese anche altre cose, come automake o gcc, a seconda di quanti strumenti di sviluppo sono già stati installati sulla macchina.

apt fornisce un metodo per installare facilmente tutte le dipendenze necessarie:

   sudo apt-get build-dep fdupes

Una volta scaricati questi strumenti, si è pronti per compilare il pacchetto.

Ricompilare senza modifiche

Prima di fare una qualunque modifica al codice, compilare il pacchetto come è adesso, solo per assicurarsi che si compila e si installa in modo corretto. Eseguire:

   fakeroot debian/rules binary

Questo è il comando, quasi come make, che compila il pacchetto.

Ci vorrà probabilmente un po' di tempo perché l'esecuzione di questo comando venga completata, dato che solitamente prima deve essere eseguito ./configure, poi deve essere compilato il codice sorgente e quindi creato il pacchetto. Di fatto, esegue i comandi che sono elencati nel file debian/rules e si spera termini con un messaggio simile a:

   dpkg-deb: building package `fdupes' in `../fdupes_1.50-PR2-3_<mia arch>.deb'

localizzato nella lingua di sistema. <mia arch> può essere i386, amd64, a seconda della architettura sulla quale gira la macchina.

Una volta che il pacchetto è stato compilato correttamente, il passo successivo è installare questo file con:

   sudo dpkg -i ../fdupes_1.50-PR2-3_<mia arch>.deb

Dopo, controllare che il bug sia ancora presente eseguendo

   fdupes --help

Modificare il codice sorgente

Ora, si deve davvero risolvere questo bug.

Qui inizia il divertimento. Quando si cerca di risolvere un bug di un pacchetto, a volte questo è nei sorgenti originali e a volte è correlato al modo in cui il programma è stato pacchettizzato per Debian. Perciò a seconda di dove è il problema si devono modificare file diversi.

In questo caso particolare, il pacchetto usa lo strumento dpatch, uno strumento per gestire patch per il pacchetto, perciò verrà usato tale strumento. Altri pacchetti usano uno strumento diverso, chiamato quilt, per gestire le patch ma non verrà trattato in questo tutorial.

Per creare una nuova patch, è necessario fare quanto segue. Digitare:

   dpatch-edit-patch 80_bts585426_fix_help 70_bts537138_disambiguate_recurse.dpatch

Questo avvierà una nuova shell all'interno di un ambiente speciale, in cui si possono modificare i file e dpatch in seguito si occuperà di ottenere le differenze con l'originale.

Il nome della patch è stato scelto in modo da essere conforme al modello già stabilito dal manutentore.

Ora deve essere modificato il file fdupes.c. Andare alla riga 1066 e cancellarla. La riga dice:

  • printf(" \teach set of duplicates without prompting the user\n");

Ciò può essere fatto con il proprio editor preferito (vi fdupes.c, gedit fdupes.c, kate fdupes.c, ecc.).

Una volta fatto, si deve digitare

   exit

nella console; questo termina l'ambiente speciale che dpatch aveva creato e si ottiene una nuova patch nella directory debian/patches/. Controllare con:

   cat debian/patches/80_bts585426_fix_help.dpatch

Per poter applicare questa patch, è necessario modificare il file debian/patches/00list e aggiungere come ultima riga:

  • 80_bts585426_fix_help

Il file 00list è il file dpatch che elenca tutte le patch che verranno applicate; queste vengono applicate in ordine, da quella nella prima riga a quella nell'ultima.

Prima di ricostruire il pacchetto con questa patch, si deve rendere il proprio pacchetto diverso da quello originale, in modo che in seguito possano essere estratte le differenze così da poterle inviare come patch per il bug. Per fare questo, digitare:

   dch -n

Questo

Ora si sta quindi modificando il file changelog; quello che è necessario inserire in questo file è una qualche descrizione del cambiamento che è stato fatto. Per esempio:

  • Added a patch to fix the --help issue with the --debug option. Closes: #585426".

Farlo nella riga con il carattere * vuoto.

Compilare il pacchetto modificato

Una volta che ciò è stato fatto, si deve prima pulire la directory di compilazione, in modo che tutto sia come quando si è iniziato, usando:

   fakeroot debian/rules clean

e poi si può ricompilare il pacchetto di nuovo facendo la stessa cosa fatta prima:

   fakeroot debian/rules binary

Nel caso che sia necessario fare il debug del pacchetto compilato, specialmente se si sta cercando di risolvere un problema di Segmentation Fault, può essere utile compilarlo nel modo seguente, in modo che il codice non venga ottimizzato e non siano rimossi i simboli di debug così da rendere più facile il debug.:

   DEB_BUILD_OPTIONS=nostrip,noopt fakeroot debian/rules binary

Si vede a schermo dell'output della compilazione; di solito non è molto interessante, a meno che non si stia cercando un bug che è correlato alla compilazione stessa del pacchetto. Normalmente l'autrice lascia che proceda mentre va a fare qualcos'altro (ad esempio prendere qualche biscotto per il caffe).

Questa volta il pacchetto creato dovrebbe essere: ../fdupes_1.50-PR2-3.1_<mia arch>.deb, la versione è cambiata perché dch l'ha cambiata per conto dell'utente nel changelog (-3.1 invece di -3).

Installare e testare il pacchetto modificato

Installarlo con:

   sudo dpkg -i ../fdupes_1.50-PR2-3.1_<mia arch>.deb

e testarlo per vedere se l'aiuto adesso è corretto. :)

In ogni caso, se ciò che si è fatto ha peggiorato le cose si può sempre tornare alla versione Debian con:

  apt-get install --reinstall fdupes=<versione_precedente>

Creare il pacchetto sorgente

Una volta che un bug è stato risolto, si può volere anche creare il pacchetto sorgente. Ciò significa non solo il file .deb, ma anche gli altri file che sono stati scaricati all'inizio. Ciò viene fatto con:

   dpkg-buildpackage -us -uc

I parametri aggiuntivi servono ad evitare che il pacchetto venga firmato, dato che al momento non è necessario.

Se si è creato il pacchetto sorgente, si può andare nella directory precedente con cd .. e controllare che ci siano i file con ls. Si può vedere che ora ci sono più file, inclusi 2 file dsc, uno per il pacchetto originale e uno per quello appena creato.

Inviare i cambiamenti al BTS

Una volta che si è creato il pacchetto sorgente, si possono trovare le differenze tra il proprio pacchetto e quello originale usando debdiff:

   debdiff fdupes_1.50-PR2-3.dsc fdupes_1.50-PR2-3.1.dsc > mio_primo_debdiff.diff

In questo caso particolare, dato che è stato usato lo strumento dpatch, ciò che dovrebbe essere inviato al BTS come patch è il file dpatch che è stato creato, poiché i cambiamenti fatti sono contenuti lì.

Ma se non fosse stato usato dpatch, si potrebbe usare l'output di quel comando debdiff e inviarlo al BTS.

Conclusioni

Questo è tutto, prepararsi per il prossimo pacchetto

Ora che le modifiche a questo pacchetto sono terminate, si può continuare a risolvere bug in altri pacchetti Debian! Questi sono i comandi che è importante ricordare:

   apt-get source il-pacchetto
   apt-get build-dep il-pacchetto
   (...)
   fakeroot debian/rules binary
   dpkg -i il-pacchetto-blabla.deb
   dpkg-buildpackage -us -uc
   debdiff pacchetto-blabla.dsc pacchetto-blabla.1.dsc > un_altro_debdiff.diff

Feedback

L'autrice spera che questo tutorial sia stato gradito, inviarle un feedback se se ne ha voglia, o modificare questo Wiki se si desiderano aggiungere informazioni utili che possono essere state dimenticate.

Domande e risposte

DOMANDA: Il numero 80_ nel nome della patch è un fatto estetico?

RISPOSTA: È fatto in modo da poterle avere in ordine quando le si elenca con ls. L'ordine di applicazione è quello in cui appaiono nel file 00list. Alcuni manutentori scelgono di usare numeri per esse, altri no. Ma quando si crea una patch per un pacchetto si dovrebbe cercare di seguire qualsiasi schema sia stato scelto dal manutentore.

DOMANDA: A proposito dei parametri di dpatch-edit-patch, dove si prendono quei parametri? Sto parlando della roba bts****

RISPOSTA: Il primo è il nome della patch. È stato scelto un nome simile a quelle già esistenti. "bts" sta per "bug tracking system", il numero è quello del bug che si vuole chiudere.

DOMANDA: Come sceglie dch il numero "3.1"?

RISPOSTA: È stato usato dch -n, perché non era eseguito dal manutentore del pacchetto (n sta per non-manutentore). Poi c'è 3.1. Se si fosse stati manutentore, si sarebbe usato dch -i e il programma avrebbe scelto -4.

DOMANDA: Quando si invia una patch al BTS, si deve inviare qualcosa riguardo al changelog?

RISPOSTA: Non necessariamente, ma si può inviare anche quello; dipende dal bug che si sta risolvendo. È anche accettabile l'invio dell'output di debdiff.

Se si sta inviando solamente una patch piccola e semplice, è normale lasciare che sia il manutentore a scrivere il changelog; se invece si tratta di un grande aggiornamento NMU allora, sì, si dovrebbe inviare al BTS il changelog come parte della grande patch.

DOMANDA: Inviare un changelog con un NMU è considerato non educato?

RISPOSTA: Quello che ad alcuni (non a tutti) manutentori non piace è il fatto che qualcuno faccia veramente un NMU. L'invio di una patch al BTS è sempre/always/immer/siempre benvenuto!

DOMANDA: Qual è il modo più veloce/facile per scoprire quale strumento (se c'è) è usato per gestire le patch?

RISPOSTA: Se tra le dipendenze di compilazione è presente quilt o dpatch in debian/control. Oppure se c'è un file debian/README.source.

DOMANDA: Questo flusso di lavoro funziona per tutti i pacchetti?

RISPOSTA: È piuttosto generico. L'unica cosa che potrebbe cambiare è il sistema di gestione delle patch (dpatch/quilt/nessuno). Il resto è fondamentalmente sempre uguale.

Vedere anche