[ precedente ] [ Contenuti ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ successivo ]


The Debian GNU/Linux FAQ
Capitolo 5 - Gli archivi FTP Debian


5.1 Cosa sono tutte quelle directory negli archivi FTP Debian?

Il software che è stato impacchettato per Debian GNU/Linux è disponibile in uno dei diversi alberi di directory in ogni sito mirror Debian.

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

La directory pool contiene gli attuali pacchetti, si veda Cosa c'è nella directory pool?, Sezione 5.11.

Ci sono queste directory aggiuntive:

/tools/:

Utilità DOS per creare dischi di avvio, partizionare il proprio disco, comprimere/decomprimere file e avviare Linux.

/doc/:

La documentazione di base di Debian, come la FAQ, le istruzioni del sistema di segnalazione dei bachi, ecc.

/indices/:

Il file dei Manutentori e i file override.

/project/:

per la maggior parte materiale solo per gli sviluppatori, come:

project/experimental/:

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.


5.2 Quante distribuzioni Debian ci sono nella directory dists?

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 A proposito di "frozen"?, Sezione 5.4).


5.3 Cosa sono tutti quei nomi come slink, potato, ecc.?

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 unstable cambia improvvisamente il nome in stable, una certa quantità di software dovrà necessariamente essere scaricata nuovamente).

Attualmente, stable è un link simbolico a woody (ovvero Debian GNU/Linux 4.0) e testing è un link simbolico a sarge. Questo significa che woody è la distribuzione attualmente stabile e che sarge è la distribuzione attualmente in testing.

unstable è un link simbolico permanente a sid, dato che sid è sempre la distribuzione instabile (si veda A proposito di "sid"?, Sezione 5.5).


5.3.1 Quali altri nomi in codice sono stati usati in passato?

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


5.3.2 Da dove derivano questi nomi in codice?

Finora sono stati presi dai nomi dei personaggi del film "Toy Story" della Pixar.

<!- Q: Should we add the trademark info here? Maybe as a footnote Mr. Potato is a Registered Trademark of Playskool, Inc., Pawtucket, R.I., a division of Hasbro Inc. Slinky Dog is a trademark of Poof Products of Plymouth, Mich., Etch-a-Sketch is a trademark of The Ohio Art Company, other characters might also be registered trademarks... (jfs) -->


5.4 A proposito di "frozen"?

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

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.

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.

Con ogni nuova release, la precedente distribuzione "stable" diventa obsoleta e viene spostata in archivio. Per maggiori informazioni si veda l'archivio Debian.


5.5 A proposito di "sid"?

sid o unstable è 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 testing, per poter essere rilasciati in stable più tardi. sid contiene pacchetti sia per architetture rilasciate che non.

Anche il nome "sid" proviene dal film d'animazione "Toy Story": Sid era il bambino vicino di casa che distruggeva i giocattoli :-)


5.5.1 Note storiche su "sid"

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.

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.

Con l'avvento dei pacchetti pools (letteralmente "vasche" - si veda Cosa c'è nella directory pool?, Sezione 5.11), 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).


5.6 Cosa contiene la directory stable?


5.7 Cosa contiene la directory testing?

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.

Maggiori informazioni sullo stato del "testing" in generale e dei singoli pacchetti è disponibile su http://www.debian.org/devel/testing


5.8 Cosa contiene la directory unstable?

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

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


5.9 Cosa sono tutte quelle directory dentro a dists/stable/main?

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

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

Si veda Su quali architetture e/o sistemi hardware funziona Debian GNU/Linux?, Sezione 3.1 per maggiori informazioni.


5.10 Dov'è il codice sorgente?

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

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 pool (si veda Cosa c'è nella directory pool?, Sezione 5.11). Per ottenere il codice sorgente senza la necessità di essere familiari con la struttura dell'archivio FTP Debian, si provi un comando come apt-get source nomedelmiopacchetto.

Alcuni pacchetti sono distribuiti solo come codice sorgente a causa delle restrizioni nelle loro licenze. In particolare, uno di questi pacchetti è pine, si veda Dov'è pine?, Sezione 4.10 per maggiori informazioni.

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.


5.11 Cosa c'è nella directory pool?

Storicamente, i pacchetti erano tenuti nella sottodirectory di dists 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.

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.

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

Le directory dists vengono ancora utilizzate per i file indice usati da programmi come apt. 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.

Normalmente, non ci sarà da preoccuparsi di tutto questo, dato che apt e probabilmente dpkg-ftp (si veda Come posso mantenere il mio sistema Debian recente?, Sezione 8.2) gestiranno la cosa senza problemi.


5.12 Cos'è "incoming"?

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.

Di solito nessuno dovrebbe installare cose da questo posto. Comunque, in alcuni rari casi di emergenza, la directory incoming è disponibile su 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.


[ precedente ] [ Contenuti ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ successivo ]


The Debian GNU/Linux FAQ

versione 4.0.4+nmu1ubuntu1, 16 April 2010

Autori della FAQ Debian