Update of the Italian FAQ

[Claudio Cattazzo <claudio@linux.it>]

Hi all,
since I don't have write access to the CVS, could someone of you please copy
the two files attached to ddp/manuals.sgml/faq/it/ on the debian-doc CVS
repository?

By the way, if you have time to spend on a new section of the FAQ, I think
it would be interesting to add, after the question 1.6 "How does one
pronounce Debian and what does this word mean?", an explanation of the
meaning of the Debian logo.


TIA,
Claudio
http://www.linux.it/~claudio/

<chapt id="ftparchives">Gli archivi FTP Debian

<sect id="dirtree">Cosa sono tutte quelle directory negli archivi FTP Debian?

<p>Il software che è stato impacchettato per &debian; è disponibile in
uno dei diversi alberi di directory in ogni sito mirror Debian.

<p>La directory <tt>dists</tt> è l'abbreviazione di "distribuzioni" (distributions) ed
è il percorso canonico per accedere alle release (e pre-release) Debian attualmente disponibili.

<p>La directory <tt>pool</tt> contiene gli attuali pacchetti, si veda <ref id="pools">.

<p>Ci sono queste directory aggiuntive:
<taglist>
  <tag><em>/tools/</em>:
    <item>Utilità DOS per creare dischi di avvio, partizionare il proprio
    disco, comprimere/decomprimere file e avviare Linux.
  <tag><em>/doc/</em>:
    <item>La documentazione di base di Debian, come la FAQ, le istruzioni del
          sistema di segnalazione dei bachi, ecc.
  <tag><em>/indices/</em>:
    <item>Il file dei Manutentori e i file override.
  <tag><em>/project/</em>:
    <item>per la maggior parte materiale solo per gli sviluppatori, come:
    <taglist>
      <tag><em>project/experimental/</em>:
        <item>Questa directory contiene pacchetti e strumenti che sono ancora in via
        di sviluppo e sono ancora allo stadio alpha di controllo. Gli utenti
        non dovrebbero usare i pacchetti provenienti da qui, perché possono essere pericolosi
        e dannosi anche per le persone con più esperienza.
    </taglist>
</taglist>

<sect id="dists">Quante distribuzioni Debian ci sono nella directory <tt>dists</tt>?

<p>Normalmente ci sono tre distribuzioni, la distribuzione "stable"
(stabile), la distribuzione "testing" (in test) e la distribuzione "unstable"
(instabile). Qualche volta c'è anche la distribuzione "frozen" (congelata,
si veda <ref id="frozen">).

<sect id="codenames">Cosa sono tutti quei nomi come slink, potato, ecc.?

<p>Sono solo "nomi in codice". Quando una distribuzione Debian
è in fase di sviluppo non ha un numero di versione ma un nome
in codice. Lo scopo di questi nomi in codice è di rendere più semplice
la creazione di mirror delle distribuzioni Debian (se una directory reale
come <tt>unstable</tt> cambia improvvisamente il nome in <tt>stable</tt>,
una certa quantità di software dovrà necessariamente essere scaricata nuovamente).

<!-- XXX update for new distros -->
<p>Attualmente, <tt>stable</tt> è un link simbolico a <tt>woody</tt>
(ovvero &debian; &release;) e <tt>testing</tt> è un link simbolico
a <tt>sarge</tt>.
Questo significa che <tt>woody</tt> è la distribuzione attualmente stabile
e che <tt>sarge</tt> è la distribuzione attualmente in testing.

<p><tt>unstable</tt> è un link simbolico permanente a <tt>sid</tt>, dato che
<tt>sid</tt> è sempre la distribuzione instabile (si veda <ref id="sid">).

<sect1 id="oldcodenames">Quali altri nomi in codice sono stati usati in passato?

<p>Altri nomi in codice che sono già stati usati sono: <tt>buzz</tt> per la
release 1.1, <tt>rex</tt> per la release 1.2, <tt>bo</tt> per la release 1.3.x,
<tt>hamm</tt> per la release 2.0, <tt>slink</tt> per la release 2.1 e
<tt>potato</tt> per la release 2.2.

<sect1 id="sourceforcodenames">Da dove derivano questi nomi in codice?

