Guida per il nuovo Maintainer

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:

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 e nel pacchetto `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') and 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 <package>'. ) ) , Questo pacchetto caricherà anche un gruppo di altri pacchetti come ) ). ) )

Probabilmente vorrai installare i pacchetti seguenti, anche: altamente raccomandati per i nuovi maintainer. Questo rende l'intero processo molto più semplice da iniziare e controllare successivamente. (vedi , , /usr/share/doc/debhelper/README) ) 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 ) ) , ) , ) , /usr/share/doc/lintian/lintian.html/index.html)

Quanto segue è la documentazione molto importante che dovresti leggere insieme a questo documento:

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: non è illustrato in questo documento, perchè il suo uso è sconsigliato. Si rimanda al per maggiori informazioni. 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. Primi passi 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 . 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 e per verificare che il pacchetto sia effettivamente disponibile.

Se sei in grado di adottare il pacchetto, prendi i sorgenti (con qualcosa come Se il pacchetto è nuovo, e decidi che ti piacerebbe facesse parte di Debian, procedi come segue: consulta la 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 . 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. 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 ).

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. 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 <pacchetto>-<versione>.

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. 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 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 <invio>.

Ancora una volta, come nuovo maintainer non sei incoraggiato a creare pacchetti con binari multipli o librerie, come spiegato prima. Non è difficile, ma richiede un po' di conoscenze ulteriori, per cui non descriveremo tutto questo nel seguito.

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 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 per creare automaticamente il programma. Per maggiori dettagli sui Makefile dai una occhiata a .

Osserva che se il tuo programma utilizza l'utilità GNU e/o , 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.

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. 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/tmp oppure 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 -rn usr/local/lib *.[ch]

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. 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 :-) 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. Il file `control'

Questo file contiene vari valori che Questo è il file control che dh_make crea per noi.

1 Source: gentoo 2 Section: unknown 3 Priority: optional 4 Maintainer: Josip Rodin <jrodin@jagor.srce.hr> 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: <insert up to 60 chars description> 12 <insert long description, indented with spaces> (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 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 riga 5 è la versione degli standard di Debian Policy che questo pacchetto segue, la versione del manuale di Policy che leggi mentre costruisci i pacchetti.

La sesta riga include la lista dei pacchetti richiesti per creare il tuo pacchetto. Alcuni pacchetti come gcc e make sono impliciti, vedi il pacchetto 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.

Gentoo sembra richiedere 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é 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 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 , , , 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, 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 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 "A 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 <jrodin@jagor.srce.hr> 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: A 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.) 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 13.6 "Informazioni di Copyright").

dh_make ne ha creato uno di default, quello di seguito:

1 This package was debianized by Josip Rodin <jrodin@jagor.srce.hr> on 2 Wed, 11 Nov 1998 21:02:14 +0100. 3 4 It was downloaded from <fill in ftp site> 5 6 Upstream Author(s): <put author(s) name and email here> 7 8 Copyright: 9 10 <Must follow here> (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 <jrodin@jagor.srce.hr> 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 <emil@obsession.se> 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.) Il file `changelog'

Questo è un file obbligatorio, che ha un formato speciale descritto nella Policy alla sezione 5.3 "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 <jrodin@jagor.srce.hr> 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 , 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 <jrodin@jagor.srce.hr> 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 . Il file `rules'

Ora occorre dare una occhiata alle regole esatte che 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 <tab>!), 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 # Sample debian/rules that uses debhelper. 3 # GNU copyright 1997 to 1999 by Joey Hess. 4 5 # Uncomment this to turn on verbose mode. 6 #export DH_VERBOSE=1 7 8 # This is the debhelper compatibility version to use. 9 export DH_COMPAT=3 10 11 ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS))) 12 CFLAGS += -g 13 endif 14 ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS))) 15 INSTALL_PROGRAM += -s 16 endif 17 18 build: build-stamp 19 build-stamp: 20 dh_testdir 21 22 # Add here commands to compile the package. 23 $(MAKE) 24 #/usr/bin/docbook-to-man debian/gentoo.sgml > gentoo.1 25 26 touch build-stamp 27 28 clean: 29 dh_testdir 30 dh_testroot 31 rm -f build-stamp 32 33 # Add here commands to clean up after the build process. 34 -$(MAKE) clean 35 36 dh_clean 37 38 install: build 39 dh_testdir 40 dh_testroot 41 dh_clean -k 42 dh_installdirs 43 44 # Add here commands to install the package into debian/gentoo. 45 $(MAKE) install DESTDIR=$(CURDIR)/debian/gentoo 46 47 # Build architecture-independent files here. 48 binary-indep: build install 49 # We have nothing to do by default. 50 51 # Build architecture-dependent files here. 52 binary-arch: build install 53 dh_testdir 54 dh_testroot 55 # dh_installdebconf 56 dh_installdocs 57 dh_installexamples 58 dh_installmenu 59 # dh_installlogrotate 60 # dh_installemacsen 61 # dh_installpam 62 # dh_installmime 63 # dh_installinit 64 dh_installcron 65 dh_installman 66 dh_installinfo 67 # dh_undocumented 68 dh_installchangelogs ChangeLog 69 dh_link 70 dh_strip 71 dh_compress 72 dh_fixperms 73 # dh_makeshlibs 74 dh_installdeb 75 # dh_perl 76 dh_shlibdeps 77 dh_gencontrol 78 dh_md5sums 79 dh_builddeb 80 81 binary: binary-indep binary-arch 82 .PHONY: build clean binary-indep binary-arch binary install (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 6 e 9 dovrebbe essere evidente dalla breve descrizione. Per maggiori informazioni su DH_COMPAT leggi la sezione "livelli di compatibilità di Debhelper" della pagina di manuale.

