trunk/maint-guide/maint-guide.it.sgml

<!doctype debiandoc system>

<debiandoc>

 <book>

  <titlepag>

   <title>Guida per il nuovo Maintainer</title>

   <author>Josip Rodin <email/jrodin@jagor.srce.hr/
   </author>
   <author>Traduzione: Francesco P. Lovergine <email/frankie@debian.org/
   </author>

   <version>versione 1.2, 6 Aprile 2002.</version>

   <copyright>
   <copyrightsummary>Copyright &copy; 1998-2002 Josip Rodin.</copyrightsummary>

   <p>Questa guida può essere utilizzata nei termini della GNU General Public License
   versione 2 o successive.

   <p>Questo documento è stato realizzato utilizzando come modello i documenti seguenti:

   <p>Making a Debian Package (noto come Manuale di Debmake), copyright &copy;
   1997 Jaldhar Vyas.

   <p>The New-Maintainer's Debian Packaging Howto, copyright &copy; 1997
   Will Lowe.
   </copyright>

  </titlepag>

  <toc sect>

  <chapt id="start">Partire "nel modo giusto"

  <p>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 <em> Longum iter est per preaecepta, breve 
  et efficax per exempla!</em> (La via è lunga usando la teoria, 
  ma breve ed efficiente con gli esempi!).

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

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

  <p>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à.
  
  <p>Versioni aggiornate di questo documento dovrebbero sempre essere
  disponibili all'indirizzo
  <url name="http://www.debian.org/doc/maint-guide/" id="http://www.debian.org/doc/maint-guide/">
  e nel pacchetto `<package/maint-guide/'.
  La traduzione in italiano è anche disponibile nel pacchetto `<package/maint-guide-it/'.

  <sect id="needprogs">Programmi necessari per lo sviluppo

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

  <p>Questa revisione del documento è stata aggiornata per i 
  pacchetti in Debian 2.2 (`potato') and 3.0 (`woody').

  <p>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 &lt;package&gt;'.

  <list>
  <item><package/dpkg-dev/ - questo pacchetto contiene gli 
  strumenti necessari per spacchettare, creare e caricare i pacchetti
  sorgenti Debian. (vedi
  <manref name="dpkg-source" section="1">)

  <item><package/file/ - questo comodo programma può stabilire la
  tipologia di un file.
  (vedi <manref name="file" section="1">)

  <item><package/gcc/ - il compilatore GNU C, necessario se il tuo programma
  come molti altri è scritto nel linguaggio di programmazione C. 
  (vedi <manref name="gcc" section="1">,
  Questo pacchetto caricherà anche un gruppo di altri pacchetti come
  <package/binutils/ che include programmi usati per assemblare e
  linkare file oggetto (vedi `info binutils` nel pacchetto 
  <package/binutils-doc/)
  e <package/cpp/, il preprocessore C. 
  (vedi <manref name="cpp" section="1">)

  <item><package/g++/ - il compilatore GNU C++, necessario se il tuo 
  programma è scritto in C++. (vedi <manref name="g++" section="1">).

  <item><package/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 <package/glibc-doc/)

  <item><package/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`) 

  <item><package/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 <manref name="patch" section="1">)

  <item><package/perl/ - Perl è uno dei linguaggi per script
  interpretati più utilizzati sui moderni sistemi simil-Unix, spesso definito
  come "il coltellino svizzero di Unix". 
  (vedi <manref name="perl" section="1">)
  </list>

  <p>Probabilmente vorrai installare i pacchetti seguenti, anche:
  
  <list>

  <item><package/autoconf/ e <package/automake/ - molti programmi
  nuovi usano script di configurazione e Makefile preprocessati
  con l'aiuto di programmi come questi. (vedi `info autoconf`, `info automake`)
  
  <item><package/dh-make/ e <package/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 <strong>altamente</strong> raccomandati
  per i nuovi maintainer. Questo rende l'intero processo molto più
  semplice da iniziare e controllare successivamente. (vedi
   <manref name="dh_make" section="1">,
  <manref name="debhelper" section="1">, /usr/share/doc/debhelper/README)

  <item><package/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)

  <item><package/fakeroot/ - questa programma di utilità permette di emulare i
  privilegi di root necessari per alcune parti del processo di creazione.
  (vedi <manref name="fakeroot" section="1">)

  <item><package/gnupg/ - un programma che ti consente di <em>firmare</em>
  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 <manref name="gpg" section="1">)

  <item><package/g77/ - il compilatore GNU Fortran 77, necessario se il
  tuo programma è scritto in Fortran. (vedi <manref name="g77" section="1">)
  
  <item><package/gpc/ - il compilatore GNU Pascal, necessario se il tuo
  programma è scritto in Pascal. Degno di nota qui è <package/fp-compiler/,
  il Compilatore Free Pascal, che è anche adatto a questo compito.
  (vedi <manref name="gpc" section="1">, <manref name="ppc386" section="1">)

  <item><package/imake/ e <package/xmkmf/ - alcuni programmi, generalmente
  quelli fatti per X11, usano anche questi programmi per generare i Makefile
  da insiemi di macro funzioni. (vedi <manref name="imake" section="1">,
    <manref name="xmkmf" section="1">)
  
  <item><package/lintian/ - questo è il verificatore dei pacchetti Debian,
  che permette di scoprire errori comuni dopo la costruzione del
  pacchetto e spiega gli errori trovati. (vedi
  <manref name="lintian" section="1">, 
  /usr/share/doc/lintian/lintian.html/index.html)
  </list>

  <p>Quanto segue è la documentazione <em>molto importante</em> 
  che dovresti leggere insieme a questo documento:

  <list>
  <item><package/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)

  <item><package/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, quando e dove fare i caricamenti, ecc.
  (vedi /usr/share/doc/developers-reference/developers-reference.html/index.html)
  </list>

  <p>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 <em>lietissimo</em> di averlo fatto.
  
  Nota: <package/debmake/ è un pacchetto che contiene alcuni programmi
  con funzioni simile a dh-make, ma il suo specifico uso
  <strong>non</strong> è illustrato in questo documento, perchè il suo
  uso è <em>sconsigliato</em>.
  Si rimanda al <url name="manuale di Debmake"
  id="http://www.debian.org/~jaldhar/"> per maggiori informazioni.

  <sect id="otherinfo">Altre informazioni

  <p>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.
  
  <p>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.
  
  <p>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.
  
  <chapt id="first">Primi passi

  <sect id="choose">Scegli il tuo programma

  <p>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
  <url name="pagina di ricerca dei pacchetti" id="http://www.debian.org/distrib/packages">.
  Se usi la <strong>corrente</strong> distribuzione `instabile', verificalo
  con i comandi:
  <example>
  dpkg -s program
  dpkg -l '*program*'
  </example>

  <p>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
  <url name="lista dei pacchetti orfani" id="http://www.debian.org/devel/wnpp/orphaned">
  e
  <url name="la lista dei pacchetti in adozione" id="http://www.debian.org/devel/wnpp/rfa_bypackage">
  per verificare che il pacchetto sia effettivamente disponibile.

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

  <list>
  <item>consulta la <url name="la lista dei pacchetti sui quali si lavora" id="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.
  </item>

  <item>il programma <strong>deve</strong> avere una licenza, 
  se possibile free, in accordo con le 
  <url name="Linee Guida per il Software Libero Debian" id="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 <email/debian-legal@lists.debian.org/.
  </item>

  <item>il programma in questione certamente <strong>non</strong> 
  dovrebbe girare come setuid root, o anche meglio, non dovrebbe richiedere di essere
  setuid o setgid a nessun utente.</item>

  <item>il programma non dovrebbe essere un daemon, o qualcosa che 
  debba essere installato nelle directory */sbin, o aprire una porta
  come root.
  </item>

  <item>il programma dovrebbe essere in forma di binario eseguibile,
  le librerie sono più difficili da gestire.
  </item>

  <item>dovrebbe essere ben documentato, o almeno comprensibile (cioè
  non confuso).
  </item>

  <item>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. 
  </item>

  <item>infine, cosa non meno importante, dovresti essere sicuro che
  il programma funziona e averlo provato per un po'.
  </item>
  </list>

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

  <p>Per maggiori informazioni su queste cose, consulta la Guida di 
  Riferimento per lo Sviluppatore.

  <sect id="getit">Prendi il programma e provalo

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

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

  <p>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.
  
  <p>A questo punto hai un'altra sottodirectory, dal nome
  `gentoo-0.9.12'. Spostati sotto tale directory e leggi
  <strong>approfonditamente</strong> 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 <ref id="destdir">).

  <p>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'.
  
  <p>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.
  
  <p>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.

  <sect id="namever">Nome del pacchetto e versione

  <p>Dovresti iniziare la pacchettizzazione con una directory di
  sorgenti completamente ripulita, o semplicemente partendo da una
  nuova scompattazione dei sorgenti.

  <p>Per costruire correttamente il pacchetto, dovresti modificare il nome
  del programma originale in minuscolo (se già non lo fosse), e
  rinominare la directory in &lt;pacchetto&gt;-&lt;versione&gt;.
  
  <p>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.

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

  <sect id="dh_make">La "debianizzazione" iniziale

  <p>Assicurati di trovarti nella directory dei sorgenti del programma 
  e lancia il comando seguente:

  <p><example>
  dh_make -e tuo.maintainer@indirizzo -f ../gentoo-0.9.12.tar.gz
  </example>

  <p>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 <manref name="dh_make" section="1"> per dettagli.
 
  <p>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 &lt;invio&gt;. 
    
  <p>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.
    
  <p>Osserva che dovresti lanciare dh_make <strong>una sola volta</strong>,
  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 <ref id="update"> 
  
  <chapt id="modify">Modificare i sorgenti

  <p>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 <manref name="make" section="1"> per
  creare automaticamente il programma. Per maggiori dettagli sui
  Makefile dai una occhiata a <ref id="rules">.

  <p>Osserva che se il tuo programma utilizza l'utilità GNU
  <manref name="automake" section="1">
  e/o <manref name="autoconf" section="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.
  
  <p>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.
  
  <sect id="destdir">Installazione in una sotto-directory

  <p>
  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.
  
  <p>Perciò dovrai fare qualcosa di diverso: 
  installa il programma in una sotto-directory temporanea 
  dalla quale dli 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.

  <p>Questa directory temporanea è generalmente creata sotto la tua
  directory debian/ nell'albero dei sorgenti spacchettato. Si chiama
  generalmente <file>debian/tmp</file> oppure 
  <file>debian/nomepacchetto</file>.

  <p>
  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 
  <tt>/home/me/deb/gentoo-0.9.12/usr/share/gentoo</tt> 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.
  
  <p>Questa è la parte rilevante del Makefile di gentoo:

  <p><example>
  # Where to put binary on 'make install'?
  BIN     = /usr/local/bin

  # Where to put icons on 'make install'? 
  ICONS   = /usr/local/share/gentoo/
  </example>

  <p>Osserva che il file sono configurati per installare sotto 
  <file>/usr/local</file>. Modifica questi percorsi in:

  <p><example>
  # Where to put binary on 'make install'?
  BIN     = $(DESTDIR)/usr/bin

  # Where to put icons on 'make install'?
  ICONS   = $(DESTDIR)/usr/share/gentoo
  </example>

  <p>Ma perchè in quella directory, e non altrove? Perchè i pacchetti
  Debian non installano mai file sotto <file>/usr/local</file> -- quella
  gerarchia è riservata all'uso dell'amministratore di sistema.
  Tali file in sistemi Debian vanno invece posti sotto <file>/usr</file>.

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

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

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

  <p>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:

  <p><example>
  grep -rn usr/local/lib *.[ch]
  </example>
  
  <p>Grep eseguirà ricorsivamente sull'albero dei sorgenti e ti dirà
  il nome di un  file e la riga in esso quando trova una occorrenza.

  <p>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! :-)
  
  <p>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:

  <p><example>
  install:        gentoo
                  install ./gentoo $(BIN)
                  install icons $(ICONS)
                  install gentoorc-example $(HOME)/.gentoorc
  </example>

  <p>Dopo la modifica invece:
  <example>
  install:        gentoo-target
                  install -d $(BIN) $(ICONS) $(DESTDIR)/etc
                  install ./gentoo $(BIN)
                  install -m644 icons/* $(ICONS)
                  install -m644 gentoorc-example $(DESTDIR)/etc/gentoorc
  </example>

  <p>Avrai sicuramente notato che c'è adesso un comando
  <tt>install -d</tt> 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.

  <p>Possiamo anche aggiungere altre cose alla fine della regola, come
  l'installazione di documentazione che l'autore upstream talvolta
  omette:

  <p><example>
                    install -d $(DESTDIR)/usr/share/doc/gentoo/html
                    cp -a docs/* $(DESTDIR)/usr/share/doc/gentoo/html
  </example>
  
  <p>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 :-)

  <p>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.
  
  <sect id="difflibs">Distinguere le librerie

  <p>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. 
  
  <p>Così, se c'è una riga nel Makefile del programma (o nel
  Makefile.in) che dice qualcosa del tipo (e il programma non compila):

  <p><example>
  LIBS = -lcurses -lsomething -lsomethingelse
  </example>

  <p>Modificala come segue, e molto probabilmente funzionerà:
  <p><example>
  LIBS = -lncurses -lsomething -lsomethingelse
  #LIBS = -lcurses -lsomething -lsomethingelse
  </example>

  <p>(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 :-)

  <chapt id="dreq">Materiale richiesto sotto debian/

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

  <sect id="control">Il file `control' 

  <p>Questo file contiene vari valori che <prgn/dpkg/,  <prgn/dselect/ e
  altri pacchetti useranno per la gestione del pacchetto. 
  
  <p>Questo è il file control che dh_make crea per noi.

  <p><example>
  1  Source: gentoo
  2  Section: unknown
  3  Priority: optional
  4  Maintainer: Josip Rodin &lt;jrodin@jagor.srce.hr&gt;
  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: &lt;insert up to 60 chars description&gt;
  12  &lt;insert long description, indented with spaces&gt;
  </example>
  (I numeri di riga sono aggiunti).

  <p>Le righe 1-6 sono le informazioni di controllo per il pacchetto 
  sorgente. 
  
  <p>La riga 1 è il nome del pacchetto sorgente.

  <p>La riga 2 è la sezione della distribuzione in cui il pacchetto è
  incluso. 
  
  <p>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.

  <p>Modifichiamo quindi la sezione in x11. (Un prefisso "main/" è implicito
  per cui lo omettiamo.)

  <p>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.
  
  <p>Sezioni e priorità sono usati effettivamente solo da <prgn/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.
  
  <p>Dal momento che si tratta di un pacchetto a priorità normale,
  lasciamo il campo al valore "optional".

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

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

  <p>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 <package/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.
  
  <p>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.

  <p>Ecco un trucco che puoi usare per trovare quali pacchetti il tuo
  pacchetto richiede per la creazione:
  <example>
  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
  </example>

  <p>Gentoo sembra richiedere <package/xlibs-dev/,
  <package/libgtk1.2-dev/ e <package/libglib1.2-dev/ per compilare,
  per cui li aggiungiamo dopo <package/debhelper/.
  
  <p>La riga 8 è il nome del pacchetto binario. Questo è generalmente lo
  stesso nome del sorgente, ma non deve necessariamente essere così.

  <p>La riga 9 descrive l'architettura di CPU per la quale il pacchetto
  binario è stato compilato. Possiamo lasciare il valore "any" perché 
  <manref name="dpkg-gencontrol" section="1"> lo riempirà con il valore
  appropriato per qualsiasi macchina sulla quale questo pacchetto è
  stato compilato. 
  
  <p>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 <ref id="rules"> sull'uso del metodo `binary-indep'
  invece di `binary-arch' per costruire un pacchetto.
  
  <p>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:.

  <p>Gli strumenti di gestione dei pacchetti generalmente si comportano 
  nello stesso modo quando trattano queste relazioni; se così non è, viene spiegato.
  (vedi <manref name="dpkg" section="8">, <manref name="dselect" section="8">,
  <manref name="apt" section="8">, <manref name="aptitude" section="1"> ecc.)

  <p>Questo è ciò che le dipendenze significano:

  <p><list>
  <item>Depends:
  <p>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.</item>

  <item>Recommends:
  <p>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.</item>

  <item>Suggests:
  <p>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. </item>

  <item>Pre-Depends:
  <p>Questo è più stringente di Depends:. Il pacchetto non sarà
  installato a meno che i pacchetti da cui pre-dipende non siano
  installati e  <em>correttamente configurati</em>. Usa questo valore
  con  <strong>molta</strong> prudenza, e solo dopo averne discusso
  nella mailing list debian-devel. Leggi: non usarlo affatto. :-)</item>

  <item>Conflicts:
  <p>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.</item>
  
  <item>Provides:
  <p>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 .</item>

  <item>Replaces:
  <p>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.
  </item>
  </list>

  <p>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 <tt>|</tt> (simbolo di pipe). 
  
  <p>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:  <tt>&lt;&lt;</tt>,
  <tt>&lt;=</tt>, <tt>=</tt>, <tt>&gt;=</tt> e
    <tt>&gt;&gt;</tt> che stanno per strettamente precedente, precedente
    o uguale, esattamente uguale, successiva o uguale, e strettamente
    successiva, rispettivamente. Per esempio,

  <p><example>
    Depends: foo (>= 1.2), libbar1 (= 1.3.4)
    Conflicts: baz
    Recommends: libbaz4 (>> 4.0.7)
    Suggests: quux
    Replaces: quux (<< 5), quux-foo (<= 7.6)
  </example>
  
  <p>L'ultima caratteristica che hai necessità di conoscere è
  $(shlibs:Depends). Dopo che il tuo pacchetto sarà stato generato
  e installato nella directory temporanea,
  <manref name="dh_shlibdeps" section="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 <manref name="dh_gencontrol" section="1">
  che li metterà al posto giusto, e tu non dovrai preoccuparti di specificarle
  da solo.

  <p>Detto ciò possiamo lasciare la riga Depends: come è ora, e inserire
  un'altra riga dopo questa che dice <tt>Suggests: file</tt>,
  perchè gentoo può usare alcune funzionalità offerte da quel 
  programma/pachetto.
  
  <p>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+".
  
  <p>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.
  
  <p>Questo è il file control aggiornato:

  <p><example>
  1  Source: gentoo
  2  Section: x11
  3  Priority: optional
  4  Maintainer: Josip Rodin &lt;jrodin@jagor.srce.hr&gt;
  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).
  </example>
  (Ho aggiunto i numeri di riga.)

  <sect id="copyright">Il file `copyright'

  <p>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"). 
  
  <p>dh_make ne ha creato uno di default, quello di seguito:

  <p><example>
  1  This package was debianized by Josip Rodin &lt;jrodin@jagor.srce.hr&gt; on
  2  Wed, 11 Nov 1998 21:02:14 +0100.
  3
  4  It was downloaded from &lt;fill in ftp site&gt;
  5
  6  Upstream Author(s): &lt;put author(s) name and email here&gt;
  7
  8  Copyright:
  9
  10 &lt;Must follow here&gt;
  </example>
  (Ho aggiunto i numeri di riga.)

  <p>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. 
  
  <p>In breve, ecco come il file copyright di gentoo appare:

  <p><example>
  1  This package was debianized by Josip Rodin &lt;jrodin@jagor.srce.hr&gt; 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 &lt;emil@obsession.se&gt;
  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.
  </example>
  (Ho aggiunto i numeri di riga.)

  <sect id="changelog">Il file `changelog'

  <p>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.
  
  <p>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.
  
  <p>dh_make ne crea uno di default, che appare così:

  <p><example>
  1  gentoo (0.9.12-1) unstable; urgency=low
  2
  3   * Initial Release.
  4
  5  -- Josip Rodin &lt;jrodin@jagor.srce.hr&gt; Wed, 11 Nov 1998 21:02:14 +0100
  6
  7  Local variables:
  8  mode: debian-changelog
  9  End:
  </example>
  (Ho aggiunto i numeri di riga.)

  <p>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'. :-).

  <p>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 <manref name="dch" section="1">, <manref
  name="emacs" section="1"> o a mano con un editor di testo. 
  
  <p>Devi metterci qualcosa di questo genere:
  
  <p><example>
  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 &lt;jrodin@jagor.srce.hr&gt; Wed, 11 Nov 1998 21:02:14 +0100
  8
  </example>
  (Ho aggiunto i numeri di riga.)

  <p>Puoi leggere altro sull'aggiornamento del file changelog più oltre 
  in <ref id="update">.

  <sect id="rules">Il file `rules'

  <p>Ora occorre dare una occhiata alle regole esatte che 
  <manref name="dpkg-buildpackage" section="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.
  
  <p>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  &lt;tab&gt;!), 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

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

  <p>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.
  
  <p>Ecco (approssimativamente) come appare il file di default debian/rules
  che dh_make ha generato:

  <p><example>
  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
  </example>
  (Ho aggiunto i numeri di riga.)

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

  <p>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 <manref name="debhelper" section="1">pagina di manuale.
  
  <p>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.
  
  <p>Generalmente puoi dire al gcc di compilare con "-g" usando la
  variabile CFLAGS -- se questo è il caso del tuo pacchetto, propaga
  la variabile <em>aggiungendo</em> <tt>CFLAGS="$(CFLAGS)"</tt> alla
  chiamata $(MAKE) nella regola build (vedi oltre). In alternativa,
  se il tuo pacchetto usa uno script configure di autoconf, puoi passarlo
  a configure <em>premettendo</em> la suddetta stringa alla invocazione
  di ./configure nella regola di build.

  <p>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 <manref name="dh_strip" section="1"> che controllerà se
  il flag DEB_BUILD_OPTIONS=nostrip è configurato e terminerà 
  silenziosamente.
  
  <p>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 <ref id="manpage">.
  
  <p>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 <em/è/ 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.
  
  <p>Il processo di installazione, la regola `install', inizia a riga 38.
  Fondamentalmente lancia la regola `install' del Makefile del programma,
  ma installa nella directory <tt>$(CURDIR)/debian/gentoo</tt> - 
  questo è il motivo per cui abbiamo
  specificato $(DESTDIR) come directory radice per l'installazione nel
  Makefile di gentoo.
  
  <p>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. 
  
  <p>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.
  
  <p>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.
  
  <p>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:
  
  <list>
  <item><manref name="dh_testdir" section="1"> controlla di trovarsi 
        nella giusta directory (cioè la directory superiore dei
        sorgenti),
  <item><manref name="dh_testroot" section="1"> controlla che tu abbia
        i privilegi di root che sono necessari per i target  `binary-arch',
        `binary-indep' e 'clean',
  <item><manref name="dh_installman" section="1"> 
        copia tutte le pagine di man al posto giusto nella directory
        destinazione, devi solo dirgli dove sono relativamente alla
        directory superiore dei sorgenti,
  <item><manref name="dh_strip" section="1">
        elimina le intestazioni per il debugging dagli eseguibili e
        librerie, per renderli più piccoli,
  <item><manref name="dh_compress" section="1"> comprime pagine di 
        man e documentazioni più grandi di 4kB con <manref name="gzip" section="1">,
  <item><manref name="dh_installdeb" section="1"> copia i file legati
        al pacchetto (per es. gli script da maintainer) sotto la 
        directory <file>debian/gentoo/DEBIAN</file>,
  <item><manref name="dh_shlibdeps" section="1"> calcola le dipendenze
        da librerie condivise di librerie ed eseguibili,
  <item><manref name="dh_gencontrol" section="1"> installa una versione
        modificata del file di controllo in <file>debian/gentoo/DEBIAN</file>,
  <item><manref name="dh_md5sums" section="1"> genera i codici di
        controllo MD5 per tutti i file del pacchetto.
  </list>

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

  <p>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.
  
  <chapt id="dother">Altri file sotto debian/

  <p>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à:
   
  <list>
        <item>esamina la documentazione relativa (suggerimento: il Policy Manual),
        <item>se necessario modifica i file per adattarli alle tue necessità,
        <item>rinominali per eliminare il suffisso `.ex' se ne hanno uno, 
        <item>modifica il file rules se necessario.
  </list>
  
  <p>Alcuni di questi file, quelli più comunemente usati, sono
  spiegati nelle sezioni seguenti.
  
  <sect id="readme">README.Debian

  <p>Qualsiasi dettaglo extra o discrepanza fra il pacchetto originale
  e la versione debianizzata, deve essere documentata qui. 
  
  <p>dh_make ne crea uno di default, che appare come segue:

  <example>
  gentoo for Debian
  ----------------------

  &lt;possible notes regarding this package - if none, delete this file&gt;

   -- Josip Rodin &lt;jrodin@jagor.srce.hr&gt;, Wed, 11 Nov 1998 21:02:14 +0100
  </example>

  <p>Poiché non dobbiamo aggiungere niente qui, cancelleremo questo file.

  <sect id="conffiles">conffiles.ex

  <p>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. 
  
  <p>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 <tt/conffiles/. Gentoo ha un file di configurazione, /etc/gentoorc, 
  e lo inseriremo nel file <tt/conffiles/. 

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

  <p>Puoi gestire degli esempi di configurazione dagli `script del
  maintainer', per maggiori informazioni vedi <ref id="maintscripts">.

  <p>Se il tuo programma non ha conffiles, puoi in tutta sicurezza
  cancellare il file <tt/conffiles/ dalla directory debian/.

  <sect id="crond">cron.d.ex

  <p>Se il tuo pacchetto richiede che compiti regolarmente schedulati
  siano svolti in modo appropriato, puoi usare questo file per configurarli.

  <p>Nota che questo non include la rotazione dei log; per quello
  guarda <manref name="dh_installlogrotate" section="1"> e
  <manref name="logrotate" section="8">.

  <p>In caso contrario rimuovilo.

  <sect id="dirs">dirs

  <p>Questo file specifica le directory che occorrono, ma che la normale 
  procedura di installazione (make install), per qualche motivo, non crea.

  Per default, contiene:
  <p><example>
  usr/bin
  usr/sbin
  </example>

  <p>Osserva che lo slash prefisso non è incluso. Cambieremo normalmente
  tale file come segue:

  <p><example>
  usr/bin
  usr/man/man1
  </example>
  
  <p>ma queste directory sono già create nel Makefile, per cui non ci serve
  tale file, e lo cancelleremo.

  <sect id="docs">docs
  
  <p>Questo file specifica i nomi dei file di documentazione che possiamo
  far installare a dh_installdocs nella directory temporanea per noi.

  <p>Per default, includerà tutti i file esistenti nella directory 
  principale dei sorgenti che si chiamano "BUGS", "README*", "TODO", ecc.

  <p>Per gentoo, ho incluso anche qualcos'altro:

  <p><example>
  BUGS
  CONFIG-CHANGES
  CREDITS
  ONEWS
  README
  README.gtkrc
  TODO
  </example>

  <p>Possiamo anche rimuovere questo file e invece elencare quei file
  sulla riga di comando di <tt/dh_installdocs/ nel file  <tt/rules/,
  in questo modo:

  <p><example>
          dh_installdocs BUGS CONFIG-CHANGES CREDITS ONEWS README \
                         README.gtkrc TODO
  </example>
  
  <p>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 <tt/dh_installdocs/ nel file <tt/rules/ 
  perchè è usata per installare il file <tt/copyright/ e altre cose.
  
  <sect id="emacsen">emacsen-*.ex

  <p>Se il tuo pacchetto fornisce dei file Emacs che possono essere 
  compilati al momento della installazione, puoi usare questi file
  per configurarlo.

  <p>Sono installati nella directory temporanea da
  <manref name="dh_installemacsen" section="1">, per cui non dimenticare
  di decommentare quella riga nel file <tt/rules/ se lo usi.

  <p>Se non ti servono, rimuovili.
  
  <sect id="initd">init.d.ex

  <p>Se il tuo pacchetto è un daemon che richiede di essere lanciato
  alla partenza del sistema, hai ovviamente ignorato la mia 
  raccomandazione iniziale, vero? :-)

  <p>Questo è uno schema di file abbastanza generico per uno script
  da <file>/etc/init.d/</file>, per cui dovrai verosimilmente modificarlo
  parecchio. Viene installato nalla directory temporanea da 
  <manref name="dh_installinit" section="1">.
  
  <p>Se non ti serve, rimuovilo.

  <sect id="manpage">manpage.1.ex, manpage.sgml.ex


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

  <p>Le pagine di manuale sono normalmente scritte in 
  <manref name="nroff" section="1">. L'esempio <tt/manpage.1.ex/
  è scritto in nroff, anche.
  Vedi la pagina di manuale relativa a <manref name="man" section="7">,
  per una breve descrizione di come modificare tale file. 
  
  <p>Se d'altro canto preferisci scrivere in SGML invece che in nroff
  puoi usare lo schema in <tt/manpage.sgml.ex/. Se lo fai, devi:
  <list>
        <item>installare il pacchetto <package/docbook-to-man/
        <item>aggiungere <tt/docbook-to-man/ alla riga <tt/Build-Depends/
        nel file <tt/control/
        <item>rimuovere il commento dalla chiamata di docbook-to-man
        nella regola `build' del tuo file <tt/rules/
  </list>

  <p>E ricorda di rinominare il file in qualcosa tipo <tt/gentoo.sgml/!

  <p>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:
  
  <p><example>
  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
  </example>
  
  <p>Così la manpage di gentoo dovrebbe chiamarsi <tt/gentoo.1/.
  Per programmi per X puoi aggiungere una "x" alla sezione, cioè
  <tt/gentoo.1x/.
  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.
 
  <sect id="menu">menu.ex

  <p>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 <package/menu/, verrà creato un insieme di menu per ciascun
  programma del sistema. 
  
  <p>Questo è il file <tt/menu.ex/ che di default dh_make crea:
  
  <p><example>
  ?package(gentoo):needs=X11|text|vc|wm section=Apps/see-menu-manual\
    title="gentoo" command="/usr/bin/gentoo"
  </example>

  <p>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". 
  
  <p>Il successivo è "section", dove voce
  di menu e sottomenu dove dovrebbe apparire. L'elenco corrente delle
  sezioni si trova in:
  <file>/usr/share/doc/debian-policy/menu-policy.html/ch2.html#s2.1</file>
  
  <p>Il campo "title" è il nome del programma. Puoi iniziarlo in 
  maiuscolo se preferisci. Solo, mantienilo breve.
  
  <p>Infine, il campo "command" è la riga di comando
  che lancia il programma.
  
  <p>Adesso, cambieremo la voce di menu in questo:
  
  <p><example>
  ?package(gentoo):needs=X11 section=Apps/Tools \
    title="Gentoo" command="gentoo"
  </example>

  <p>Puoi anche aggiungere altri campi come "longtitle", "icon", "hints", ecc.
  <p>Vedi <manref name="menufile" section="5">, <manref name="update-menus" section="1">
  e <file>/usr/share/doc/debian-policy/menu-policy.html/</file> 
  per maggiori informazioni.

  <sect id="watch">watch.ex

  <p>Questo file è usato per configurare
  <manref name="uscan" section="1">
  e <manref name="uupdate" section="1"> (nel pacchetto <package/devscripts/)
  Sono usati per controllare il sito da dove hai recuperato il 
  sorgente originale.
  
  <p>Questo è quello che vi ho inserito:

  <p><example>
  # watch control file for uscan
  # Site                Directory       Pattern                 Version Script
  ftp.obsession.se      /gentoo         gentoo-(.*)\.tar\.gz    debian  uupdate
  </example>

  <p>Suggerimento: collegati a Internet, 
  e prova a eseguire "uscan" nella directory del programma, dopo avere
  creato il file. E leggi le pagine di manuale! :)

  <sect id="doc-base">ex.package.doc-base

  <p>Se il tuo pacchetto ha altra documentazione a
  parte le pagine man e i documenti info, dovresti usare il file
  `<package/doc-base/'
  per registrarle, in modo che l'utente possa trovarle, con
  <manref name="dhelp" section="1">, <manref name="dwww" section="1"> 
  o <manref name="doccentral" section="1">,
  per esempio.

  <p>Questo in genere include file HTML,PS e PDF, distribuiti in
  <file>/usr/share/doc/packagename/</file>.

  <p>Il file doc-base di gentoo appare come segue:

  <p><example>
  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
  </example>

  <p>Per informazioni sul formato del file, vedi 
  <manref name="install-docs" section="8">
  e il manuale di <package/doc-base/, 
  in <file>/usr/share/doc/doc-base/doc-base.html/</file>.

  <sect id="maintscripts">postinst.ex, preinst.ex, postrm.ex, prerm.ex

  <p>Questi file sono chiamati script del maintainer. Sono script posti
  nell'area di controllo del pacchetto e lanciati da <prgn/dpkg/ quando il 
  tuo pacchetto è installato, aggiornato o rimosso.

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

  <chapt id="build">Costruzione del pacchetto

  <p>A questo punto, dovresti essere pronto a creare il pacchetto.

  <sect id="completebuild">Costruzione completa
  
  <p>Spostati nella directory principale del programma e lancia il
  comando:

  <p><example>
  dpkg-buildpackage -rfakeroot
  </example>

  <p>Questo farà tutto il necessario per te.
  <list>
        <item>pulirà l'albero dei sorgenti (debian/rules clean), usando <prgn/fakeroot/
        <item>costuirà il pacchetto sorgente (dpkg-source -b)
        <item>costruirà il programma (debian/rules build)
        <item>costruirà il pacchetto binario (debian/rules binary), usando <prgn/fakeroot/
        <item>firmerà il file sorgente <tt/.dsc/, usando <prgn/gnupg/
        <item>creerà e firmerà il file di upload <tt/.changes/ usando
                <prgn/dpkg-genchanges/ e <prgn/gnupg/
  </list>
      
  <p>Il solo input da te richiesto è tua chiave PGP segreta, due volte. 
  
  <p>Fatto ciò, vedrai quattro nuovi
  file nella directory di cui sopra (<tt>~/debian/</tt>):   
  
  <p><list>
  <item><em>gentoo_0.9.12.orig.tar.gz</em>
  
  <p>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 <prgn/dh_make/ quando è stato inizialmente lanciato.
  
  <item><em>gentoo_0.9.12-1.dsc</em>
  
  <p>È un sommario del contenuto del codice sorgente. Questo file è
  generato dal tuo file `control', ed è usato
  quando si scompatta il sorgente con  <manref name="dpkg-source"
  section="1">. Questo file è firmato con PGP, in modo che si possa 
  essere sicuri che effettivamente è fatto da te. 
  
  <item><em>gentoo_0.9.12-1.diff.gz</em>
  
  <p>Questo file compresso contiene ogni singola modifica fatta al
  codice sorgente originale, in una forma nota come "diff unificata".
  Viene creata e usata da <manref name="dpkg-source" section="1">.
  Attenzione: se non chiami il file di distribuzione originale 
  packagename_version.orig.tar.gz, <prgn/dpkg-source/ non riuscirà
  a creare il file .diff.gz correttamente!

  <p>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 <tt>dpkg-source -x gentoo_0.9.12-1.dsc</tt>.

  <item><em>gentoo_0.9.12-1_i386.deb</em>

  <p>Questo è il pacchetto binario completo. Puoi usare <prgn/dpkg/
  per installarlo e rimuoverlo, come per ogni altro pacchetto.

  <item><em>gentoo_0.9.12-1_i386.changes</em>
  
  <p>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.

  <p>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.
  </list>
  
  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 <manref
  name="md5sum" section="1"> e se i numeri non corrispondessero
  saprebbe che il file relativo è corrotto, o è stato alterato. 

  <sect id="quickrebuild">Ricostruzione veloce

  <p>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:
  
  <p><example>
  fakeroot debian/rules binary
  </example>

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

  <sect id="checkit">Controllare il pacchetto per errori

  <p>Lancia <manref name="lintian" section="1"> sul tuo file .changes;
  questo programma fa una verifica in merito a molti comuni errori di
  pacchettizzazione. Il comando è:
  
  <p><example>
  lintian -i gentoo_0.9.12-1_i386.changes
  </example>
  
  <p>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 <ref id="completebuild">.  
  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) 
  
  <p>Osserva che puoi costruire il pacchetto con <prgn/dpkg-buildpackage/ e
  <prgn/lintian/ in un unico comando con <manref name="debuild"
  section="1">.

  <p>Guarda all'interno del pacchetto usando un file manager come 
  <manref name="mc" section="1">, o spacchettalo in una posizione
  temporanea usando <manref name="dpkg-deb" section="1">.
  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.
  
  <p>Installa il pacchetto per testarlo tu stesso, per esempio usando il
  comando <manref name="debi" section="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.

  <sect id="upload">Caricamento del pacchetto

  <p>Una volta testato il nuovo pacchetto approfonditamente, 
  sarai pronto a partire con il processo di candidatura come nuovo
  maintainer Debian, come descritto in 
  <url id="http://www.debian.org/devel/join/newmaint">.

  <p>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
  <manref name="dupload" section="1"> o <manref name="dput" section="1">.
  Descriveremo come puoi farlo con  <prgn/dupload/.
  
  <p>Per prima cosa devi creare il file di configurazione di dupload.
  Puoi modificare il file di sistema <file>/etc/dupload.conf</file>
  o averne uno tuo personale <file>~/.dupload.conf</file>
  che fornisce le poche cose da modificare. Scrivici dentro qualcosa come:

  <p><example>
  package config;

  $default_host = "ftp-master";

  $cfg{"ftp-master"}{"login"} = "yourdebianusername";

  $cfg{"non-us"}{"login"} = "yourdebianusername";

  1;
  </example>

  <p>Ovviamente, modifica le mie informazini personali con le tue, e 
  leggi la pagina man <manref name="dupload.conf" section="5"> per
  capire cosa significa ciascuna opzione.

  <p>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
  <file>/usr/share/doc/developers-reference/developers-reference.html/ch-upload.en.html#s-uploading</file>

  <p>A questo punto connettiti al tuo provider Internet, e scrivi
  questo comando:
  
  <p><example>
  dupload --to master gentoo_0.9.12-1_i386.changes
  </example>

  <p><prgn/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 
  <ref id="completebuild">, per caricare appropriatamente il pacchetto.

  <p>Se carichi su "ftp-master", <prgn/dupload/
  ti chiederà la tua password per le macchine Debian, e quindi caricherà 
  il pacchetto.

  <chapt id="update">Aggiornamento del pacchetto

  <sect id="newrevision">Nuova revisione Debian

  <p>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:

  <list>
  <item>Correggere il problema nel pacchetto sorgente, ovviamente.

  <item>Aggiungere una nuova revisione nel file changelog Debian, per
  esempio con `dch -i', oppure esplicitamente con 
  `dch -v &lt;version&gt;-&lt;revision&gt;` e quindi
  includere i tuoi commenti usando il tuo editor preferito,

  <p>Suggerimento: come ottenere la data facilmente nel formato
  richiesto? Usa `822-date`, or `date -R`.

  <p>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.
  
  <item>Ripeti quanto fatto in <ref id="completebuild">, <ref id="checkit">,
  e <ref id="upload">. La differenza è che questa volta il sorgente
  originale non sarà incluso, dal momento che non è stato modificato
  e già esiste nell'archivio Debian.
  </list>

  <sect id="newupstream">Nuovo rilascio di upstream
  
  <p>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:
  
  <list>
  <item>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/).

  <item>Spostati nella vecchia directory di sorgenti e lancia:

  <example>
  uupdate -u gentoo-0.9.13.tar.gz
  </example>

  <p>Ovviamente, sostituisci questo nome di file con il nome
  dell'archivio dei sorgenti del tuo programma.  
  <manref name="uupdate" section="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.

  <item>Portati nella directory `../gentoo-0.9.13', il nuovo albero
  di sorgenti del pacchetto, e ripeti quanto fatto in 
  <ref id="completebuild">, <ref id="checkit">, e <ref id="upload">.
  </list>

  <p>Osserva che se hai configurato il file `debian/watch' come descritto
  in <ref id="watch">, puoi lanciare <manref name="uscan" section="1"> 
  per cercare automaticamente i sorgenti aggiornati, scaricarli e
  lanciare <prgn/uupdate/.

  <sect id="upgrading">Verificare gli aggiornamenti di pacchetti

  <p>Quando crei una nuova versione del pacchetto, dovresti fare
  quanto segue per verificare che il pacchetto può essere 
  aggiornato in modo sicuro:

  <list>
        <item>aggiorna dalla versione precedente,
        <item>torna indietro e rimuovilo,
        <item>installa il nuovo pacchetto,
        <item>rimuovilo e reinstallalo nuovamente,
        <item>fanne un purge.
  </list>

  <p>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.
  
  <sect id="helpme">Dove chiedere aiuto

  <p>Prima di deciderti a fare una domanda in qualche area pubblica,
  sei pregato di leggere i dannati manuali (RTFM). 
  Questo include la documentazione in 
   <file>/usr/share/doc/dpkg</file>,
   <file>/usr/share/doc/debian</file>, i file
   <file>/usr/share/doc/package/*</file> e
  e le pagine man/info di tutti i programmi menzionati in questo documento.

  <p>Se hai domande sulla pacchettizzazione alle quale non trovi risposta
  nella documentazione, puoi chiedere alla mailing list dei Debian Mentors
  su  <email/debian-mentors@lists.debian.org/. Gli sviluppatori più esperti
  di Debian ti aiuteranno con piacere, ma leggi almeno un po' di
  documentazione prima di chiedere!

  <p>Guarda <url id="http://lists.debian.org/debian-mentors/"> per
  maggiori informazioni riguardo la mailing list.
  
  <p>Quando ricevi una segnalazione di bug (sì, effettive segnalazioni
  di bug!) saprai che è il momento di fare fare riferimento al
  <url name="Sistema Debian di tracciamento dei bug" id="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
  <file>/usr/share/doc/developers-reference/developers-reference.html/ch-bug-handling.en.html</file>
  
  <p>Se ancora hai delle domande, chiedi sulla mailing list degli 
  sviuppatori Debian all'indirizzo
  <email/debian-devel@lists.debian.org/. 
  Guarda  <url id="http://lists.debian.org/debian-devel/">
  per maggiori informazioni su questa mailing list.

  <p>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 :-)

  <p>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 <em>documentazione reale</em> per i dettagli).
  Buona fortuna!
  
 </book>

</debiandoc>