<p>Finora sono stati presi dai nomi dei personaggi del film "Toy Story" della Pixar.
<list>
  <item><em>buzz</em> (Buzz Lightyear) era l'astronauta,
  <item><em>rex</em> era il tirannosauro,
  <item><em>bo</em> (Bo Peep) era la bambina che si prese cura della pecora,
  <item><em>hamm</em> era il salvadanaio a porcellino,
  <item><em>slink</em> (Slinky Dog (R)) era il cane giocattolo,
  <item><em>potato</em> era, ovviamente, Mr. Potato (R),
  <item><em>woody</em> era il cowboy.
  <item><em>sarge</em> era il sergente del Green Plastic Army Men,
  <item><em>etch</em> era la lavagna giocattolo (Etch-a-Sketch (R)).
</list>
<!--
  more info in http://www.pixar.com/feature/toystory/toystory.html
  or better yet http://us.imdb.com/M/title-exact?Toy%20Story%20(1995)
  or actually:
    http://us.imdb.com/Title?0114709 for TS1
    http://us.imdb.com/Title?0120363 for TS2
  we shouldn't put the links in, Pixar needs no additional propaganda
-->
<!--
  characters not used from Toy Story (yet):
    - Andy (the kid)
    - Snake
    - Robot
    - Scud (Sid's dog)
    - Lenny the Binoculars
    - Three Eyed Alien
  and additional characters from Toy Story 2, also not yet used:
    - Jessie (the Yodelling Cowgirl)
    - Zurg (the Evil Emperor)
    - Wheezy (the penguin)
    - Hannah (owner of Jessie)
    - Stinky Pete the Prospector (the old fat guy)
    - Mrs. Davis (Andy's Mom)
    - Barbie (the Tour Guide, probably under (c))
    - Mrs. Potato Head
    - Heimlich the Caterpillar
-->
<!-- (jfs) Just in case somebody misses the "What do we do when we finish
with Toy Story characters" thread see:
http://lists.debian.org/debian-devel/2002/debian-devel-200207/msg01133.html
I, suggested we followed with either Monster's Inc or "A Bug's life" :)
-->

<sect id="frozen">A proposito di "frozen"?

<p>Quando la distribuzione "testing" è matura abbastanza, il responsabile della release
inizia a 'congelarla'. I normali ritardi di diffusione vengono aumentati per assicurare
che il minor numero di bachi possibile da "unstable" entri in "testing".

<p>Dopo un po', la distribuzione "testing" diventa realmente 'frozen' (congelata). Questo
significa che tutti i nuovi pacchetti da mettere in "testing" sono rimandati indietro,
a meno che non includano fissaggi per bachi release-critical. La distribuzione "testing"
può anche rimanere in uno stato di "congelamento profondo" durante i cosiddetti
'test cycles' (cicli di test), quando il rilascio è imminente.

<p>Teniamo una registrazione dei bachi nella distribuzione "testing" che possono
impedire ad un pacchetto di essere rilasciato, o dei bachi che possono impedire
il rilascio dell'intera release. Una volta che il numero dei bachi è più
basso del valore massimo accettabile, la distribuzione "frozen" viene dichiarata
"stable" e rilasciata con un numero di versione.

<p>Con ogni nuova release, la precedente distribuzione "stable" diventa obsoleta
e viene spostata in archivio. Per maggiori informazioni si veda
l'<url name="archivio Debian" id="http://www.debian.org/distrib/archive";>.

<sect id="sid">A proposito di "sid"?

<p><em>sid</em> o <em>unstable</em> è il posto in cui la maggior parte dei pacchetti
viene inizialmente caricata. Non sarà mai direttamente rilasciata, perché i pacchetti
che stanno per essere rilasciati dovranno prima essere inclusi in <em>testing</em>,
per poter essere rilasciati in <em>stable</em> più tardi. sid contiene pacchetti
sia per architetture rilasciate che non.

<p>Anche il nome "sid" proviene dal film d'animazione "Toy Story": Sid
era il ragazzo della porta accanto che distruggeva i giocattoli :-)

<sect1 id="sid-history">Note storiche su "sid"

<p>Quando l'attuale sid non esisteva, l'organizzazione del sito FTP
aveva un problema principale: c'era l'assunto che quando un'architettura veniva
creata nell'attuale unstable, sarebbe stata rilasciata quando quella distribuzione
diventava la nuova stable. Per molte architetture questo non è il caso,
con il risultato che quelle directory dovevano essere mosse al momento del
rilascio. Poco pratico, poiché lo spostamento avrebbe divorato grosse
quantità di banda.

<p>Gli amministratori dell'archivio hanno evitato questo problema per diversi
anni collocando i binari delle architetture non ancora rilasciate in una directory
speciale chiamata "sid". Per quelle architetture non ancora rilasciate, al primo
rilascio c'era un link da stable a sid e da quel momento in poi essa veniva creata
all'interno dell'albero unstable di norma. Tutto ciò
era motivo di confusione per gli utenti.

<p>Con l'avvento dei pacchetti pools (letteralmente "vasche" - si veda <ref id="pools">),
i pacchetti binari cominciarono ad essere immagazzinati in una locazione canonica
nella "vasca", indipendentemente dalla distribuzione, così il rilascio di una
distribuzione non determina più grande dispendio di banda sui mirror (c'è,
ovviamente, un notevole graduale consumo di banda durante la fase di sviluppo).

<sect id="stable">Cosa contiene la directory stable?

<p><list>
  <item>stable/main/:
  Questa directory contiene i pacchetti che costituiscono formalmente la release
  più recente del sistema &debian;.

  <p>Tutti questi pacchetti sono conformi alle <url name="Debian Free Software Guidelines"
  id="http://www.debian.org/social_contract#guidelines";> (Linee Guida del Software Libero
  Debian) e sono tutti liberamente utilizzabili e distribuibili.

  <item>stable/non-free/: Questa directory contiene i pacchetti la cui distribuzione
  è ristretta in un modo tale da richiedere ai distributori delle cautele dovute
  ai loro requisiti specifici di copyright.

  <p>Per esempio, alcuni pacchetti hanno licenze che ne vietano la distribuzione
  commerciale. Altri possono essere redistribuiti, ma sono di fatto shareware
  e non freeware. Le licenze di ognuno di questi pacchetti devono essere studiate e
  possibilmente negoziate prima che tali pacchetti possano essere inclusi in qualsiasi
  redistribuzione (p.e., in un CD-ROM).

  <item>stable/contrib/: Questa directory contiene i pacchetti che sono
  DFSG-free e <em>liberamente distribuibili</em> da soli, ma dipendono in
  qualche modo da un pacchetto che <em/non/ è liberamente distribuibile
  ed è quindi disponibile solo nella sezione non-free.
</list>

<sect id="testing">Cosa contiene la directory testing?

<p>I pacchetti vengono inseriti nella directory 'testing' dopo aver subito
un periodo di test in unstable. Devono essere sincronizzati
in tutte le architetture per le quali sono stati compilati e non devono
mostrare dipendenze tali da renderli non installabili; devono inoltre avere
meno bachi release-critical delle versioni sotto test al momento. In questo modo, si
auspica che 'testing' sia sempre vicina ad essere candidata al rilascio.

<p>Maggiori informazioni sullo stato del "testing" in generale e dei singoli
pacchetti è disponibile su <url id="http://www.debian.org/devel/testing";>

<sect id="unstable">Cosa contiene la directory unstable?

<p>La directory 'unstable' contiene un'immagine del sistema correntemente
in via di sviluppo. Gli utenti sono i benvenuti ad usare e testare questi
pacchetti, ma sono avvisati riguardo il loro stato di preparazione. Il
vantaggio di usare la distribuzione 'unstable' è che si è sempre aggiornati
con la più recente industria di software in GNU/Linux, ma se non
funzionasse: vi toccherà tenere entrambe le parti :-)

