Guida per il nuovo Maintainer ----------------------------- Josip Rodin Traduzione: Francesco P. Lovergine versione 1.2.3, 18 January 2005. ------------------------------------------------------------------------------- Avviso di Copyright ------------------- Copyright (C) 1998-2002 Josip Rodin. Questa guida può essere utilizzata nei termini della GNU General Public License versione 2 o successive. Questo documento è stato realizzato utilizzando come modello i documenti seguenti: Making a Debian Package (noto come Manuale di Debmake), copyright (C) 1997 Jaldhar Vyas. The New-Maintainer's Debian Packaging Howto, copyright (C) 1997 Will Lowe. ------------------------------------------------------------------------------- Contenuti --------- 1. Partire "nel modo giusto" 1.1. Programmi necessari per lo sviluppo 1.2. Altre informazioni 2. Primi passi 2.1. Scegli il tuo programma 2.2. Prendi il programma e provalo 2.3. Nome del pacchetto e versione 2.4. La "debianizzazione" iniziale 3. Modificare i sorgenti 3.1. Installazione in una sotto-directory 3.2. Distinguere le librerie 4. Materiale richiesto sotto debian/ 4.1. Il file `control' 4.2. Il file `copyright' 4.3. Il file `changelog' 4.4. Il file `rules' 5. Altri file sotto debian/ 5.1. README.Debian 5.2. conffiles.ex 5.3. cron.d.ex 5.4. dirs 5.5. docs 5.6. emacsen-*.ex 5.7. init.d.ex 5.8. manpage.1.ex, manpage.sgml.ex 5.9. menu.ex 5.10. watch.ex 5.11. ex.package.doc-base 5.12. postinst.ex, preinst.ex, postrm.ex, prerm.ex 6. Costruzione del pacchetto 6.1. Costruzione completa 6.2. Ricostruzione veloce 6.3. Il comando `debuild' 6.4. Il sistema `dpatch' 6.5. Includere `orig.tar.gz' per il caricamento. 7. Controllare il pacchetto per errori 7.1. I pacchetti `lintian' 7.2. Il comando `mc' 7.3. Il comando `debdiff' 7.4. Il comando `interdiff' 7.5. Il comando `debi' 7.6. Il pacchetto `pbuilder' 8. Caricamento del pacchetto 8.1. Caricamento nell'archivio Debian 8.2. Caricamento in archivio privato 9. Aggiornamento del pacchetto 9.1. Nuova revisione Debian 9.2. Nuovo rilascio di upstream (base) 9.3. New upstream release (realistic) 9.4. Il file `orig.tar.gz' 9.5. Il comando `cvs-buildpackage' e similari 9.6. Verificare gli aggiornamenti di pacchetti 9.7. Dove chiedere aiuto A. Esempi A.1. Semplice esempio di pacchetto A.2. Pacchettizzare l'esempio con `dpatch' e `pbuilder' ------------------------------------------------------------------------------- 1. Partire "nel modo giusto" ---------------------------- Questo documento proverà a descrivere la costruzione di un pacchetto Debian GNU/Linux per un comune utente Debian (e aspirante sviluppatore), utilizzando un linguaggio immediato e con l'ausilio di esempi concreti. C'è un detto latino che dice _Longum iter est per preaecepta, breve et efficax per exempla!_ (La via è lunga usando la teoria, ma breve ed efficiente con gli esempi!). Una cosa che rende Debian una distribuzione Linux di prima scelta, è il suo sistema di pacchettizzazione. Sebbene ci sia una vasta quantità di software già in formato Debian, qualche volta è necessario installare del software che non lo è. Potresti chiederti come creare personalmente i tuoi pacchetti e forse pensare che sia un compito molto difficile. In effetti, se sei un novizio di Linux è dura, ma se sei un un utente stagionato non puoi non leggere questo documento subito :-) Avrai bisogno di conoscere dei rudimenti di programmazione Unix, ma certamente non occorrerà che tu sia un mago della programmazione. Una cosa è certa, però: per creare propriamente e manutenere pacchetti Debian ti occorrono ore-uomo di lavoro. Non commettere errori, per far funzionare il nostro sistema, i maintainer necessitano di essere insieme tecnicamente competenti e diligenti. Questo documento spiegherà ogni piccolo (e in apparenza irrilevante) passo, e ti aiuterà a creare il tuo primo pacchetto, e conseguire qualche esperienza nel costruire i successivi rilasci di questo e forse altri pacchetti più in là. Versioni aggiornate di questo documento dovrebbero sempre essere disponibili all'indirizzo http://www.debian.org/doc/maint-guide/ e nel pacchetto ``maint-guide''. La traduzione in italiano è anche disponibile nel pacchetto ``maint-guide-it''. 1.1. Programmi necessari per lo sviluppo ---------------------------------------- Prima di iniziare, dovresti assicurarti di avere correttamente installati alcuni pacchetti addizionali, necessari per lo sviluppo del software. Osserva che la lista non contiene alcun pacchetto etichettato `essential' o `required' - ci aspettiamo che tu li abbia già installati. Questa revisione del documento è stata aggiornata per i pacchetti in Debian 2.2 (`potato') e 3.0 (`woody'). I pacchetti seguenti fanno parte della installazione standard della Debian, per cui probabilmente li hai già installati (insieme ai pacchetti addizionali dai quali dipendono). Comunque dovresti controllare con `dpkg -s '. * `dpkg-dev' - questo pacchetto contiene gli strumenti necessari per spacchettare, creare e caricare i pacchetti sorgenti Debian. (vedi dpkg-source(1)) * `file' - questo comodo programma può stabilire la tipologia di un file. (vedi file(1)) * `gcc' - il compilatore GNU C, necessario se il tuo programma come molti altri è scritto nel linguaggio di programmazione C. (vedi gcc(1), Questo pacchetto caricherà anche un gruppo di altri pacchetti come `binutils' che include programmi usati per assemblare e linkare file oggetto (vedi `info binutils` nel pacchetto `binutils-doc') e `cpp', il preprocessore C. (vedi cpp(1)) * `g++' - il compilatore GNU C++, necessario se il tuo programma è scritto in C++. (vedi g++(1)). * `libc6-dev' - le librerie e i file header che il gcc richiede per la compilazione e il link dei file oggetto. (vedi `info libc' nel pacchetto `glibc-doc') * `make' - generalmente la creazione di programmi richiede una serie di passi. Piuttosto di riscrivere continuamente gli stessi comandi, puoi utilizzare questo programma per automatizzare il processo, creando dei `Makefile'. (vedi `info make`) * `patch' - questo programma di utilità molto utile impiega un file contenente una lista di differenze (prodotta dal programma diff) e la applica al file originale, per produrre una versione modificata. (vedi patch(1)) * `perl' - Perl è uno dei linguaggi per script interpretati più utilizzati sui moderni sistemi simil-Unix, spesso definito come "il coltellino svizzero di Unix". (vedi perl(1)) Probabilmente vorrai installare i pacchetti seguenti, anche: * `autoconf' e `automake' - molti programmi nuovi usano script di configurazione e Makefile preprocessati con l'aiuto di programmi come questi. (vedi `info autoconf`, `info automake`) * `dh-make' e `debhelper'- dh-make è necessario per creare lo skeleton del nostro pacchetto di esempio, e utilizzerà alcuni strumenti di debhelper per creare i pacchetti. Non sono essenziali per la creazione di pacchetti, ma sono _altamente_ raccomandati per i nuovi maintainer. Questo rende l'intero processo molto più semplice da iniziare e controllare successivamente. (vedi dh_make(1), debhelper(1), /usr/share/doc/debhelper/README) * `devscripts' - questo pacchetto contiene alcuni utili script che possono essere di aiuto per il maintainer, ma anche questi non sono strettamente necessari per la creazione di pacchetti. (vedi /usr/share/doc/devscripts/README.gz) * `fakeroot' - questa programma di utilità permette di emulare i privilegi di root necessari per alcune parti del processo di creazione. (vedi fakeroot(1)) * `gnupg' - un programma che ti consente di _firmare_ elettronicamente i pacchetti. Questo è soprattutto importante se vuoi distribuirli ad altre persone, e certamente lo farai quando il tuo lavoro verrà incluso nella distribuzione Debian. (vedi gpg(1)) * `g77' - il compilatore GNU Fortran 77, necessario se il tuo programma è scritto in Fortran. (vedi g77(1)) * `gpc' - il compilatore GNU Pascal, necessario se il tuo programma è scritto in Pascal. Degno di nota qui è `fp-compiler', il Compilatore Free Pascal, che è anche adatto a questo compito. (vedi gpc(1), ppc386(1)) * `xutils' - alcuni programmi, generalmente quelli fatti per X11, usano anche questi programmi per generare i Makefile da insiemi di macro funzioni. (vedi imake(1), xmkmf(1)) * `lintian' - questo è il verificatore dei pacchetti Debian, che permette di scoprire errori comuni dopo la costruzione del pacchetto e spiega gli errori trovati. (vedi lintian(1), /usr/share/doc/lintian/lintian.html/index.html) * `pbuilder' - questo pacchetto contiene programmi che sono usati per creare e mantenere un ambiente chroot. Creare pacchetti in tale ambiente chroot permette di verificare le appropiate dipendenze ed evitare i bug FTBS. (vedi pbuilder(8) e pdebuild(1)) Quanto segue è la documentazione _molto importante_ che dovresti leggere insieme a questo documento: * `debian-policy' - la Policy include la struttura e i contenuti dell'archivio, una serie di indicazioni sul disegno del sistema operativo, lo Standard della Gerarchia del Filesystem (che dice dove ogni file e directory dovrebbe stare), ecc. La cosa che per te è più importante è che descrive gli obblighi che ogni pacchetto deve soddisfare per essere incluso nella distribuzione. (vedi /usr/share/doc/debian-policy/policy.html/index.html) * `developers-reference' - contiene tutto il materiale non specificatamente relativo ai dettagli tecnici della pacchettizzazione, come la struttura dell'archivio, come rinominare, rendere orfano o prendere in carico un pacchetto, come fare gli NMU, come gestire i bug, suggerimenti pratici di pacchettizzazione,quando e dove fare i caricamenti, ecc. (vedi /usr/share/doc/developers-reference/index.en.html) Le brevi note date sino a questo punto servono solo come introduzione a cosa ciascun pacchetto fa. Prima di continuare, leggi approfonditamente la documentazione di ogni programma, almeno per un uso standard. Potrà sembrarti molto pesante farlo adesso, ma più avanti sarai _lietissimo_ di averlo fatto. Nota: `debmake' è un pacchetto che contiene alcuni programmi con funzioni simile a dh-make, ma il suo specifico uso _non_ è illustrato in questo documento, perchè il suo uso è _sconsigliato_. Si rimanda al manuale di Debmake (http://www.debian.org/~jaldhar/) per maggiori informazioni. 1.2. Altre informazioni ----------------------- Ci sono due tipi di pacchetti che puoi creare, sorgente e binario. Un pacchetto sorgente contiene codice che puoi compilare in un programma. Un pacchetto binario contiene il solo programma finito. Non confondere il sorgente di un programma con i sorgenti del pacchetto del programma! Leggi gli altri manuali se hai necessità di avere maggiori dettagli sulla terminologia. In Debian, il termine `maintainer' è utilizzato per la persona che crea pacchetti, `upstream author' per chi ha realizzato il programma, e `upstream maintainer' per la persona che correntemente manutiene quel programma, al di fuori di Debian. Generalmente author e upstream maintainer sono la stessa persona - e talvolta anche il maintainer è la stessa persona. Se hai realizzato un programma, e vuoi che faccia parte di Debian, sentiti libero di sottomettere la richiesta per diventare un maintainer. Una volta creato il pacchetto (o mentre lo fai), dovrai diventare un maintainer Debian ufficiale, se vuoi che il tuo programma vada a far parte della prossima distribuzione (se il programma è utile perché no?). La procedura è spiegata nella Guida di Riferimento per lo Sviluppatore. Sei pregato di leggerla. ------------------------------------------------------------------------------- 2. Primi passi -------------- 2.1. Scegli il tuo programma ---------------------------- Devi probabilmente scegliere il pacchetto che vuoi creare. La prima cosa da fare è controllare se il pacchetto è già nella distribuzione. Se usi la distribuzione `stabile', forse è meglio che tu vada all'indirizzo pagina di ricerca dei pacchetti (http://www.debian.org/distrib/packages). Se usi la _corrente_ distribuzione `instabile', verificalo con i comandi: dpkg -s program dpkg -l '*program*' Se il pacchetto già esiste, bene, installalo! :-) Se fosse stato reso orfano -- se il suo maintainer è configurato come "Debian QA Group", dovresti essere in grado di prenderlo in carico. Consulta lista dei pacchetti orfani (http://www.debian.org/devel/wnpp/orphaned) e la lista dei pacchetti in adozione (http://www.debian.org/devel/wnpp/rfa_bypackage) per verificare che il pacchetto sia effettivamente disponibile. Se sei in grado di adottare il pacchetto, prendi i sorgenti (con qualcosa come `apt-get source packagename') ed esaminali. Questo documento purtroppo non include informazioni esaustive sulla adozione di pacchetti. Fortunatamente non dovrai fare un duro lavoro per capire come il pacchetto funziona poichè qualcuno avrà già fatto la configurazione iniziale al posto tuo. Continua a leggere comunque, molti dei suggerimenti nel seguito saranno ancora applicabili nel tuo caso. Se il pacchetto è nuovo, e decidi che ti piacerebbe facesse parte di Debian, procedi come segue: * consulta la la lista dei pacchetti sui quali si lavora (http://www.debian.org/devel/wnpp/being_packaged) per vedere se qualcun altro sta lavorando sullo stesso pacchetto. Se così fosse, contatta il maintainer corrente se pensi che occorra. Altrimenti - trova un altro programma interessante che nessuno ha in mantenimento. * il programma _deve_ avere una licenza, se possibile free, in accordo con le Linee Guida per il Software Libero Debian (http://www.debian.org/social_contract.html#guidelines). Se non è conforme a qualcuna di tali regole, ma può comunque essere distribuito, può ancora essere incluso nelle sezioni `contrib' o `non-free'.. Se non sei sicuro di dove debba essere incluso chiedi un suggerimento su . * il programma in questione certamente _non_ dovrebbe girare come setuid root, o anche meglio, non dovrebbe richiedere di essere setuid o setgid a nessun utente. * il programma non dovrebbe essere un daemon, o qualcosa che debba essere installato nelle directory */sbin, o aprire una porta come root. * il programma dovrebbe essere in forma di binario eseguibile, le librerie sono più difficili da gestire. * dovrebbe essere ben documentato, o almeno comprensibile (cioè non confuso). * dovresti contattare l'autore o gli autori del programma per controllare che siano d'accordo con la sua pacchettizzazione. È importante essere in grado di consultarsi con l'autore/i sul programma nel caso di problemi specifici del programma, per cui non provare a pacchettizzare prodotti software non in manutenzione. * infine, cosa non meno importante, dovresti essere sicuro che il programma funziona e averlo provato per un po'. Ovviamente queste cose sono solo misure di sicurezza, intese per salvarti dall'ira degli utenti se fai qualcosa di sbagliato in qualche daemon setuid... Una volta acquisita qualche esperienza nella pacchettizzazione, sarai anche in grado di creare quel tipo di pacchetti, ma anche lo sviluppatore più esperto consulta la mailing list debian-devel quando ha qualche dubbio. E i partecipanti saranno lieti di darti una mano. Per maggiori informazioni su queste cose, consulta la Guida di Riferimento per lo Sviluppatore. 2.2. Prendi il programma e provalo ---------------------------------- La prima cosa da fare è trovare e scaricare il pacchetto originale. Sto supponendo che tu abbia già i file dei sorgenti recuperati dalla homepage dell'autore. I sorgenti per programmi free Linux sono generalmente in formato tar/gzip, con estensione .tar.gz, contengono una subdirectory dal nome programma-versione e tutti i sorgenti sotto di essa. Se il sorgente è in qualche altro formato di archiviazione (per esempio, il nome del file finisce in ".Z" o ".zip") scompattalo con i programmi appropriati, o chiedi a un esperto Debian se non sei sicuro su come scompattarlo correttamente (suggerimento: usa il comando `file archivio.estensione'). A titolo di esempio, utilizzerò un programma dal nome `gentoo', un file manager per X basato su GTK+. Osserva che il programma in questione è già pacchettizzato ed ha subito sostanziali modifiche dal momento in cui questo testo è stato inizialmente scritto. Crea una sottodirectory nella tua home dal nome `debian' o `deb' o un altro nome che ritieni appropriato (per es. anche `~/gentoo/' sarebbe adatto in questo caso). Sposta l'archivio scaricato in essa e scompattalo (con `tar xzf gentoo-0.9.12.tar.gz'). Assicurati che non ci siano errori, anche qualcuno "irrilevante," perché potrebbe probabilmente dare problemi di spacchettamento sul sistema di altri, i cui programmi di scompattazione potrebbero o meno ignorare tali anomalie. A questo punto hai un'altra sottodirectory, dal nome `gentoo-0.9.12'. Spostati sotto tale directory e leggi _approfonditamente_ la documentazione fornita. Generalmente ci sono file come README*, INSTALL*, *.lsm o *.html. Devi trovare le istruzioni su come compilare correttamente e installare il programma (molto probabilmente, si assume che tu voglia installare sotto /usr/local/bin; non lo farai, ma trovi altro su questo argomento più in là in Sezione 3.1, `Installazione in una sotto-directory'). La procedura cambia da programma a programma, ma molti dei programmi più recenti hanno uno script `configure' che configura i sorgenti sotto il tuo sistema e ti assicura che il sistema sia nella condizioni di compilarli. Dopo la configurazione (con il comando `./configure'), i programmi sono generalmente compilati con `make'. Alcuni supportano il comando `make check' per lanciare dei controlli automatici inclusi. L'installazione nelle directory destinazione viene generalmente fatta con `make install'. Adesso prova a compilare ed eseguire il programma, per essere sicuro che lavori correttamente e niente sia andato male durante l'installazione o l'esecuzione. Puoi anche lanciare generalmente `make clean' per rimuovere i file installati (o meglio ancora `make distclean') per ripulire la directory di compilazione. Talvolta c'e' anche un `make uninstall` che può essere usato per rimuovere tutti i file installati. 2.3. Nome del pacchetto e versione ---------------------------------- Dovresti iniziare la pacchettizzazione con una directory di sorgenti completamente ripulita, o semplicemente partendo da una nuova scompattazione dei sorgenti. Per costruire correttamente il pacchetto, dovresti modificare il nome del programma originale in minuscolo (se già non lo fosse), e rinominare la directory in -. Se il nome del programma consiste di più di una parola, contrailo in una sola parola, o fanne una abbreviazione. Per esempio, il pacchetto del programma "John's little editor for X" potrebbe essere chiamato johnledx o jle4x, o qualsiasi altra cosa tu decida in modo da stare sotto un numero ragionevole di caratteri, per esempio 20. Controlla anche l'esatta versione del programma (che deve essere inclusa nella versione del pacchetto). Se il programma non è numerato con versioni quali X.Y.Z, ma con qualche tipo di data, sei libero di utilizzare tale data come numero di versione, con un prefisso "0.0." (giusto nel caso in cui un upstream, un giorno, decida di rilasciare una versione più comoda come "1.0"). Così se la data di rilascio fosse il 19 Dicembre 1998, potresti usare la stringa di versione 0.0.19981219. Alcuni programmi non hanno affatto una numerazione, nel qual caso dovresti contattare l'upstream maintainer, per vedere se viene usato qualche altro metodo di revisione. 2.4. La "debianizzazione" iniziale ---------------------------------- Assicurati di trovarti nella directory dei sorgenti del programma e lancia il comando seguente: dh_make -e tuo.maintainer@indirizzo -f ../gentoo-0.9.12.tar.gz Ovviamente, sostituisci alla stringa "tuo.maintainer@indirizzo" il tuo indirizzo e-mail da includere come voce del changelog e in altri file, e al nome del file il nome originale dell'archivio dei sorgenti. Vedi dh_make(1) per dettagli. Verranno visualizzate alcune informazioni. Ti verrà chiesto che genere di pacchetto vuoi creare. Gentoo è un singolo pacchetto binario - crea un solo binario, e perciò un solo file .deb - per cui selezionerai la prima opzione con il tasto `s', e controllerai le informazioni sullo schermo, confermando la scelta con . Dopo questa esecuzione di `dh_make', una copia del tarball dell'upstream viene creato col nome `gentoo_0.9.12.orig.tar.gz' nella directory superiore per consentire la creazione di un pacchetto Debian sorgente non nativo con il `diff.gz'. Nota due caratteristiche chiave in questo nome di file: * Nome del pacchetto e versione sono separate da "`_'" . * È presente "`orig.'" prima del "`tar.gz'" . Ancora una volta, come nuovo maintainer non sei incoraggiato a creare pacchetti complessi, per esempio: * pacchetti binari multipli, * pacchetti di libreria, * pacchetti i cui sorgenti non sono in formato `tar.gz.' o `tar.bz2', oppure * il tarball sorgente ha contenuti non distribuibili. Non è difficile, ma richiede un po' più di conoscenze, per cui non ne parleremo in questo documento. Osserva che dovresti lanciare `dh_make' _una sola volta_, perché non avrebbe un comportamento corretto se lo eseguissi nuovamente nella stessa directory già "debianizzata". Questo significa anche che userai un metodo diverso per rilasciare una nuova revisione o una nuova versione del tuo pacchetto, in futuro. Leggi altro in merito più oltre in Capitolo 9, `Aggiornamento del pacchetto' ------------------------------------------------------------------------------- 3. Modificare i sorgenti ------------------------ Normalmente, i programmi si auto-installano in sottodirectory di /usr/local I pacchetti Debian invece non usano quella directory, dal momento che è riservata agli amministratori (o utenti) del sistema per uso privato. Questo significa che dovrai dare una occhiata al sistema di compilazione del programma, partendo generalmente dal Makefile. Questo script sarà utilizzato da make(1) per creare automaticamente il programma. Per maggiori dettagli sui Makefile dai una occhiata a Sezione 4.4, `Il file `rules''. Osserva che se il tuo programma utilizza l'utilità GNU automake(1) e/o autoconf(1), questo significa che i sorgenti includono un Makefile.am e/o Makefile.in rispettivamente, e avrai bisogno di modificare questi ultimi file, poiché ogni esecuzione di automake provoca la riscrittura di Makefile.in con informazioni generate a partire dal suo file Makefile.am, e ogni esecuzione di ./configure farà lo stesso con il corrispondente Makefile, con i dati ricavati dal file Makefile.in. Modificare i file Makefile.am richiede qualche conoscenza di automake - del quale puoi leggere la relativa documentazione in formato info - mentre modificare Makefile.in è molto simile a modificare i Makefile, in più ponendo attenzione alle variabili, ovvero qualsiasi stringa di caratteri compresa fra `@', come ad esempio @CFLAGS@ or @LN_S@, che viene sostituita con l'effettivo valore ad ogni invocazione di ./configure. Assicurati di leggere `/usr/share/doc/autotools-dev/README.Debian.gz' prima di procedere. Nota anche che in questo documento, non c'è spazio sufficiente per entrare in tutti i dettagli di come fare le modifiche, ma di seguito ecco alcuni problemi che spesso si incontrano. 3.1. Installazione in una sotto-directory ----------------------------------------- La maggior parte dei programmi ha una qualche maniera di installarsi in una struttura di directory pre-esistente del tuo sistema, in modo che i binari vengano inclusi nel $PATH, e si possano trovare le pagine di manuale e i programmi in locazioni comuni. Tuttavia, se facessi questo, il programma sarebbe installato tra ogni altra cosa già presente sul tuo sistema. Questo renderebbe difficile per i programmi di pacchettizzazione capire quali file appartengono al tuo pacchetto e quali no. Perciò dovrai fare qualcosa di diverso: installa il programma in una sotto-directory temporanea dalla quale gli strumenti di manutenzione costruiranno un pacchetto .deb operativo. Ogni file contenuto in tale directory sarà installato sul sistema dell'utente, quando questi installa il tuo pacchetto, la sola differenza è che dpkg installerà i file a partire dalla radice. Questa directory temporanea è generalmente creata sotto la tua directory debian/ nell'albero dei sorgenti spacchettato. Si chiama generalmente `debian/nomepacchetto'. Tieni a mente che anche se avrai bisogno che il programma venga installato in debian/nomepacchetto, deve funzionare correttamente quando piazzato nella radice, cioè quando viene installato a partire dal pacchetto .deb. Così, non dovrai consentire che il sistema di compilazione inserisca stringhe come `/home/me/deb/gentoo-0.9.12/usr/share/gentoo' nei file del pacchetto. Con programmi che usano GNU autoconf, questo è piuttosto semplice, La maggior parte di questi programmi hanno makefile che sono creati per default per consentire installazioni in directory casuali, sebbene mantengano /usr (ad esempio) come prefisso canonico. Quando si accorgerà che il programma usa autoconf, dh_make fornirà i comandi per fare tutto questo automaticamente, per cui potresti saltare la lettura di questa sezione. Invece con altri programmi, dovrai probabilmente esaminare e modificare i Makefile. Questa è la parte rilevante del Makefile di gentoo: # Where to put binary on 'make install'? BIN = /usr/local/bin # Where to put icons on 'make install'? ICONS = /usr/local/share/gentoo/ Osserva che il file sono configurati per installare sotto `/usr/local'. Modifica questi percorsi in: # Where to put binary on 'make install'? BIN = $(DESTDIR)/usr/bin # Where to put icons on 'make install'? ICONS = $(DESTDIR)/usr/share/gentoo Ma perchè in quella directory, e non altrove? Perchè i pacchetti Debian non installano mai file sotto `/usr/local' -- quella gerarchia è riservata all'uso dell'amministratore di sistema. Tali file in sistemi Debian vanno invece posti sotto `/usr'. Le locazioni più corrette per binari, icone, documentazione ecc. sono specificate nello Standard per la Gerarchia del Filesystem (vedi /usr/share/doc/debian-policy/fhs/). Ti raccomando di visionarlo e leggere le sezioni che possono riguardare il tuo pacchetto. Così, dobbiamo installare i binari in /usr/bin invece di /usr/local/bin, la pagina di manuale in /usr/share/man/man1 invece di /usr/local/man/man1, ecc. Nota come non ci sia una pagina di manuale menzionata nel makefile di gentoo, ma dal momento che la Policy Debian richiede che ogni programma ne abbia una, ne faremo una più in là e la installeremo in /usr/share/man/man1. Ma perché in quella directory e non in qualche altra? Perchè Debian ha definito alcune regole su dove i programmi devono essere installati. Questo è specificato nello Standard della Gerarchia del Filesystem (vedi /usr/share/doc/debian-policy/fhs/). Così dovremmo installare il binario in /usr/X11R6/bin invece che in /usr/local/bin e le pagine di manuale (non esistono in questo caso, ma quasi ogni programma ne ha una, per cui ne faremo una dopo) in /usr/share/man/man1 invece che in /usr/local/man/man1. Alcuni programmi non usano variabili di makefile per definire percorsi come questi. Questo significa che potrai dover editare alcuni sorgenti C allo scopo di correggerli per usare le locazioni giuste. Ma dove e come cercarle? Puoi trovarle eseguendo: grep -nr -e 'usr/local/lib' --include='*.[c|h]' . Grep eseguirà ricorsivamente sull'albero dei sorgenti e ti dirà il nome di un file e la riga in esso quando trova una occorrenza. Edita questi file e in quelle righe sostituisci /usr/local/* con usr/* -- e questo e tutto. Fa attenzione a non sconvolgere il resto del codice! :-) Dopo di questo, dovresti trovare il target install (cerca la riga che inizia con `install:') e rinomina tutti i riferimenti a directory diverse da quelle definite all'inizio del Makefile. In precedenza, il target install di gentoo diceva: install: gentoo install ./gentoo $(BIN) install icons $(ICONS) install gentoorc-example $(HOME)/.gentoorc Dopo la modifica invece: install: gentoo-target install -d $(BIN) $(ICONS) $(DESTDIR)/etc install ./gentoo $(BIN) install -m644 icons/* $(ICONS) install -m644 gentoorc-example $(DESTDIR)/etc/gentoorc Avrai sicuramente notato che c'è adesso un comando `install -d' prima degli altri nella regola. Il makefile originale non ce l'ha perchè generalmente /usr/local/bin e le altre directory già esistono sul sistema su cui si lancia `make install`. Tuttavia, dal momento che installeremo nella nostra directory vuota (o anche inesistente), dovremo creare ogni singola directory. Possiamo anche aggiungere altre cose alla fine della regola, come l'installazione di documentazione che l'autore upstream talvolta omette: install -d $(DESTDIR)/usr/share/doc/gentoo/html cp -a docs/* $(DESTDIR)/usr/share/doc/gentoo/html Se sei un lettore attento, avrai notato che ho modificato `gentoo' in `gentoo-target' nella riga `install:'. Questo è quello che si definisce un bug fix :-) Qualora effettuassi delle modifiche che non sono specificatamente legate alla pacchettizzazione Debian, assicurati di inviarle all'upstream maintainer, in modo che possa includerle nella prossima revisione del programma e possano essere utili ad ogni altro. Ricorda anche di rendere i tuoi fix non specifici per Debian o Linux (o anche Unix!) prima di inviarli -- rendili portabili. Questo renderà la tua correzione molto più semplice da applicare. 3.2. Distinguere le librerie ---------------------------- C'è un altro problema comune: le librerie sono spesso diverse da piattaforma a piattaforma. Per esempio, il Makefile può contenere un riferimento a una libreria che non esiste in sistemi Debian. In tal caso occorre modificarlo in una libreria che esiste in Debian, e serva allo stesso scopo. Così, se c'è una riga nel Makefile del programma (o nel Makefile.in) che dice qualcosa del tipo (e il programma non compila): LIBS = -lcurses -lsomething -lsomethingelse Modificala come segue, e molto probabilmente funzionerà: LIBS = -lncurses -lsomething -lsomethingelse #LIBS = -lcurses -lsomething -lsomethingelse (L'autore si rende conto che questo non è il migliore esempio considerato che il nostro pacchetto libncurses adesso è distribuito con un link simbolico libcurses.so, ma non gliene veniva uno migliore. Suggerimenti sono benvenuti :-) ------------------------------------------------------------------------------- 4. Materiale richiesto sotto debian/ ------------------------------------ C'è adesso una nuova sotto-directory nella directory principale del programma (`gentoo-0.9.12'), il cui nome è `debian'. Ci sono un certo numero di file in questa directory che dovremo modificare allo scopo di adattare il comportamento del pacchetto. I più importati fra loro sono `control', `changelog', `copyright' e 'rules', che sono richiesti per tutti i pacchetti. 4.1. Il file `control' ---------------------- Questo file contiene vari valori che `dpkg', `dselect' e altri pacchetti useranno per la gestione del pacchetto. Questo è il file control che dh_make crea per noi. 1 Source: gentoo 2 Section: unknown 3 Priority: optional 4 Maintainer: Josip Rodin 5 Build-Depends: debhelper (>> 3.0.0) 6 Standards-Version: 3.5.2 7 8 Package: gentoo 9 Architecture: any 10 Depends: ${shlibs:Depends} 11 Description: 12 (I numeri di riga sono aggiunti). Le righe 1-6 sono le informazioni di controllo per il pacchetto sorgente. La riga 1 è il nome del pacchetto sorgente. La riga 2 è la sezione della distribuzione in cui il pacchetto è incluso. Come ti sarai reso conto, Debian è diviso in sezioni: main (il software free), non-free (il software non esattamente free) e contrib (software free che dipende da software non free). Al di sotto di queste ci sono delle sotto-sezioni logiche che descrivono in breve di che genere di pacchetto si tratta. Così abbiamo `admin' per programmi da amministratore, `base' per gli strumenti di base, `devel' per gli strumenti per programmatori, `doc' per la documentazione, `libs' per le librerie, `mail' per programmi e demoni di posta elettronica, `net' per applicazioni e demoni di rete, `x11' per programmi specifici per X11, e molte altre. Modifichiamo quindi la sezione in x11. (Un prefisso "main/" è implicito per cui lo omettiamo.) La riga 3 descrive quanto sia importante che l'utente installi tale pacchetto. Leggi il manuale della Policy per una guida su come configurare questi campi. La priorità "optional" generalmente funzionerà per nuovi pacchetti. Sezioni e priorità sono usati effettivamente solo da `dselect' dselect quando ordina i pacchetti e seleziona i default. Una volta caricato il pacchetto in Debian, il valore di questi due campi possono essere modificati dai maintainer dell'archivio FTP, nel qual caso ne sarai informato via email. Dal momento che si tratta di un pacchetto a priorità normale, lasciamo il campo al valore "optional". La riga 4 è nome e e-mail del maintainer. Assicurati che questo campo contenga un campo "To: " valido per una email, perché dopo averlo caricato il sistema di tracciamento delle anomalie lo userà per inviarti le email relativi a errori. Evita l'uso di virgole, '&' e parentesi. La quinta riga include la lista dei pacchetti richiesti per creare il tuo pacchetto. Alcuni pacchetti come gcc e make sono impliciti, vedi il pacchetto `build-essential' per dettagli. Se qualche compilatore non standard o altri strumenti sono necessari per compilare il tuo pacchetto, dovresti aggiungerlo alla riga `Build-Depends'. Valori multipli sono separati con virgole; leggi più avanti la spiegazione delle dipendenze binarie per saperne di più della sintassi di questo campo. Qui puoi anche avere Build-Depends-Indep, Build-Conflicts e altri campi. Questi dati saranno usati dal software di costruzione automatica dei pacchetti per creare pacchetti binari per altre piattaforme di computer. Vedi il manuale della Policy per altre informazioni sulle build-dependencies e la Guida di Riferimento dello Sviluppatore per informazioni su tali piattaforme (architetture) e come portare il software su di esse. Ecco un trucco che puoi usare per trovare quali pacchetti il tuo pacchetto richiede per la creazione: strace -f -o /tmp/log ./configure # o make invece di ./configure, se il pacchetto non usa autoconf for x in `dpkg -S $(grep open /tmp/log|\ perl -pe 's!.* open\(\"([^\"]*).*!$1!' |\ grep "^/"| sort | uniq|\ grep -v "^\(/tmp\|/dev\|/proc\)" ) 2>/dev/null|\ cut -f1 -d":"| sort | uniq`; \ do \ echo -n "$x (>=" `dpkg -s $x|grep ^Version|cut -f2 -d":"` "), "; \ done Per trovare manualmente le esatte dipendenze per la compilazione di `', esegui objdump -p | grep NEEDED e per ogni libreria elencata, per es. `libfoo.so.6', esegui dpkg -S libfoo.so.6 A questo punto usa la versione -dev di ogni pacchetto come valore di `Build-deps'. Se usi `ldd' a questo scopo, ti verranno indicate anche tutte le librerie di dipendenza indiretta, col problema di un numero eccessivo di dipendenze per la compilazione. Gentoo sembra richiedere `xlibs-dev', `libgtk1.2-dev' e `libglib1.2-dev' per compilare, per cui li aggiungiamo dopo `debhelper'. La riga 6 è la versione degli standard di Debian Policy che questo pacchetto segue, la versione del manuale di Policy che leggi mentre costruisci i pacchetti. La riga 8 è il nome del pacchetto binario. Questo è generalmente lo stesso nome del sorgente, ma non deve necessariamente essere così. La riga 9 descrive l'architettura di CPU per la quale il pacchetto binario è stato compilato. Possiamo lasciare il valore "any" perché dpkg-gencontrol(1) lo riempirà con il valore appropriato per qualsiasi macchina sulla quale questo pacchetto è stato compilato. Se il tuo pacchetto è indipendente dalla architettura (per esempio, uno script di shell o Perl, o un documento) modifica questo campo in "all", e leggi oltre in Sezione 4.4, `Il file `rules'' sull'uso del metodo `binary-indep' invece di `binary-arch' per costruire un pacchetto. La riga 10 mostra una della più potenti caratteristiche del sistema di pacchettizzazione Debian. I pacchetti possono far riferimento l'uno all'altro in vari modi. Oltre a Depends:, altri campi di relazione sono Recommends:, Suggests:, Pre-Depends:, Conflicts:, Provides:, e Replaces:. Gli strumenti di gestione dei pacchetti generalmente si comportano nello stesso modo quando trattano queste relazioni; se così non è, viene spiegato. (vedi dpkg(8), dselect(8), apt(8), aptitude(1) ecc.) Questo è ciò che le dipendenze significano: * Depends: Il pacchetto non sarà installato sino a quando i pacchetti da cui dipende non lo sono. Usa questo valore se il tuo programma non funziona affatto (o causa un serio malfunzionamento) quando un pacchetto particolare non è già presente. * Recommends: Alcuni frontend come dselect o aptitude ti chiederanno di installare i pacchetti raccomandati, insieme al tuo pacchetto; dselect insisterà nel volerlo fare. Dpkg e apt-get invece, ingnorano questo campo. Usa questo valore per pacchetti che non sono strettamente necessari, ma tipicamente usati con il tuo programma. * Suggests: Quando un utente installa il tuo programma, tutti i frontend chiedono verosimilmente se devono installare i pacchetti suggeriti. Dpkg e apt-get non se ne curano Usa questo valore per pacchetti che lavorano insieme al tuo programma, ma non sono affatto necessari. * Pre-Depends: Questo è più stringente di Depends:. Il pacchetto non sarà installato a meno che i pacchetti da cui pre-dipende non siano installati e _correttamente configurati_. Usa questo valore con _molta_ prudenza, e solo dopo averne discusso nella mailing list debian-devel. Leggi: non usarlo affatto. :-) * Conflicts: Il pacchetto non sarà installato sino a quando tutti i pacchetti con i quali va in conflitto non saranno stati rimossi. Usa questo valore se il tuo programma assolutamente non può girare (o causa un serio danno) se un particolare pacchetto è presente. * Provides: Per alcuni tipi di pacchetti dove ci sono alternative multiple sono stati definiti dei nomi virtuali. Puoi trovarne una lista completa nel file /usr/share/doc/debian-policy/virtual-package-names-list.text.gz. Usa questo valore se il tuo programma fornisce una funzione di un pacchetto virtuale esistente . * Replaces: Usa questo valore quando il tuo programma sostituisce i file di un altro pacchetto o sostituisce completamente un altro pacchetto (usato congiuntamente a Conflicts:). I file dei suddetti pacchetti saranno sostituiti con i file del tuo pacchetto. Tutti questi campi hanno una sintassi uniforme. Sono una lista di nomi di pacchetti separati da virgole. Questi nomi di pacchetti possono anche essere liste di nomi di pacchetti alternativi, separati da una barra verticale `|' (simbolo di pipe). Questi campi possono restringere la propria applicabilità a una particolare versione di ciascun pacchetto. Tali versioni sono elencate in parentesi dopo ogni nome di pacchetto, e dovrebbero contenere una relazione fra le possibili qui in elenco, seguita da un numero di versione. Le relazioni consentite sono: `<<', `<=', `=', `>=' e `>>' che stanno per strettamente precedente, precedente o uguale, esattamente uguale, successiva o uguale, e strettamente successiva, rispettivamente. Per esempio, Depends: foo (>= 1.2), libbar1 (= 1.3.4) Conflicts: baz Recommends: libbaz4 (>> 4.0.7) Suggests: quux Replaces: quux (<< 5), quux-foo (<= 7.6) L'ultima caratteristica che hai necessità di conoscere è $(shlibs:Depends). Dopo che il tuo pacchetto sarà stato generato e installato nella directory temporanea, dh_shlibdeps(1) lo esaminerà alla ricerca di binari e librerie, determinerà le dipendenze da librerie condivise e stabilirà in quali pacchetti queste si trovano, come libc6 o xlib6g. Questo programma passerà la lista a dh_gencontrol(1) che li metterà al posto giusto, e tu non dovrai preoccuparti di specificarle da solo. Detto ciò possiamo lasciare la riga Depends: come è ora, e inserire un'altra riga dopo questa che dice `Suggests: file', perchè gentoo può usare alcune funzionalità offerte da quel programma/pachetto. La riga 12 è una breve descrizione. Gli schermi di molte persone sono larghi 80 colonne, per cui non dovrebbe essere di più di 60 caratteri. Modificherai tale campo in "fully GUI configurable X file manager using GTK+". La riga 13 contiene una descrizione estesa. Dovrebbe essere un paragrafo dove vengono dati più dettagli sul pacchetto. La colonna 1 di ogni riga dovrebbe essere vuota. Non ci devono essere righe vuote in mezzo, ma puoi mettere un . (punto) in una colonna, per simularle. Inoltre, non ci deve essere più di una riga vuota dopo la descrizione. Questo è il file control aggiornato: 1 Source: gentoo 2 Section: x11 3 Priority: optional 4 Maintainer: Josip Rodin 5 Build-Depends: debhelper (>> 3.0.0), xlibs-dev, libgtk1.2-dev, libglib1.2-dev 6 Standards-Version: 3.5.2 7 8 Package: gentoo 9 Architecture: any 10 Depends: ${shlibs:Depends} 11 Suggests: file 12 Description: fully GUI configurable GTK+ file manager 13 gentoo is a file manager for Linux written from scratch in pure C. It 14 uses the GTK+ toolkit for all of its interface needs. gentoo provides 15 100% GUI configurability; no need to edit config files by hand and re- 16 start the program. gentoo supports identifying the type of various 17 files (using extension, regular expressions, or the 'file' command), 18 and can display files of different types with different colors and icons. 19 . 20 gentoo borrows some of its look and feel from the classic Amiga file 21 manager "Directory OPUS" (written by Jonathan Potter). (Ho aggiunto i numeri di riga.) 4.2. Il file `copyright' ------------------------ Questo file contiene le informazioni sui riferimenti, copyright e licenza del pacchetto upstream. Il suo formato non è dettato dalla Policy, ma i contenuti lo sono (sezioni 12.6 "Informazioni di Copyright"). dh_make ne ha creato uno di default, quello di seguito: 1 This package was debianized by Josip Rodin on 2 Wed, 11 Nov 1998 21:02:14 +0100. 3 4 It was downloaded from 5 6 Upstream Author(s): 7 8 Copyright: 9 10 (Ho aggiunto i numeri di riga.) Le cose importanti da aggiungere a questo file sono l'indirizzo da cui il pacchetto è stato preso e l'effettiva nota di copyright e licenza. Devi includere la licenza completa, a meno che non sia una delle comuni licenze di free software, come la GNU GPL o LGPL, la BSD o l'Artistic, nel quale caso puoi semplicemente fare riferimento all'opportuno file in /usr/share/common-licenses/ che esiste su tutti i sistemi Debian. In breve, ecco come il file copyright di gentoo appare: 1 This package was debianized by Josip Rodin on 2 Wed, 11 Nov 1998 21:02:14 +0100. 3 4 It was downloaded from: ftp://ftp.obsession.se/gentoo/ 5 6 Upstream author: Emil Brink 7 8 This software is copyright (c) 1998-99 by Emil Brink, Obsession 9 Development. 10 11 You are free to distribute this software under the terms of 12 the GNU General Public License. 13 On Debian systems, the complete text of the GNU General Public 14 License can be found in /usr/share/common-licenses/GPL file. (Ho aggiunto i numeri di riga.) 4.3. Il file `changelog' ------------------------ Questo è un file obbligatorio, che ha un formato speciale descritto nella Policy alla sezione 4.4 "debian/changelog". Tale formato è usato da dpkg e altri programmi per ricavare il numero di versione, revisione, distribuzione e livello di urgenza del tuo pacchetto. Per te è ugualmente importante dal momento che è una buona cosa aver documentato tutte le modifiche apportate. Questo aiuterà chi scarica il tuo pacchetto a vedere velocemente se ci sono problemi non risolti con il pacchetto, che dovrebbe sapere. Sarà salvato come `/usr/share/doc/gentoo/changelog.Debian.gz' nel pacchetto binario. dh_make ne crea uno di default, che appare così: 1 gentoo (0.9.12-1) unstable; urgency=low 2 3 * Initial Release. 4 5 -- Josip Rodin Wed, 11 Nov 1998 21:02:14 +0100 6 7 Local variables: 8 mode: debian-changelog 9 End: (Ho aggiunto i numeri di riga.) La riga 1 è il nome del pacchetto, versione, distribuzione e livello di urgenza. Il nome deve corrispondere al nome del pacchetto sorgente, la distribuzione dovrebbe essere `unstable' o `experimental' (per ora), e il livello non dovrebbe essere modificato in qualcosa maggiore di `low'. :-). Le righe 3-5 sono voci di log, dove documenti le modifiche fatte nella revisione del pacchetto (non le modifiche di upstream - c'è un file speciale a tale scopo, creato dall'autore di upstream, installato come /usr/share/doc/gentoo/changelog.gz). Le nuove righe devono essere inserite prima della riga più in alto, che inizia con un asterisco (`*'). Puoi farlo con dch(1), emacs(1) o a mano con un editor di testo. Devi metterci qualcosa di questo genere: 1 gentoo (0.9.12-1) unstable; urgency=low 2 3 * Initial Release. 4 * This is my first Debian package. 5 * Adjusted the Makefile to fix $DESTDIR problems. 6 7 -- Josip Rodin Wed, 11 Nov 1998 21:02:14 +0100 8 (Ho aggiunto i numeri di riga.) Puoi leggere altro sull'aggiornamento del file changelog più oltre in Capitolo 9, `Aggiornamento del pacchetto'. 4.4. Il file `rules' -------------------- Ora occorre dare una occhiata alle regole esatte che dpkg-buildpackage(1) userà per creare effettivamente il pacchetto. Questo file è in effetti un altro Makefile, ma diverso da quello dei sorgenti upstream. Diversamente da altri file in debian/, questo è marcato come eseguibile. Tutti i file `rules', come ogni Makefile, consistono di diverse regole che specificano come gestire i sorgenti. Ogni regola consiste di target e nomi di file o nomi di azione che devono essere intraprese (per es. `build:' o `install:'.) Le regole che tu vuoi siano eseguite sono invocate come argomenti a riga di comando (per esempio, `./debian/rules build' o `make -f rules install'.) Dopo il nome del target, puoi fornire i nomi delle dipendenze, il programma o file da cui dipende quella regola. A seguire, ci può essere un qualsiasi numero di comandi (indentati con !), finché si trova una riga vuota. Da quel punto inizia un'altra regola. Righe vuote multiple e linee che iniziano con `#' (hash) sono trattate come commenti e ignorate Sarai probabilmente confuso ora, ma sarà tutto più chiaro dopo l'esame del file `rules' che dh_make fornisce come default. Dovresti anche leggere la voce `make' in info per maggiori informazioni. La cosa importante da capire, a proposito del file rules creato da dh_make, è che si tratta solo di un suggerimento. Funzionerà per semplici pacchetti, ma per i più complicati non avere remore nell'aggiungere o togliere qualcosa ad esso, per accomodarlo alle tue necessità. L'unica cosa che non devi modificare sono i nomi delle regole, perché gli strumenti usano tutti gli stessi nomi, come richiesto dalla Policy. Ecco (approssimativamente) come appare il file di default debian/rules che dh_make ha generato: 1 #!/usr/bin/make -f 2 # -*- makefile -*- 3 # Sample debian/rules that uses debhelper. 4 # This file was originally written by Joey Hess and Craig Small. 5 # As a special exception, when this file is copied by dh-make into a 6 # dh-make output file, you may use that output file without restriction. 7 # This special exception was added by Craig Small in version 0.37 of dh-make. 8 # Uncomment this to turn on verbose mode. 9 #export DH_VERBOSE=1 10 configure: configure-stamp 11 configure-stamp: 12 dh_testdir 13 # Add here commands to configure the package. 14 touch configure-stamp 15 build: build-stamp 16 build-stamp: configure-stamp 17 dh_testdir 18 # Add here commands to compile the package. 19 $(MAKE) 20 #docbook-to-man debian/testpack.sgml > testpack.1 21 touch $@ 22 clean: 23 dh_testdir 24 dh_testroot 25 rm -f build-stamp configure-stamp 26 # Add here commands to clean up after the build process. 27 $(MAKE) clean 28 dh_clean 29 install: build 30 dh_testdir 31 dh_testroot 32 dh_clean -k 33 dh_installdirs 34 # Add here commands to install the package into debian/testpack. 35 $(MAKE) DESTDIR=$(CURDIR)/debian/testpack install 36 # Build architecture-independent files here. 37 binary-indep: build install 38 # We have nothing to do by default. 39 # Build architecture-dependent files here. 40 binary-arch: build install 41 dh_testdir 42 dh_testroot 43 dh_installchangelogs 44 dh_installdocs 45 dh_installexamples 46 # dh_install 47 # dh_installmenu 48 # dh_installdebconf 49 # dh_installlogrotate 50 # dh_installemacsen 51 # dh_installpam 52 # dh_installmime 53 # dh_python 54 # dh_installinit 55 # dh_installcron 56 # dh_installinfo 57 dh_installman 58 dh_link 59 dh_strip 60 dh_compress 61 dh_fixperms 62 # dh_perl 63 # dh_makeshlibs 64 dh_installdeb 65 dh_shlibdeps 66 dh_gencontrol 67 dh_md5sums 68 dh_builddeb 69 binary: binary-indep binary-arch 70 .PHONY: build clean binary-indep binary-arch binary install configure (Ho aggiunto i numeri di riga.) Hai probabilmente familiarità con righe come la prima, dagli script di shell e Perl. Essa dice al sistema operativo che questo file deve essere processato usando /usr/bin/make. Il senso delle variabili DH_* menzionate alle righe 8 e 9 dovrebbe essere evidente dalla breve descrizione. Per maggiori informazioni su DH_COMPAT leggi la sezione "livelli di compatibilità di Debhelper" della debhelper(1)pagina di manuale. Le righe da 11 a 16 sono schemi di supporto per i parametri DEB_BUILD_OPTIONS, descritti nella sezione 10.1 "Binari" della Policy. Di base queste cose controllano se i binari sono creati con i simboli per il debugging, e se questi possono essere eliminati al momento della installazione. Di nuovo, si tratta solo di uno schema, un suggerimento che dovresti seguire. Dovresti controllare come il sistema di compilazione dell'upstream gestisce l'inclusione di simboli di debugging e la loro cancellazione in installazione e implementare il tutto tu stesso. Generalmente puoi dire al gcc di compilare con "-g" usando la variabile CFLAGS -- se questo è il caso del tuo pacchetto, propaga la variabile _aggiungendo_ `CFLAGS="$(CFLAGS)"' alla chiamata $(MAKE) nella regola build (vedi oltre). In alternativa, se il tuo pacchetto usa uno script configure di autoconf, puoi passarlo a configure _premettendo_ la suddetta stringa alla invocazione di ./configure nella regola di build. A proposito di stripping, i programmi sono configurati comunemente per essere installati non strippati, e spesso senza una opzione per modificare questa cosa. Fortunatamente, hai anche dh_strip(1) che controllerà se il flag DEB_BUILD_OPTIONS=nostrip è configurato e terminerà silenziosamente. Le righe dalla 18 alla 26 descrivono la regola `build' (e la figlia `build-stamp') che lanciano make con il Makefile proprio della applicazione per compilare il programma. Se il tuo pacchetto usa le utilità di configurazione GNU per creare i binari, assicurati assolutamente di leggere `/usr/share/doc/autotools-dev/README.Debian.gz' . Parleremo dell'esempio commentato docbook-to-man più avanti in Sezione 5.8, `manpage.1.ex, manpage.sgml.ex'. La regola `clean', come specificata nelle righe 28-36, ripulisce ogni binario non necessario e file autogenerati, lasciati in giro dalla creazione del pacchetto. Questa regola deve lavorare tutte le volte (anche quando l'albero dei sorgenti _è_ già ripulito!), per cui usa le opzioni di forzatura (per es. per rm, è -f), oppure fai in modo che make ignori i valori di ritorno (errori) usando un `-' prima del nome del comando. Il processo di installazione, la regola `install', inizia a riga 38. Fondamentalmente lancia la regola `install' del Makefile del programma, ma installa nella directory `$(CURDIR)/debian/gentoo' - questo è il motivo per cui abbiamo specificato $(DESTDIR) come directory radice per l'installazione nel Makefile di gentoo. Come suggeriscono i commenti, la regola `binary-indep', alla riga 48, è usata per costruire i pacchetti indipendenti dalla architettura. Dal momento che non ne abbiamo, non verrà fatto niente in questo caso. Fino alla prossima regola - `binary-arch', dalla riga 52 alla 79, lanciamo una serie di piccoli programmi di utilità dal pacchetto debhelper che svolgono varie operazioni sui file del tuo pacchetto per renderlo conforme alla Policy. Se il tuo pacchetto fosse del tipo `Architecture: all', avresti bisogno di includere tutti i comandi per costruire i pacchetti sotto la regola `binary-indep', e lasciare la regola `binary-arch' vuota, invece. I nomi dei programmi di debhelper iniziano con dh_, e il resto è la descrizione di cosa fa effettivamente il programma di utilità. È tutto abbastanza auto esplicativo, ma ecco qualche spiegazione addizionale: * dh_testdir(1) controlla di trovarsi nella giusta directory (cioè la directory superiore dei sorgenti), * dh_testroot(1) controlla che tu abbia i privilegi di root che sono necessari per i target `binary-arch', `binary-indep' e 'clean', * dh_installman(1) copia tutte le pagine di man al posto giusto nella directory destinazione, devi solo dirgli dove sono relativamente alla directory superiore dei sorgenti, * dh_strip(1) elimina le intestazioni per il debugging dagli eseguibili e librerie, per renderli più piccoli, * dh_compress(1) comprime pagine di man e documentazioni più grandi di 4kB con gzip(1), * dh_installdeb(1) copia i file legati al pacchetto (per es. gli script da maintainer) sotto la directory `debian/gentoo/DEBIAN', * dh_shlibdeps(1) calcola le dipendenze da librerie condivise di librerie ed eseguibili, * dh_gencontrol(1) installa una versione modificata del file di controllo in `debian/gentoo/DEBIAN', * dh_md5sums(1) genera i codici di controllo MD5 per tutti i file del pacchetto. Per informazioni più complete su cosa fanno tutti questi script dh_*, e quali sono le loro altre opzioni, leggi le rispettive pagine di manuale. Ci sono alcuni altri, alle volte utili, script dh_*, che non sono menzionati qui. Se ne avessi bisogno, leggi la documentazione di debhelper. La sezione binary-arch è quella dove dovresti effettivamente commentare qualsiasi riga che richiama funzionalità che non occorrono. Per gentoo, commenterò tutte le righe su examples, cron, init, man and info, semplicemente perché gentoo non le richiede. Inoltre alla linea 68, avrò bisogno di sostituirò `ChangeLog' con `FIXES', perché è il nome reale del file di changelog dell'upstream. Le ultime due righe (insieme con le altre non spiegate qui) sono solo cose più o meno necessarie, delle quali puoi leggere nel manuale del make e nella Policy. Al momento, non è essenziale conoscerle. ------------------------------------------------------------------------------- 5. Altri file sotto debian/ --------------------------- Vedrai che ci sono altri file nella sottodirectory debian/, molti dei quali con suffisso `.ex', che sta a indicare degli esempi. Dagli una occhiata. Se volessi usarli o avessi necessità di usarne le funzionalità: * esamina la documentazione relativa (suggerimento: il Policy Manual), * se necessario modifica i file per adattarli alle tue necessità, * rinominali per eliminare il suffisso `.ex' se ne hanno uno, * modifica il file rules se necessario. Alcuni di questi file, quelli più comunemente usati, sono spiegati nelle sezioni seguenti. 5.1. README.Debian ------------------ Qualsiasi dettaglo extra o discrepanza fra il pacchetto originale e la versione debianizzata, deve essere documentata qui. dh_make ne crea uno di default, che appare come segue: gentoo for Debian ---------------------- -- Josip Rodin , Wed, 11 Nov 1998 21:02:14 +0100 Poiché non dobbiamo aggiungere niente qui, cancelleremo questo file. 5.2. conffiles.ex ----------------- Una delle esperienze più tedianti con il software, capita quando si passa parecchio tempo a configurare con tutti gli sforzi un programma, per vedersi poi cancellate tutte le modifiche effettuate, a seguito di un aggiornamento. Debian risolve questo problema marcando i file di configurazione in modo che quando si aggiorna un pacchetto venga richiesto se si vogliono conservare i vecchi file di configurazione, o meno. Il modo di fare questo in un pacchetto è inserire il path completo di ciascun file di configurazione (generalmente in /etc), uno per riga, in un file che si chiama `conffiles'. Gentoo ha un file di configurazione, /etc/gentoorc, e lo inseriremo nel file `conffiles'. Se il programma che stai pacchettizzando richiede che ogni utente modifichi il file di configurazione per funzionare, prendi in considerazione la possibilità di non marcarlo come conffile. Puoi gestire degli esempi di configurazione dagli `script del maintainer', per maggiori informazioni vedi Sezione 5.12, `postinst.ex, preinst.ex, postrm.ex, prerm.ex'. Se il tuo programma non ha conffiles, puoi in tutta sicurezza cancellare il file `conffiles' dalla directory debian/. 5.3. cron.d.ex -------------- Se il tuo pacchetto richiede che compiti regolarmente schedulati siano svolti in modo appropriato, puoi usare questo file per configurarli. Nota che questo non include la rotazione dei log; per quello guarda dh_installlogrotate(1) e logrotate(8). In caso contrario rimuovilo. 5.4. dirs --------- Questo file specifica le directory che occorrono, ma che la normale procedura di installazione (make install), per qualche motivo, non crea. Per default, contiene: usr/bin usr/sbin Osserva che lo slash prefisso non è incluso. Cambieremo normalmente tale file come segue: usr/bin usr/man/man1 ma queste directory sono già create nel Makefile, per cui non ci serve tale file, e lo cancelleremo. 5.5. docs --------- Questo file specifica i nomi dei file di documentazione che possiamo far installare a dh_installdocs nella directory temporanea per noi. Per default, includerà tutti i file esistenti nella directory principale dei sorgenti che si chiamano "BUGS", "README*", "TODO", ecc. Per gentoo, ho incluso anche qualcos'altro: BUGS CONFIG-CHANGES CREDITS ONEWS README README.gtkrc TODO Possiamo anche rimuovere questo file e invece elencare quei file sulla riga di comando di `dh_installdocs' nel file `rules', in questo modo: dh_installdocs BUGS CONFIG-CHANGES CREDITS ONEWS README \ README.gtkrc TODO Per quanto inversomile possa sembrare, potresti non avere nessuno di questi file nella directory dei sorgenti del pacchetto. In tal caso potresti in tutta sicurezza cancellare questo file. Ma non rimuovere la chiamata `dh_installdocs' nel file `rules' perchè è usata per installare il file `copyright' e altre cose. 5.6. emacsen-*.ex ----------------- Se il tuo pacchetto fornisce dei file Emacs che possono essere compilati al momento della installazione, puoi usare questi file per configurarlo. Sono installati nella directory temporanea da dh_installemacsen(1), per cui non dimenticare di decommentare quella riga nel file `rules' se lo usi. Se non ti servono, rimuovili. 5.7. init.d.ex -------------- Se il tuo pacchetto è un daemon che richiede di essere lanciato alla partenza del sistema, hai ovviamente ignorato la mia raccomandazione iniziale, vero? :-) Questo è uno schema di file abbastanza generico per uno script da `/etc/init.d/', per cui dovrai verosimilmente modificarlo parecchio. Viene installato nalla directory temporanea da dh_installinit(1). Se non ti serve, rimuovilo. 5.8. manpage.1.ex, manpage.sgml.ex ---------------------------------- Il tuo programma dovrebbe avere una pagina di man. Se non ce l'ha questo file contiene lo scheletro di una pagina che puoi riempire. Le pagine di manuale sono normalmente scritte in nroff(1). L'esempio `manpage.1.ex' è scritto in nroff, anche. Vedi la pagina di manuale relativa a man(7), per una breve descrizione di come modificare tale file. Se d'altro canto preferisci scrivere in SGML invece che in nroff puoi usare lo schema in `manpage.sgml.ex'. Se lo fai, devi: * installare il pacchetto `docbook-to-man' * aggiungere `docbook-to-man' alla riga `Build-Depends' nel file `control' * rimuovere il commento dalla chiamata di docbook-to-man nella regola `build' del tuo file `rules' E ricorda di rinominare il file in qualcosa tipo `gentoo.sgml'! Il nome della pagina finale di manuale dovrebbe includere il nome del programma che sta documentando, per cui la rinomineremo da "manpage" a "gentoo". Questo nome di file include ".1" come primo suffisso, il che indica che è una pagina di manuale per un comando utente. Assicurati che questa sezione sia di fatto quella corretta. Ecco una breve lista delle sezioni di pagina di man: Sezione | Descrizione | Note 1 User commands Comandi e script eseguibili 2 System calls Funzioni del kernel 3 Library calls Funzioni delle librerie di sistema 4 Special files File di /dev 5 File formats Per es. formato di /etc/passwd 6 Games O programmi frivoli 7 Macro packages Come le macro di man. 8 System administration Programmi usati da root. 9 Kernel routines Chiamate non standard e interne Così la manpage di gentoo dovrebbe chiamarsi `gentoo.1'. Non c'era nessuna pagina man gentoo.1 nei sorgenti originali, per cui ne ho scritta una, usando le informazioni dell'esempio e la documentazione dall'upstream. 5.9. menu.ex ------------ Gli utenti di X Window generalmente hanno un window manager con un menu che può essere adattato per lanciare programmi. Se è stato installato il pacchetto `menu', verrà creato un insieme di menu per ciascun programma del sistema. Questo è il file `menu.ex' che di default dh_make crea: ?package(gentoo):needs=X11|text|vc|wm section=Apps/see-menu-manual\ title="gentoo" command="/usr/bin/gentoo" Il primo campo dopo i due punti è "needs", e specifica di che tipo di interfaccia il programma ha bisogno. Modificalo in una delle alternative in elenco, per esempio "text" o "X11". Il successivo è "section", dove voce di menu e sottomenu dove dovrebbe apparire. L'elenco corrente delle sezioni si trova in: `/usr/share/doc/debian-policy/menu-policy.html/ch2.html#s2.1' Il campo "title" è il nome del programma. Puoi iniziarlo in maiuscolo se preferisci. Solo, mantienilo breve. Infine, il campo "command" è la riga di comando che lancia il programma. Adesso, cambieremo la voce di menu in questo: ?package(gentoo):needs=X11 section=Apps/Tools \ title="Gentoo" command="gentoo" Puoi anche aggiungere altri campi come "longtitle", "icon", "hints", ecc. Vedi menufile(5), update-menus(1) e `/usr/share/doc/debian-policy/menu-policy.html/' per maggiori informazioni. 5.10. watch.ex -------------- Questo file è usato per configurare uscan(1) e uupdate(1) (nel pacchetto `devscripts') Sono usati per controllare il sito da dove hai recuperato il sorgente originale. Questo è quello che vi ho inserito: # watch control file for uscan # Site Directory Pattern Version Script ftp.obsession.se /gentoo gentoo-(.*)\.tar\.gz debian uupdate Suggerimento: collegati a Internet, e prova a eseguire "uscan" nella directory del programma, dopo avere creato il file. E leggi le pagine di manuale! :) 5.11. ex.package.doc-base ------------------------- Se il tuo pacchetto ha altra documentazione a parte le pagine man e i documenti info, dovresti usare il file ``doc-base'' per registrarle, in modo che l'utente possa trovarle, con dhelp(1), dwww(1) o doccentral(1), per esempio. Questo in genere include file HTML,PS e PDF, distribuiti in `/usr/share/doc/packagename/'. Il file doc-base di gentoo appare come segue: Document: gentoo Title: Gentoo Manual Author: Emil Brink Abstract: This manual describes what Gentoo is, and how it can be used. Section: Apps/Tools Format: HTML Index: /usr/share/doc/gentoo/html/index.html Files: /usr/share/doc/gentoo/html/*.html Per informazioni sul formato del file, vedi install-docs(8) e il manuale di `doc-base', in `/usr/share/doc/doc-base/doc-base.html/'. 5.12. postinst.ex, preinst.ex, postrm.ex, prerm.ex -------------------------------------------------- Questi file sono chiamati script del maintainer. Sono script posti nell'area di controllo del pacchetto e lanciati da `dpkg' quando il tuo pacchetto è installato, aggiornato o rimosso. Per il momento, dovresti evitare qualsiasi modifica manuale degli script, se possibile, perché sono complicati. Per maggiori informazioni guarda il Policy Manual alla sezione 6, e dai una occhiata a questi file di esempio forniti da dh_make. ------------------------------------------------------------------------------- 6. Costruzione del pacchetto ---------------------------- A questo punto, dovresti essere pronto a creare il pacchetto. 6.1. Costruzione completa ------------------------- Spostati nella directory principale del programma e lancia il comando: dpkg-buildpackage -rfakeroot Questo farà tutto il necessario per te. * pulirà l'albero dei sorgenti (debian/rules clean), usando `fakeroot' * costuirà il pacchetto sorgente (dpkg-source -b) * costruirà il programma (debian/rules build) * costruirà il pacchetto binario (debian/rules binary), usando `fakeroot' * firmerà il file sorgente `.dsc', usando `gnupg' * creerà e firmerà il file di upload `.changes' usando `dpkg-genchanges' e `gnupg' Il solo input da te richiesto è tua chiave PGP segreta, due volte. Fatto ciò, vedrai quattro nuovi file nella directory di cui sopra (`~/debian/'): * _gentoo_0.9.12.orig.tar.gz_ Questo è il codice sorgente originale, semplicemente rinominato in questo modo in modo da aderire allo standard Debian. Osserva che questo è stato creato usando l'opzione `-f' per `dh_make' quando è stato inizialmente lanciato. * _gentoo_0.9.12-1.dsc_ È un sommario del contenuto del codice sorgente. Questo file è generato dal tuo file `control', ed è usato quando si scompatta il sorgente con dpkg-source(1). Questo file è firmato con GPG, in modo che si possa essere sicuri che effettivamente è fatto da te. * _gentoo_0.9.12-1.diff.gz_ Questo file compresso contiene ogni singola modifica fatta al codice sorgente originale, in una forma nota come "diff unificata". Viene creata e usata da dpkg-source(1). Attenzione: se non chiami il file di distribuzione originale packagename_version.orig.tar.gz, `dpkg-source' non riuscirà a creare il file .diff.gz correttamente! Se qualcun altro volesse ri-creare il tuo pacchetto da zero, potrebbe farlo facilmente usando i suddetti tre file. La procedura di estrazione è banale: copiare semplicemente i tre file da qualche parte e lanciare `dpkg-source -x gentoo_0.9.12-1.dsc'. * _gentoo_0.9.12-1_i386.deb_ Questo è il pacchetto binario completo. Puoi usare `dpkg' per installarlo e rimuoverlo, come per ogni altro pacchetto. * _gentoo_0.9.12-1_i386.changes_ Questo file descrive tutte le modifiche fatte nella revisione corrente del pacchetto, ed è usata dai programmi di mantenimento dell'archivio FTP di Debian per installare i pacchetti binari e sorgenti. È parzialmente generato dal contenuto del file `changelog' e dal file .dsc. Questo file è firmato con GPG, in modo che si possa essere sicuri che è effettivamente tuo. Quando lavori sul pacchetto, cambieranno le modalità di funzionamento e nuove funzionalità potranno essere aggiunte. Quelli che scaricano il tuo pacchetto, possono quardare questo file per vedere velocemente quali sono i cambiamenti. I programmi di mantenimento dell'archivio Debian invieranno anche i contenuti di questo file alla mailing list debian-devel-changes. Le lunghe stringhe di numeri nei file .dsc e .changes sono codici di controllo MD5 per i file menzionati. Chi scarica questi file, può controllarli con md5sum(1) e se i numeri non corrispondessero saprebbe che il file relativo è corrotto, o è stato alterato. 6.2. Ricostruzione veloce ------------------------- Con un grosso pacchetto, potresti non voler ricostruire tutto da zero, ogni volte che modifichi un dettaglio in debian/rules. Per motivi di testing puoi creare un file .deb, ricostruendo i sorgenti upstream come segue: fakeroot debian/rules binary Una volta finito con i tuoi aggiustamenti, ricorda di ricostruire usando la giusta procedura. Potresti non essere in grado di caricare il pacchetto correttamente se provi con dei file .deb creati in questo modo. 6.3. Il comando `debuild' ------------------------- Puoi automatizzare il processo di creazione di un package ulteriormente con il comando `debuild'. Vedi debuild(1). La configurazione del comando debuild può essere fatta usando `/etc/devscripts.conf' o `~/.devscripts'. Suggerisco almeno le seguenti impostazioni: DEBSIGN_KEYID="Your_GPG_keyID" DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -ICVS -I.svn" Con tali opzioni, puoi creare i pacchetti sempre usando la tua chiave GPG ed evitare di includere componenti non richieste. (Questo è utile anche per le sponsorizzazioni.) Per esempio, ripulire i sorgenti e ricreare il pacchetto da un account utente si fa semplicemente con: debuild clean debuild 6.4. Il sistema `dpatch' ------------------------ Il semplice impiego dei comandi `dh_make' e `dpkg-buildpackage' crea un singolo grosso file `diff.gz' che contiene i file di mantenimento in `debian/' e i file di patch ai sorgenti. Un file così fatto è ingombrante da esaminare e comprendere per ogni successiva modifica successiva all'albero dei sorgenti. Questo non è bello. [1] Diversi metodi man il mantenimento di insiemi di patch sono stati proposti e sono in uso nei pacchetti Debian. Il sistema `dpatch' è uno dei più semplici di tali sistemi di mantenimento delle patch. Altri sono dbs, cdbs, ecc. Un pacchetto che sia pacchettizzato in modo appropriato con `dpatch' ha modifiche al sorgente chiaramente documentate come file di insiemi di patch in `debian/patches/' mentre l'albero dei sorgenti non e' modificato al di fuori della directory `debian/'. Se chiedi a uno sponsor di caricare il tuo package, questo tipo di chiara separazione e documentazione delle tue modifiche è molto importante per rendere veloce l'analisi da parte del tuo sponsor. Il metodo di uso di `dpatch' è spiegato in dpatch(1). Quando qualcuno (incluso te stesso) ti fornisce una patch per il sorgente successivamente, la modifica del pacchetto sotto dpatch è alquanto semplice: * Edita la patch per renderla una patch di tipo -p1 per il sorgente. * Aggiungi una intestazione usando il programma `dpatch patch-template'. * Mettila in `debian/patches' * Aggiungi il nome della patch all'elenco nel file `debian/patches/00list' Inoltre, `dpatch' ha la capacità di rendere le patch dipendenti da architettura, usando macro CPP. [1] Se non sei ancora uno sviluppatore Debian e chiedi al tuo sponsor di caricare il tuo pacchetto dopo averlo esaminato, dovresti rendere il più possibile semplice per lui l'analisi. 6.5. Includere `orig.tar.gz' per il caricamento. ------------------------------------------------ Quando inserisci per la prima volta il pacchetto nell'archivio, devi includere il file dei sorgenti originali `orig.tar.gz'. Se la versione del pacchetto non ha una revisione Debian `-0' o `-1', devi aggiungere al comando `dpkg-buildpackage' l'opzione "`-sa'". Al contrario, l'opzione "`-sd'" forzerà l'esclusione del sorgente originale `orig.tar.gz'. ------------------------------------------------------------------------------- 7. Controllare il pacchetto per errori -------------------------------------- 7.1. I pacchetti `lintian' -------------------------- Lancia lintian(1) sul tuo file .changes; questo programma fa una verifica in merito a molti comuni errori di pacchettizzazione. I comando sono: lintian -i gentoo_0.9.12-1_i386.changes Ovviamente, sostituisci il nome del file con il nome del file changes generato per il tuo pacchetto. Se sembra che ci siano errori (le righe che iniziano con E:), leggi la spiegazione (le righe con N:), correggi e ricostruisci come descritto in Sezione 6.1, `Costruzione completa'. Se ci sono righe che iniziano con W:, si tratta di warning, per cui aggiusta il pacchetto o verifica che i warning siano spuri (e crea gli ovverrides per Lintian; vedi la documentazione per i dettagli) Nota che puoi creare il pacchetto con `dpkg-buildpackage' , e lanciare `lintian' con un solo comando con debuild(1). 7.2. Il comando `mc' -------------------- Puoi spacchettare il contenuto di un pacchetto `*.deb' con il comando dpkg-deb(1) command. Puoi vedere il contenuto di un pacchetto Debian con debc(1). Tutto ciò può essere fatto in modo intuitivo usando un file manager come mc(1) che permette non solo l'esame di un pacchetto `*.deb' ma anche di file `*.diff.gz' e `*.tar.gz' Fa attenzione a file non necessari extra o di dimensione nulla, sia nei pacchetti binari che sorgenti. Spesso le cose non vengono ripulite come dovrebbero: modifica il tuo file rules per farlo. Suggerimento: ``zgrep ^+++ ../gentoo_0.9.12-1.diff.gz'' ti fornirà una lista delle modifiche/aggiunte ai file sorgenti, e ``dpkg-deb -c gentoo_0.9.12-1_i386.deb'' o ``debc gentoo_0.9.12-1_i386.changes'' ti fornirà l'elenco dei file nel pacchetto binario. 7.3. Il comando `debdiff' ------------------------- Puoi confrontare le liste dei file in due pacchetti binari Debian con il comando debdiff(1). Questo è utile per verificare che nessun file sia stato non intenzionalmente spostato o rimosso, e non siano state fatte modifiche inavvertite nell'aggiornamento del pacchetto. Puoi verificare gruppi di file `*.deb' semplicemente con ``debdiff old-package.change new-package.change''. 7.4. Il comando `interdiff' --------------------------- Puoi confrontare due file `diff.gz' con il comando interdiff(1). Questo è utile per verificare che non ci siano modifiche inavvertite fatte sui sorgenti dal maintainer aggiornando i pacchetti. Esegui ``interdiff -z old-package.diff.gz new-package.diff.gz''. 7.5. Il comando `debi' ---------------------- Installa il pacchetto per testarlo tu stesso, per esempio usando il comando debi(1) come root. Prova a installarlo e lanciarlo su una macchina che non sia la tua, e verifica qualsiasi errore o warning durante l'installazione o l'esecuzione. 7.6. Il pacchetto `pbuilder' ---------------------------- Il pacchetto `pbuilder' è molto utile per verificare le dipendenze di creazione del pacchetto da un ambiente di compilazione sano e minimale (chroot). Questo assicura compilazioni pulite dai sorgenti sotto un compilatore automatico (auto-builder) per differenti architetture ed evita i bug FTBS (Fails To Build from Source) di severità seria, che sono sempre di categoria RC (Critici per il Rilascio). Vedi http://buildd.debian.org/ per maggiori informazioni sul compilatore automatico di pacchetti Debian. L'uso di base più importante del pacchetto `pbuilder' è la invocazione diretta del comando `pbuilder' come root. Per esempio, scrivi i comandi che seguono nella directory in cui si trovano i file `.orig.tar.gz', `.diff.gz', e `.dsc' per creare un pacchetto. root # pbuilder create # if second time, pbuilder update root # pbuilder build foo.dsc Il nuovo pacchetto così creato sarà localizzato in `/var/cache/pbuilder/result/' con proprietà assegnata a root. Il comando `pdebuild' aiuta ad usare le funzioni del pacchetto `pbuilder' come utente ordinario. In questo modo, dalla radice dell'albero dei sorgenti, avendo il file `orig.tar.gz' nella directory superiore, puoi eseguire i comandi seguenti: $ sudo pbuilder create # if second time, sudo pbuilder update $ pdebuild I pacchetti creati saranno collocati in `/var/cache/pbuilder/result/' con proprietario non-root. [1] Se vuoi aggiungere una sorgente apt addizionale da usare con il pacchetto `pbuilder', configura `OTHERMIRROR' in `~/.pbuilderrc' o `/etc/pbuilderrc' ed esegui (per sarge) $ sudo pbuilder update --distribution sarge --override-config L'impiego di `--override-config' è necessario per aggiornare la sorgente apt all'interno dell'ambiente chroot. Vedi http://www.netfort.gr.jp/~dancer/software/pbuilder.html, pdebuild(1), pbuilderrc(5), e pbuilder(8) . [1] Al momento, suggerisco di configurare il tuo sistema con la directory `/var/cache/pbuilder/result/' scrivibile dall'utente e impostare `~/.pbuilderrc' o `/etc/pbuilderrc' includendo AUTO_DEBSIGN=yes Questo consentirà di firmare i pacchetti generati con la tua chiave segreta GPG, impostata in `~/.gnupg/'. Dal momento che il pacchetto `pbuilder' è ancora in evoluzione, dovresti consultare lo situazione effettiva in merito alla configurazione consultando la documentazione ufficiale più recente. ------------------------------------------------------------------------------- 8. Caricamento del pacchetto ---------------------------- Una volta testato il nuovo pacchetto approfonditamente, sarai pronto a partire con il processo di candidatura come nuovo maintainer Debian, come descritto in http://www.debian.org/devel/join/newmaint. 8.1. Caricamento nell'archivio Debian ------------------------------------- Una volta diventato uno sviluppatore ufficiale, avrai necessità di caricare il pacchetto nell'archivio Debian. Potresti farlo a mano, ma è più semplice usare i tool automatici forniti, come dupload(1) o dput(1). Descriveremo come puoi farlo con `dupload'. Per prima cosa devi creare il file di configurazione di dupload. Puoi modificare il file di sistema `/etc/dupload.conf' o averne uno tuo personale `~/.dupload.conf' che fornisce le poche cose da modificare. Scrivici dentro qualcosa come: package config; $default_host = "anonymous-ftp-master"; $cfg{'anonymous-ftp-master'} = { fqdn => "ftp-master.debian.org", method => "ftp", incoming => "/pub/UploadQueue/", # i file passano per dinstall su ftp-mastr che invia email autonomamente dinstall_runs => 1, }; 1; Ovviamente, modifica le mie informazini personali con le tue, e leggi la pagina man dupload.conf(5) per capire cosa significa ciascuna opzione. L'opzione $default_host è la più particolare -- stabilisce quale coda di caricamento sarà usata per default. "anonymous-ftp-master" è la primaria, ma è possibile che tu voglia usarne un'altra, più veloce. Per maggiori informazioni sulle code, leggi la Guida di Riferimento per lo Sviluppatore, nella sezione "Caricare un pacchetto", su `/usr/share/doc/developers-reference/ch-pkgs.en.html#s-upload' A questo punto connettiti al tuo provider Internet, e scrivi questo comando: dupload --to master gentoo_0.9.12-1_i386.changes `dupload' verifica che i codici di controllo MD5 dei file siano coerenti con quelli del file .changes, per cui ti avvertirà di ricreare il pacchetto come descritto in Sezione 6.1, `Costruzione completa', per caricare appropriatamente il pacchetto. Se trovi problemi nell'uso di ftp://ftp-master.debian.org/pub/UploadQueue/, puoi risolvere caricando manualmente un file `*.commands' firmato con GPG all'indirizzo ftp://ftp-master.debian.org/pub/UploadQueue/ via `ftp'. [1] Per esempio, usa `hello.commands': -----BEGIN PGP SIGNED MESSAGE----- Uploader: Roman Hodek Commands: rm hello_1.0-1_i386.deb mv hello_1.0-1.dsx hello_1.0-1.dsc -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia iQCVAwUBNFiQSXVhJ0HiWnvJAQG58AP+IDJVeSWmDvzMUphScg1EK0mvChgnuD7h BRiVQubXkB2DphLJW5UUSRnjw1iuFcYwH/lFpNpl7XP95LkLX3iFza9qItw4k2/q tvylZkmIA9jxCyv/YB6zZCbHmbvUnL473eLRoxlnYZd3JFaCZMJ86B0Ph4GFNPAf Z4jxNrgh7Bc= =pH94 -----END PGP SIGNATURE----- [1] Vedi ftp://ftp-master.debian.org/pub/UploadQueue/README. In alternativa, puoi usare il comando `dcut' dal pacchetto `dput' . 8.2. Caricamento in archivio privato ------------------------------------ Se volessi creare un archivio di pacchetti personal all'indirizzo `URL="http://people.debian.org/~"' come sviluppatore con un semplice comando `dupload -t ', dovresti aggiungere al file `/etc/dupload.conf' quanto segue: # Developer account $cfg{''} = { fqdn => "people.debian.org", method => "scpb", incoming => "/home//public_html/package/", # Non occorre annunciare dinstall_runs => 1, }; $cfg{''}{preupload}{'changes'} = " echo 'mkdir -p public_html/package' | ssh people.debian.org 2>/dev/null ; echo 'Package directory created!'"; $cfg{''}{postupload}{'changes'} = " echo 'cd public_html/package ; dpkg-scanpackages . /dev/null >Packages || true ; dpkg-scansources . /dev/null >Sources || true ; gzip -c Packages >Packages.gz ; gzip -c Sources >Sources.gz ' | ssh people.debian.org 2>/dev/null ; echo 'Package archive created!'"; In questo caso, un archivio APT viene creato con una semplice esecuzione di SSH. I file di override richiesti da `dpkg-scanpackages' e `dpkg-scansources' sono impostati a `/dev/null'. Questa tecnica può essere impiegata da chi non è sviluppatore Debian per archiviare i pacchetti nel proprio sito personale. In alternativa, puoi usare `apt-ftparchive' o altri programmi per creare un archivio APT. ------------------------------------------------------------------------------- 9. Aggiornamento del pacchetto ------------------------------ 9.1. Nuova revisione Debian --------------------------- Supponiamo che sia stato segnalato un bug del tuo pacchetto, il #54321, e che si riferisca a un problema che sei in grado di risolvere. Per creare una nuova revisione Debian del pacchetto, hai bisogno di: * Correggere il problema nel pacchetto sorgente, ovviamente. * Aggiungere una nuova revisione nel file changelog Debian, per esempio con ``dch -i'', oppure esplicitamente con ``dch -v -'` e quindi includere i tuoi commenti usando il tuo editor preferito, Suggerimento: come ottenere la data facilmente nel formato richiesto? Usa ``822-date'`, or ``date -R'`. Includi una breve descrizione del bug e la soluzione nella voce del changelog, seguita da: "Closes: #54321". In questo modo, la sottomissione del bug sarà automaticamente chiusa dal software di mantenimento, nel momento in cui il tuo pacchetto sarà accettato nell'archivio Debian. * Ripeti quanto fatto in Sezione 6.1, `Costruzione completa', Capitolo 7, `Controllare il pacchetto per errori', e Capitolo 8, `Caricamento del pacchetto'. La differenza è che questa volta il sorgente originale non sarà incluso, dal momento che non è stato modificato e già esiste nell'archivio Debian. 9.2. Nuovo rilascio di upstream (base) -------------------------------------- Adesso consideriamo una situazione differente, un po' più complicata - una nuova versione upstream è stata rilasciata, e ovviamente vuoi pacchettizzarla. Avrai bisogno di fare quanto segue: * Scarica i nuovi sorgenti e sposta il relativo archivio (per es. dal nome ``gentoo-0.9.13.tar.gz'') nella directory al di sopra del vecchio albero di sorgenti (per es. `~/gentoo/'). * Spostati nella vecchia directory di sorgenti e lancia: uupdate -u gentoo-0.9.13.tar.gz Ovviamente, sostituisci questo nome di file con il nome dell'archivio dei sorgenti del tuo programma. uupdate(1) rinominerà in modo appropriato quell'archivio, proverà ad applicare tutte le modifiche dal tuo precedente file `.diff.gz', e aggiornerà il nuovo file `debian/changelog'. * Portati nella directory ``../gentoo-0.9.13'', il nuovo albero di sorgenti del pacchetto, e ripeti quanto fatto in Sezione 6.1, `Costruzione completa', Capitolo 7, `Controllare il pacchetto per errori', e Capitolo 8, `Caricamento del pacchetto'. Osserva che se hai configurato il file ``debian/watch'' come descritto in Sezione 5.10, `watch.ex', puoi lanciare uscan(1) per cercare automaticamente i sorgenti aggiornati, scaricarli e lanciare `uupdate'. 9.3. New upstream release (realistic) ------------------------------------- Nel preparare pacchetti per il caricamento nell'archivio Debian, dovresti verificare i pacchetti risultanti in dettaglio. Di seguito, ecco un esempio più realistico di tal procedura. 1. Verificare le modifiche nei sorgenti upstream * Leggi i file `changelog', `NEWS', e ogni altra documentazione che possa essere stata rilasciata con la nuova versione. * Esegui ``diff -urN'' tra la vecchia e la nuova versione dei sorgenti upstream per prendere visione della portata delle modifiche, capire dove è stato fatto attivamente lavoro (e perciò dove nuovi bug potrebbero apparire), e dai anche una occhiata per qualsiasi cosa sospetta. 2. Migra il vecchio pacchetto Debian alla nuova versione. * Spacchetto l'archivo dei sorgenti e rinomina la radice dell'albero dei sorgenti come `-/' quindi spostati con ``cd'' in tale directory * Copia l'archivio dei sorgenti nella directory precedente e rinominalo come `_.orig.tar.gz' . * Applica lo stesso tipo di modifica al nuovo albero dei sorgenti e al vecchio. I metodi possibili sono> * il comando ``zcat _.diff.gz | patch -p1'' . * il comando ``uupdate'' , * il comando ``svn merge'' se gestisci i sorgenti con un deposito Subversion , oppure * semplicemente copia la directory `debian/' dai vecchi sorgenti se era pacchettizzata con `dpatch'. * Conserva i vecchi contenuti di changelog (sembra ovvio, ma ci sono stati incidenti in proposito...) * La nuova versione del pacchetto è la versione di rilascio upstream con l'aggiunta di un numero di revisione Debian `-1', per esempio, ``0.9.13-1''. * Aggiungi una voce al changelog con indicato "New upstream release" per tale nuova versione all'inizio del file `debian/changelog'. Per esempio ``dch -v 0.9.13-1''. * Descrivi in modo coinciso le modifiche _nel_ nuovo rilascio upstream che risolvono bug riportati e chiudi tali bug nel changelog. * Descrivi in modo coinciso le modifiche apportate _al_ nuovo rilascio upstream dal manutentore che risolvono bug riportati e chiudi tali bug nel changelog. * Se una patch/fusione non si applica in modo pulito, esamina la situazione per stabilire cosa è andato male (indicazioni in merito sono nei file `.rej'). Il più delle volte, il problema è che una patch da te applicata al sorgente è stata integrata dall'upstream, e perciò non è più rilevante. * Gli aggiornamenti a nuove versioni dovrebbero essere silenti non intrusivi (utenti esistenti dovrebbero solo notare l'aggiornamento scoprendo che che vecchi bug sono stati corretti e che ci sono forse nuove funzionalità). [1] * Se occorre aggiungere dei file modello cancellati per qualsiasi motivo, puoi lanciare nuovamente `dh_make' nella stessa directory, già "debianizzata", con l'opzione `-o' . A quel punto modificali in maniera appropriata. * Le modifiche Debian esistenti devono essere nuovamente vautate: elimina materiale che l'upstream ha incorporato (in una forma o un'altra) e rucorda di mantenere ciò che non è stato incluso dal upstream, a meno che non ci sia una valida ragione per non farlo. * Se fosse stata fatta qualche modifica al sistema di compilazione (sperabilmente dovresti già scoprirlo al passo 1 e aggiornare il file `debian/rules' e le dipendenze per la compilazione in `debian/control' se necessario. 3. Crea il nuovo pacchetto come descritto in Sezione 6.3, `Il comando `debuild'' o Sezione 7.6, `Il pacchetto `pbuilder''. L'impiego di `pbuilder' è consigliato. 4. Verifica che il nuovo pacchetto compila correttamente. * Esegui Capitolo 7, `Controllare il pacchetto per errori'. * Esegui Sezione 9.6, `Verificare gli aggiornamenti di pacchetti'. * Controlla nuovamente per capire se qualche bug è stato corretto ed è correntemente aperto nel Sistema di Gestione dei Bug Debian (http://www.debian.org/Bugs/) . * Verifica il contenuto del file .changes per essere sicuro di caricare nella distribuzione corretta, che i bug appropriati vengano chiusi nel campo Closes: , che i campi Maintainer: e Changed-By: coincidano, che il file abbia una firma GPG, ecc. 5. Se avessi apportato qualche cambiamento nel pacchetto in corso d'opera, torna al passo 2 fino a soddisfarlo. 6. Se il caricamento richiede uno sponsor, assicurati di annotare qualsiasi opzione speciale richiesta nella creazione del pacchetto (come '`dpkg-buildpackage -sa -v ...'') e informane il tuo sponsor in modo che questi possa fare la compilazione in modo esatto. 7. Se devi caricare tu stesso il pacchetto esegui Capitolo 8, `Caricamento del pacchetto'. [1] Per piacere, accertati che il tuo pacchetto modifichi correttamente le configurazione durante gli aggiornamenti, usando `postinst' ben disegnati. ecc. in modo che _non faccia_ cose non volute dall'utente! Queste sono i perfezionamenti che spiegano _perché_ la gente sceglie Debian. Quando l'aggiornamento è necessariamente intrusivo (per es. file di configurazione sparsi tra varie home directory con strutture completamente diverse), puoi considerare di configurare il pacchetto con il più sicuro default (per es. servizi disabilitati) e fornire appropriata documentazione richiesta dalla policy in (`README.Debian' e `NEWS.Debian' ) come ultima risorsa. Ma non abusare di note in debconf. 9.4. Il file `orig.tar.gz' -------------------------- Se provi a creare il pacchetto solo a partire dal nuovo albero dei sorgenti, con la directory `debian/' ma senza il file `orig.tar.gz' nella directory superiore, finirai per creare non intenzinalmente un pacchetto sorgente nativo, che risulta privo di un file `diff.gz'. Questo tipo di pacchettizzazione è appropriato solo per pacchetti specifici di Debian, che non saranno mai utili per un altra distribuzione. [1] Per creare un pacchetto a sorgente non nativo, che consiste in una coppia di file `orig.tar.gz' e `diff.gz' , devi copiare manualmente l'archivio dell'upstream nella directory superiore con il nome del file modificato in `_.orig.tar.gz' come viene fatto dal comando `dh_make' in Sezione 2.4, `La "debianizzazione" iniziale'. [1] Qualcuno ritiene che anche nel caso di pacchetti specifici per Debian, è ancora opportuno nella pratica che il contenuto della directory `debian/' sia nel file `diff.gz' , piuttosto che nel file `.tar.gz' . 9.5. Il comando `cvs-buildpackage' e similari --------------------------------------------- Dovresti prendere in considerazione l'eventualità di usare un sistema di gestione del codice per l'attività di pacchettizzazione. Ci sono diversi programmi di interfaccia adattati per usare i sistemi più comuni. * CVS * `cvs-buildpackage' * Subversion * `svn-buildpackage' * Arch (tla) * `tla-buildpackage' * `arch-buildpackage' Questi comandi possono anche automatizzare la pacchettizzazione di nuovi rilasci dell'upstream. 9.6. Verificare gli aggiornamenti di pacchetti ---------------------------------------------- Quando crei una nuova versione del pacchetto, dovresti fare quanto segue per verificare che il pacchetto può essere aggiornato in modo sicuro: * aggiorna dalla versione precedente, * torna indietro e rimuovilo, * installa il nuovo pacchetto, * rimuovilo e reinstallalo nuovamente, * fanne un purge. Se il pacchetto fa un uso di script non banali di pre/post/inst/rm, assicurati di controllarli in aggiornamento. Tieni a mente che se il pacchetto è stato in precedenza rilasciato in Debian, la gente vorrà spesso fare un aggiornamento dalla versione che era nell'ultima versione Debian. Ricorda di provare l'aggiornamento da tale versione, anche. 9.7. Dove chiedere aiuto ------------------------ Prima di deciderti a fare una domanda in qualche area pubblica, sei pregato di leggere i dannati manuali (RTFM). Questo include la documentazione in `/usr/share/doc/dpkg', `/usr/share/doc/debian', `/usr/share/doc/autotools-dev/README.Debian.gz' i file `/usr/share/doc/package/*' e le pagine man/info di tutti i programmi menzionati in questo documento. Vedi tutte le informazioni in http://nm.debian.org/ e http://people.debian.org/~mpalmer/debian-mentors_FAQ.html. Se hai domande sulla pacchettizzazione alle quale non trovi risposta nella documentazione, puoi chiedere alla mailing list dei Debian Mentors su . Gli sviluppatori più esperti di Debian ti aiuteranno con piacere, ma leggi almeno un po' di documentazione prima di chiedere! Guarda http://lists.debian.org/debian-mentors/ per maggiori informazioni riguardo la mailing list. Quando ricevi una segnalazione di bug (sì, effettive segnalazioni di bug!) saprai che è il momento di fare fare riferimento al Sistema Debian di tracciamento dei bug (http://www.debian.org/Bugs/) e leggere la documentazione lì, per essere in grado di gestire le segnalazioni in modo efficiente. Ti raccomando di leggere la Guida di Riferimento dello Sviluppatore, al capitolo "Gestione dei Bug", su `/usr/share/doc/developers-reference/ch-pkgs.en.html#s-bug-handling' Se ancora hai delle domande, chiedi sulla mailing list degli sviuppatori Debian all'indirizzo . Guarda http://lists.debian.org/debian-devel/ per maggiori informazioni su questa mailing list. Anche se tutto funziona bene, è venuto il momento di iniziare a pregare. Perché? Perché in poche ore (o giorni), gli utenti di tutto il mondo inizieranno a usare il pacchetto, e se hai commesso qualche errore critico, sarai bombardato dalle mail di numerosi utenti Debian arrabbiati... sto scherzando :-) Rilassati e sii pronto per le segnalazioni dei bug, perché c'è molto lavoro da fare prima che il tuo pacchetto sia completamente in linea con le politiche Debian (ancora una volta, leggi la _documentazione reale_ per i dettagli). Buona fortuna! ------------------------------------------------------------------------------- A. Esempi --------- Di seguito pacchettiziamo l'archivio upstream .tar.gz e carichiamo tutti i pacchetti risultanti `'. A.1. Semplice esempio di pacchetto ---------------------------------- $ mkdir -p # nuova directory vuota $ cd $ tar -xvzf .tar.gz # prendi i sorgenti $ cd $ dh_make -e -f .tar.gz ... Rispondi alle domande ... Modifica il sorgente ... Se si tratta di un pacchetto di script, imposta debian/control con "Architecture: all" ... Non cancellare ../.orig.tar.gz $ debuild ... Assicurati non ci siano messaggi di tipo warning $ cd .. $ dupload -t _i386.changes A.2. Pacchettizzare l'esempio con `dpatch' e `pbuilder' ------------------------------------------------------- $ mkdir -p # nuova directory vuota $ cd $ tar -xvzf .tar.gz $ cp -a $ cd $ dh_make -e -f /path/from/.tar.gz ... Rispondi alle domande ... Modifica i sorgenti con un editore di testi ... Prova a pacchetttizzare con "dpkg-buildpackage -rfakeroot -us -uc" ... Modifica i sorgenti per renderli compilabili ... Non cancellare ../.orig.tar.gz $ cd .. $ cp -a # safety backup $ mv /debian debian $ diff -Nru > ... Puoi sovrascrivere la directory mentre stai facendo questo ... Assicurati di mantenere una copia -keep per tua sicurezza $ mkdir -p debian/patches $ dpatch patch-template \ -p "01_patchname" "patch-file description" \ < > debian/patches/01_patchname.dpatch $ cd debian/patches $ echo 01_patchname.dpatch >00list $ cd ../.. # torna a $ rm -rf $ editor debian/rules Qui `debian/rules' all'origine contiene: config.status: configure ./configure --prefix=/usr --mandir=/usr/share build: config.status ${MAKE} clean: $(testdir) $(testroot) ${MAKE} distclean rm -rf debian/imaginary-package debian/files debian/substvars Modifichi `debian/rules' come segue con un editore di testi per usare `dpatch': config.status: patch configure ./configure --prefix=/usr --mandir=/usr/share build: config.status ${MAKE} clean: clean-patched unpatch clean-patched: $(testdir) $(testroot) ${MAKE} distclean rm -rf debian/imaginary-package debian/files debian/substvars patch: patch-stamp patch-stamp: dpatch apply-all dpatch call-all -a=pkg-info >patch-stamp unpatch: dpatch deapply-all rm -rf patch-stamp debian/patched Ora sei pronto a ripacchettizzare i sorgenti con il sistema `dpatch'. $ tar -xvzf .orig.tar.gz $ cp -a debian/ /debian $ cd $ sudo pbuilder update $ pdebuild $ cd /var/cache/pbuilder/result/ $ dupload -t _i386.changes ------------------------------------------------------------------------------- Guida per il nuovo Maintainer Josip Rodin Traduzione: Francesco P. Lovergine versione 1.2.3, 18 January 2005.