Le righe da 11 a 16 sono schemi di supporto per i parametri DEB_BUILD_OPTIONS, descritti nella sezione 11.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 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. Parleremo dell'esempio commentato docbook-to-man più avanti in .

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 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: controlla di trovarsi nella giusta directory (cioè la directory superiore dei sorgenti), controlla che tu abbia i privilegi di root che sono necessari per i target `binary-arch', `binary-indep' e 'clean', copia tutte le pagine di man al posto giusto nella directory destinazione, devi solo dirgli dove sono relativamente alla directory superiore dei sorgenti, elimina le intestazioni per il debugging dagli eseguibili e librerie, per renderli più piccoli, comprime pagine di man e documentazioni più grandi di 4kB con , copia i file legati al pacchetto (per es. gli script da maintainer) sotto la directory debian/gentoo/DEBIAN, calcola le dipendenze da librerie condivise di librerie ed eseguibili, installa una versione modificata del file di controllo in debian/gentoo/DEBIAN, 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. 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. 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 ---------------------- <possible notes regarding this package - if none, delete this file> -- Josip Rodin <jrodin@jagor.srce.hr>, Wed, 11 Nov 1998 21:02:14 +0100

Poiché non dobbiamo aggiungere niente qui, cancelleremo questo file. 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 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 .

Se il tuo programma non ha conffiles, puoi in tutta sicurezza cancellare il file 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 e .

In caso contrario rimuovilo. 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. 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 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 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 , per cui non dimenticare di decommentare quella riga nel file Se non ti servono, rimuovili. 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 .

Se non ti serve, rimuovilo. 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 . L'esempio , 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 installare il pacchetto aggiungere rimuovere il commento dalla chiamata di docbook-to-man nella regola `build' del tuo file

E ricorda di rinominare il file in qualcosa tipo 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 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 Questo è il file ?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 , e /usr/share/doc/debian-policy/menu-policy.html/ per maggiori informazioni. watch.ex

Questo file è usato per configurare e (nel pacchetto 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! :) ex.package.doc-base

Se il tuo pacchetto ha altra documentazione a parte le pagine man e i documenti info, dovresti usare il file `, o , 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 e il manuale di /usr/share/doc/doc-base/doc-base.html/. 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 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. Costruzione del pacchetto

A questo punto, dovresti essere pronto a creare il pacchetto. 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 costuirà il pacchetto sorgente (dpkg-source -b) costruirà il programma (debian/rules build) costruirà il pacchetto binario (debian/rules binary), usando firmerà il file sorgente creerà e firmerà il file di upload

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 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 . Questo file è firmato con PGP, 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 . Attenzione: se non chiami il file di distribuzione originale packagename_version.orig.tar.gz, 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 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 PGP, 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 e se i numeri non corrispondessero saprebbe che il file relativo è corrotto, o è stato alterato. 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. Controllare il pacchetto per errori

Lancia sul tuo file .changes; questo programma fa una verifica in merito a molti comuni errori di pacchettizzazione. Il comando è:

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 . 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)

Osserva che puoi costruire il pacchetto con .

Guarda all'interno del pacchetto usando un file manager come , o spacchettalo in una posizione temporanea usando . Stai in guardia per file extra non necessari nel pacchetto binario e sorgente. Spesso un po' di robaccia non viene cancellata propriamente; modifica le tue regole per compensare questa cosa. Suggerimento: `zgrep ^+++ ../gentoo_0.9.12-1.diff.gz' ti darà una lista di modifiche/aggiunte ai file sorgenti, e `dpkg-deb -c gentoo_0.9.12-1_i386.deb' elencherà tutti i file nel pacchetto.

Installa il pacchetto per testarlo tu stesso, per esempio usando il comando 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. 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 .

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 o . Descriveremo come puoi farlo con 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 = "ftp-master"; $cfg{"ftp-master"}{"login"} = "yourdebianusername"; $cfg{"non-us"}{"login"} = "yourdebianusername"; 1;

Ovviamente, modifica le mie informazini personali con le tue, e leggi la pagina man per capire cosa significa ciascuna opzione.

L'opzione $default_host è la più particolare -- stabilisce quale coda di caricamento sarà usata per default. "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/developers-reference.html/ch-upload.en.html#s-uploading

A questo punto connettiti al tuo provider Internet, e scrivi questo comando:

dupload --to master gentoo_0.9.12-1_i386.changes

, per caricare appropriatamente il pacchetto.

Se carichi su "ftp-master", Aggiornamento del pacchetto 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 <version>-<revision>` 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 , , e . La differenza è che questa volta il sorgente originale non sarà incluso, dal momento che non è stato modificato e già esiste nell'archivio Debian. Nuovo rilascio di upstream

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. ~/debian/). 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. 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 , , e .

Osserva che se hai configurato il file `debian/watch' come descritto in , puoi lanciare per cercare automaticamente i sorgenti aggiornati, scaricarli e lanciare 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.

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. 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, i file /usr/share/doc/package/* e e le pagine man/info di tutti i programmi menzionati in questo documento.

Se hai domande sulla pacchettizzazione alle quale non trovi risposta nella documentazione, puoi chiedere alla mailing list dei Debian Mentors su Guarda 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 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/developers-reference.html/ch-bug-handling.en.html

Se ancora hai delle domande, chiedi sulla mailing list degli sviuppatori Debian all'indirizzo 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!