<p>In 'unstable' ci sono anche le sottodirectory main, contrib e non-free,
separate con lo stesso criterio adottato in 'stable'.

<sect id="archsections">Cosa sono tutte quelle directory dentro a <tt>dists/stable/main</tt>?

<p>All'interno dei maggiori alberi di directory (<tt>dists/stable/main</tt>,
<tt>dists/stable/contrib</tt>, <tt>dists/stable/non-free</tt> e
<tt>dists/unstable/main/</tt>, ecc.), i pacchetti binari risiedono in sottodirectory
i cui nomi indicano l'architettura dei chip per i quali sono stati compilati:

<list>
  <item>binary-all/, per pacchetti che sono indipendenti dall'architettura.
  Questi includono, per esempio, script Perl o pura documentazione.

  <item>binary-i386/, per pacchetti che funzionano su macchine PC 80x86.

  <item>binary-m68k/, per pacchetti che funzionano su macchine basate su
  uno dei processori Motorola 680x0. Attualmente questo è fatto
  principalmente per computer Atari e Amiga e per alcune schede
  industriali standard basate su VME.
<!-- Still true?
    There is no port of Linux to the old m68k based Macintoshes,
    because Apple did not supply the needed hardware information.
-->

  <item>binary-sparc/, per pacchetti che funzionano su Sun SPARCStation.

  <item>binary-alpha/, per pacchetti che funzionano su macchine DEC Alpha.

  <item>binary-powerpc/, per pacchetti che funzionano su macchine PowerPC.

  <item>binary-arm/, per pacchetti che funzionano su macchine ARM.
</list>

<p>Si noti che gli attuali pacchetti binari per <em/woody/ e
release successive non risiedono più in queste directory, ma nella directory
<tt/pool/ al livello superiore. I file di indice (Packages e Packages.gz)
sono stati tenuti, comunque, per compatibilità con il passato.

<p>Si veda <ref id="arches"> per maggiori informazioni.

<sect id="source">Dov'è il codice sorgente?

<p>Il codice sorgente è incluso per qualsiasi cosa nel sistema
Debian. Inoltre, i termini di licenza della maggior parte dei programmi
<em>richiedono</em> che il codice venga distribuito insieme ai programmi o che
un'offerta di fornitura del codice sorgente li accompagni.

<p>Normalmente il codice sorgente viene distribuito nelle directory "source", che
sono in parallelo a tutte le directory dei binari specifici per l'architettura
o più recentemente nella directory <tt>pool</tt> (si veda <ref id="pools">).
Per ottenere il codice sorgente senza la necessità di essere familiari con la
struttura dell'archivio FTP Debian, si provi un comando come
<tt>apt-get source nomedelmiopacchetto</tt>.

<p>Alcuni pacchetti sono distribuiti solo come codice sorgente a causa delle restrizioni
nelle loro licenze. In particolare, uno di questi pacchetti è <tt>pine</tt>, si veda
<ref id="pine"> per maggiori informazioni.

<p>Il codice sorgente potrebbe essere disponibile o non esserlo per i pacchetti nelle
directory "contrib" e "non-free", che non sono formalmente parte del sistema Debian.

<sect id="pools">Cosa c'è nella directory <tt>pool</tt>?

<p>Storicamente, i pacchetti erano tenuti nella sottodirectory di <tt>dists</tt>
corrispondente alla distribuzione di cui facevano parte. Questo causava
vari problemi, come un grosso consumo di banda dei mirror
ogni volta che venivano fatti dei cambiamenti di grossa portata.

<p>Ora i pacchetti vengono tenuti in una grossa 'vasca' (pool), strutturata
in accordo con il nome del pacchetto sorgente. Per rendere il tutto maneggevole,
la vasca è suddivisa in sezioni ('main', 'contrib' e 'non-free') e secondo la prima lettera
del nome del pacchetto sorgente. Queste directory contengono diversi file: i
binari per ciascuna architettura e i pacchetti sorgente da cui sono stati
generati i pacchetti binari.

<p>Si può sapere dove ciascun pacchetto è situato eseguendo un
comando come <tt>apt-cache showsrc nomedelmiopacchetto</tt> e vedendo
la riga 'Directory:'. Per esempio, i pacchetti <tt>apache</tt> sono immagazzinati
in <tt>pool/main/a/apache/</tt>. Poiché ci sono così tanti pacchetti <tt>lib*</tt>,
questi vengono trattati in maniera particolare: per esempio, i pacchetti
libpaper sono immagazzinati in pool/main/libp/libpaper/.

<p>Le directory <tt>dists</tt> vengono ancora utilizzate per i file indice usati da
programmi come <tt>apt</tt>. Inoltre, al momento della scrittura di questo documento,
le vecchie distribuzioni non sono state convertite per usare le vasche, per cui si
troveranno i percorsi contenenti distribuzioni come potato o woody nel campo Filename dell'intestazione.

<p>Normalmente, non ci sarà da preoccuparsi di tutto questo, dato che <tt>apt</tt> e
probabilmente <tt>dpkg-ftp</tt> (si veda <ref id="howtocurrent">) gestiranno la cosa
senza problemi.
<!-- joeyh doesn't want to maintain it so it's dead; need to integrate it
Se si desiderano maggiori informazioni, si veda la
<url id="http://people.debian.org/~joeyh/poolfaq"; name="Debian Package Pools FAQ">.
-->

<sect id="incoming">Cos'è "incoming"?

<p>Dopo che uno sviluppatore carica un pacchetto, questo resta per un po' nella directory
"incoming" prima che ne venga controllata la genuinità e che venga accettato nell'archivio.

<p>Di solito nessuno dovrebbe installare cose da questo posto. Comunque, in alcuni
rari casi di emergenza, la directory incoming è disponibile su
<url id="http://incoming.debian.org/";>. Si possono scaricare i pacchetti manualmente,
controllare la firma GPG e gli MD5sum nei file .changes e .dsc,
e poi installarli.

<chapt id="kernel">Debian e il kernel

<sect id="non-debian-kernel">Posso installare e compilare un kernel senza alcun adattamento
  specifico per Debian?

<p>Sì.

<p>C'è solo una trappola: le librerie C di Debian sono compilate con la più recente
release <em>stabile</em> degli header del <strong>kernel</strong>.
Se capita di aver bisogno di compilare un programma con gli header del kernel
più nuovi rispetto a quelli nella serie stabile allora si dovrebbe aggiornare
il pacchetto contenente gli header (<package/libc6-dev/) oppure usare i nuovi
header da un albero di directory del kernel più recente. Così, se i sorgenti
del kernel sono in <file>/usr/src/linux</file>, si dovrebbe aggiungere
<tt>-I/usr/src/linux/include/</tt> alla propria riga di comando quando si compila.

<sect id="customkernel">Quali strumenti fornisce Debian per costruire kernel personalizzati?

<p>Gli utenti che desiderano (o devono) costruirsi un kernel personalizzato sono
incoraggiati a scaricare il pacchetto <package/kernel-package/. Questo pacchetto
contiene lo script per costruire il pacchetto kernel e fornisce la
possibilità di creare un pacchetto Debian kernel-image solo eseguendo il comando
  <example>make-kpkg kernel_image</example>
nel livello più alto della directory dei sorgenti del kernel.
L'aiuto è disponibile eseguendo il comando
  <example>make-kpkg --help</example>
e attraverso la pagina di manuale <manref name="make-kpkg" section="8">.

<p>Gli utenti devono scaricare separatamente il codice sorgente per il
kernel più recente (o il kernel di propria scelta) dall'archivio del
proprio sito Linux preferito, a meno che un pacchetto kernel-source-version
sia disponibile (dove "version" rappresenta la versione del kernel).

<p>Istruzioni dettagliate sull'uso del pacchetto <package/kernel-package/
sono fornite nel file <tt>/usr/doc/kernel-package/README.gz</tt>. In breve, si dovrebbe:

<list>
  <item>Spacchettare i sorgenti del kernel e <tt>cd</tt> alla nuova directory creata.
  <item>Modificare la configurazione del kernel usando uno di questi comandi:
    <list>
      <item><tt>make config</tt> (per un'interfaccia tty una-riga-alla-volta).
      <item><tt>make menuconfig</tt> (per un'interfaccia a menu basata su ncurses).
        Si noti che se si usa questa opzione, il pacchetto <package/libncurses5-dev/
        deve essere installato.
      <item><tt>make xconfig</tt> (per un'interfaccia X11).
        Usare questa opzione richiede che pacchetti rilevanti di X e Tcl/Tk siano installati.
    </list>
    Ognuno dei passi sopra genera un nuovo <tt>.config</tt> nel livello più alto
    della directory dei sorgenti del kernel.
  <item>Eseguire il comando: <tt>make-kpkg -rev Custom.N kernel_image</tt>,
    dove N è un numero di revisione assegnato dall'utente.
    Il nuovo archivio Debian così formato dovrebbe avere revisione Custom.1, p.e.,
    <tt>kernel-image-2.2.14_Custom.1_i386.deb</tt>
    per il kernel Linux 2.2.14.
  <item>Installare il pacchetto creato.
    <list>
    <item><tt>Si esegua dpkg --install /usr/src/kernel-image-VVV_Custom.N.deb</tt>
      per installare il kernel. Lo script di installazione:
      <list>
        <item>eseguirà il boot loader, LILO (se è installato),
        <item>installerà il kernel personalizzato in /boot/vmlinuz_VVV-Custom.N e
          imposterà gli appropriati link simbolici alla versione del kernel
          più recente.
        <item>chiederà all'utente di fare un floppy di avvio. Questo
          floppy conterrà solo il kernel. Si veda <ref id="custombootdisk">.
      </list>
    <item>Per servirsi di boot loader secondari come <package/grub/ o
      <tt/loadlin/, si copi questa immagine in altri posti (p.e., in /boot/grub
      o su una partizione <tt>MS-DOS</tt>).
  </list>
</list>

<!-- TODO: check out a new source of details, this README isn't too useful,
I'm told (joy) -->
<sect id="custombootdisk">Come posso creare un floppy di avvio personalizzato?

<p>Questo compito è molto semplificato dal pacchetto Debian <package/boot-floppies/,
che si trova normalmente nella sezione <tt>admin</tt> dell'archivio FTP Debian.
Gli script di shell in questo pacchetto producono floppy di boot nel formato <tt>SYSLINUX</tt>.
Questi sono floppy formattati <tt>MS-DOS</tt> i cui master boot record sono stati alterati
così che possano avviare direttamente Linux (o qualsiasi altro sistema operativo
sia stato definito nel file syslinux.cfg sul floppy). Altri script in questo pacchetto
producono dischi di root di emergenza e possono anche riprodurre i dischi base.

<p>Si troveranno maggiori informazioni su questo nel file
<tt>/usr/doc/boot-floppies/README</tt> dopo aver installato il pacchetto
<package/boot-floppies/.

<sect id="modules">Quali strumenti speciali fornisce Debian per lavorare con i moduli?

<p>Il pacchetto <package/modconf/ di Debian fornisce uno script di shell
(<tt>/usr/sbin/modconf</tt>) che può essere usato per personalizzare
la configurazione dei moduli. Questo script presenta un'interfaccia basata su menu
che chiede all'utente particolari sui dispositivi driver caricabili nel suo sistema.
Le risposte sono usate per personalizzare il file <tt>/etc/modules.conf</tt> (che elenca
gli alias ed altri argomenti che devono essere usati in congiunzione con i vari moduli)
attraverso i file in <tt>/etc/modutils/</tt> e <tt>/etc/modules</tt> (che elenca i
moduli che devono essere caricati all'avvio).

<p>Come i (nuovi) file Configure.help sono ora disponibili per supportare
la costruzione di kernel personalizzati, il pacchetto modconf nasce con una serie
di file di aiuto (in <tt>/usr/lib/modules_help/</tt>) che forniscono
informazioni dettagliate sugli argomenti appropriati per ognuno dei moduli.

<sect id="removeoldkernel">Posso disinstallare con sicurezza un vecchio pacchetto kernel e,
  se sì, come?

<p>Sì. Lo script <tt>kernel-image-NNN.prerm</tt> verifica se il kernel
che si sta correntemente usando è lo stesso kernel che si sta tentando di
disinstallare. Quindi si può rimuovere il pacchetto dell'immagine del
kernel che non si vuole usando questo comando:

<example>dpkg --purge --force-remove-essential kernel-image-NNN</example>

(si sostituisca "NNN" con la propria versione e numero di revisione del kernel, ovviamente)