| Capitolo 6. Gli archivi Debian | ||
|---|---|---|
 |  | |
| Capitolo 6. Gli archivi Debian | ||
|---|---|---|
| | | |
Indice
dists/stable/main?pool?Esistono tre distribuzioni principali: la distribuzione "stable" (stabile), la distribuzione "testing" (in test) e la distribuzione "unstable" (instabile). La distribuzione "testing" è a volte congelata, "frozen" (si veda Sezione 6.5.1, «Cosa dire di "testing"? Come viene "congelata"?»). Oltre a queste c'è la distribuzione "oldstable" (che è semplicemente quella che ha preceduto "stable") e quella "experimental".
Experimental è usata per i pacchetti che sono ancora in fase di sviluppo e con un alto rischio di danneggiamento del sistema. Viene usata da sviluppatori che vogliono studiare e testare software recentissimo. Gli utenti non dovrebbero usare pacchetti provenienti da lì perché questi possono essere pericolosi e creare danni anche per le persone più esperte.
Per un aiuto al momento di scegliere una distribuzione Debian, si veda Capitolo 3, Scegliere una distribuzione Debian.
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 cambiasse improvvisamente il nome in
stable, moltissima roba dovrebbe essere inutilmente
scaricata di nuovo).
Attualmente, stable è un collegamento simbolico a
bullseye (ovvero Debian GNU/Linux 11) e
testing è un collegamento simbolico a
bookworm. Questo significa che
bullseye è la distribuzione stable attuale e che
bookworm è la distribuzione testing attuale.
unstable è un collegamento simbolico permanente a
sid, dato che sid è sempre la
distribuzione unstable (si veda Sezione 6.3, «Cosa dire a proposito di "sid"?»).
Oltre a bullseye e
bookworm, altri nomi in codice che sono già
stati usati sono: buzz per il rilascio 1.1,
rex per il rilascio 1.2, bo per il
rilascio 1.3.x, hamm per il rilascio 2.0,
slink per il rilascio 2.1, potato per
il rilascio 2.2, woody per il rilascio 3.0,
sarge per il rilascio 3.1, etch per il
rilascio 4.0, lenny per il rilascio 5.0 e
squeeze per il rilascio 6.0, wheezy
per il rilascio 7, jessie per il rilascio 8,
stretch per il rilascio 9 e buster per
il rilascio 10.
Finora sono stati presi dai nomi dei personaggi del film "Toy Story" della Pixar.
buzz (Debian 1.1) era l'astronauta Buzz Lightyear,
rex (Debian 1.2) era il tirannosauro,
bo (Debian 1.3) era Bo Peep, la bambina che si prese cura della pecora,
hamm (Debian 2.0) era il salvadanaio a forma di maialino,
slink (Debian 2.1) era Slinky Dog, il cane giocattolo,
potato (Debian 2.2) era ovviamente Mr. Potato,
woody (Debian 3.0) era il cowboy,
sarge (Debian 3.1) era il sergente dell'Armata Verde,
etch (Debian 4.0) era la lavagna giocattolo (Etch-a-Sketch),
lenny (Debian 5.0) era il binocolo giocattolo,
squeeze (Debian 6) era il nome degli alieni con tre occhi,
wheezy (Debian 7) era il pinguino di gomma con un farfallino rosso,
jessie (Debian 8) era la cowgirl che faceva lo yodel,
stretch (Debian 9) era la piovra giocattolo di gomma con ventose sulle sue otto lunghe braccia,
buster (Debian 10) era il cagnolino di Andy,
bullseye (Debian 11) era il cavallo di legno di Woody,
bookworm (Debian 12) era un verme giocattolo verde con una torcia incorporata che amava leggere libri,
trixie (Debian 13) era un triceratopo di plastica blu.
sid era il bambino cattivo della casa accanto che distruggeva tutti i giocattoli.
La decisione di usare i nomi in Toy Story è stata presa da Bruce Perens che, all'epoca, era il Debian Project Leader e stava contemporaneamente lavorando alla Pixar, la compagnia che ha prodotto i film.
sid o unstable è il posto in cui la maggior parte dei pacchetti viene inizialmente caricata. Non sarà mai direttamente rilasciata, perché i pacchetti che devono essere rilasciati devono 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 della porta accanto che distruggeva i giocattoli :-)
stable/main/: questa directory contiene i pacchetti che costituiscono formalmente il rilascio più recente del sistema Debian GNU/Linux.
Tutti questi pacchetti sono conformi alle DFSG - Linee guida Debian per il software libero e sono tutti liberamente utilizzabili e distribuibili.
stable/non-free/: questa directory contiene i pacchetti la cui distribuzione è limitata in modo tale da richiedere che i distributori prendano attentamente in considerazione i loro requisiti specifici relativi al copyright.
Per esempio, alcuni pacchetti hanno licenze che ne vietano la distribuzione commerciale. Altri possono essere redistribuiti, ma sono di fatto shareware e non software libero. Le licenze di ognuno di questi pacchetti devono essere studiate e possibilmente negoziate prima che tali pacchetti possano essere inclusi in qualsiasi redistribuzione (per esempio, in un CD-ROM).
stable/contrib/: questa directory contiene i pacchetti che sono di per sé liberi in base alle DFSG e liberamente distribuibili, ma dipendono in qualche modo da un pacchetto che non è liberamente distribuibile ed è quindi disponibile solo nella sezione non-free.
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 avere dipendenze tali da renderli non installabili; devono inoltre avere meno bug critici per il rilascio delle versioni attualmente in unstable. In questo modo, si auspica che «testing» sia sempre vicina ad essere una candidata al rilascio.
Maggiori informazioni sullo stato di "testing" in generale e dei singoli pacchetti sono disponibili su https://www.debian.org/devel/testing.
Quando la distribuzione «testing» è abbastanza matura, il responsabile del rilascio inizia a «congelarla». I normali ritardi di diffusione vengono aumentati per assicurare che entri da «unstable» in «testing» il minor numero di bug possibile.
Dopo un po', la distribuzione "testing" diventa realmente "congelata" (frozen). Ciò significa che tutti i nuovi pacchetti da mettere in "testing" sono trattenuti, a meno che non contengano le soluzioni a bug critici per il rilascio. La distribuzione "testing" può anche rimanere in questo stato di "surgelamento" durante i cosiddetti "cicli di test", quando il rilascio è imminente.
Quando un rilascio diventa "congelato", "unstable" tende a congelarsi parzialmente anch'essa. Ciò avviene perché gli sviluppatori sono restii a caricare software radicalmente nuovo in unstable, nel caso che il software congelato in testing necessiti di aggiornamenti minori e per risolvere bug critici per il rilascio che impediscono a testing di diventare "stable".
Viene tenuto un registro dei bug nella distribuzione "testing" che possono impedire ad un pacchetto di essere rilasciato, o dei bug che possono impedire l'intero rilascio. Per i dettagli si vedano le informazioni sull'attuale rilascio testing.
Una volta che il numero dei bug si abbassa sotto i valori massimi accettabili, la distribuzione "congelata" viene dichiarata "stable" e rilasciata con un proprio numero di versione.
Il conteggio più importante per i bug è quello dei bug critici per il rilascio ("Release Critical"), che può essere seguito nella Pagina dello stato dei bug critici per il rilascio. Un comune obiettivo di rilascio è NoRCBugs che significa che la distribuzione non dovrebbe avere alcun bug di gravità critica, grave o seria. L'elenco completo dei problemi considerati critici può essere trovato nel documento della politica RC.
Ad ogni nuovo rilascio, la precedente distribuzione "stable" diventa obsoleta e viene spostata in archivio. Per maggiori informazioni si veda l'archivio Debian.
La directory "unstable" contiene un'istantanea del sistema attualmente 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 produzione di software in GNU/Linux, ma se si rompe, i cocci sono vostri :-)
Anche in "unstable" ci sono le sottodirectory main, contrib e non-free, separate con lo stesso criterio adottato in "stable".
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"
ed è il percorso canonico per accedere ai rilasci (e pre-rilasci) Debian
attualmente disponibili.
La directory pool contiene i pacchetti effettivi, si veda
Sezione 6.10, «Cosa c'è nella directory pool?».
Ci sono queste directory aggiuntive:
utilità DOS per creare dischi di avvio, partizionare il proprio disco, comprimere/decomprimere file e avviare Linux.
la documentazione di base di Debian, come queste FAQ, le istruzioni del sistema di segnalazione dei bug, ecc.
vari indici del sito (il file Maintainers e i file override).
per la maggior parte materiale solo per gli sviluppatori e file vari.
All'interno degli alberi di directory principali [3], ci sono tre insiemi di sottodirectory contenenti file indice.
C'è un gruppo di sottodirectory
binary- che contengono
i file indice per i pacchetti binari di ciascuna architettura disponibile,
per esempio qualcosabinary-i386 per i pacchetti che si possono
eseguire su macchine PC Intel x86 o binary-sparc per i
pacchetti da eseguire su SPARCStation Sun.
L'elenco completo delle architetture disponibili per ciascun rilascio è disponibile alla pagina web dei rilasci. Per il rilascio attuale, si veda Sezione 4.1, «Su quali architetture o sistemi hardware funziona Debian?».
I file indice in binary-* si chiamano Packages(.gz, .bz2) e contengono un
riassunto di ciascun pacchetto binario che è incluso in quella
distribuzione. I pacchetti binari effettivi risiedono nella directory pool di livello più alto.
Inoltre esiste una sottodirectory chiamata source/ che contiene i file indice dei pacchetti sorgenti inclusi nella distribuzione. Il file indice si chiama Sources(.gz, .bz2).
Da ultimo, ma non per importanza, c'è un gruppo di sottodirectory pensate
per i file indice del sistema di installazione: sono in
debian-installer/binary-.
architettura
Viene fornito il codice sorgente per tutto ciò che è 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 fornire il codice sorgente li accompagni.
Il codice sorgente viene distribuito nella directory pool
(vedere Sezione 6.10, «Cosa c'è nella directory pool?») insieme con tutte le directory dei binari
specifiche per le architetture. Per ottenere il codice sorgente senza la
necessità di avere familiarità con la struttura dell'archivio Debian, si
provi un comando come apt-get source nomedelmiopacchetto.
A causa di restrizioni nelle licenze, il codice sorgente può essere o meno
disponibile per i pacchetti nelle aree «contrib» e «non-free», che non fanno
formalmente parte del sistema Debian. In alcuni casi possono essere
distribuiti solo dei «frammenti binari» («binary blob») senza sorgenti
(vedere ad esempio firmware-misc-nonfree); in altri casi
la licenza proibisce la distribuzione di binari precompilati, ma permette
quella di pacchetti di codice sorgente che l'utente può compilare localmente
(vedere broadcom-sta-dkms).
I pacchetti vengono tenuti in un grosso "pool", strutturato in base ai nomi dei pacchetti sorgente. Per rendere il tutto usabile, il pool è suddiviso in sezioni ("main", "contrib" e "non-free") e in base alla prima lettera del nome dei pacchetti sorgente. Queste directory contengono diversi file: i pacchetti binari per ciascuna architettura e i pacchetti sorgente da cui sono stati generati i pacchetti binari.
Si può scoprire dove ciascun pacchetto è situato eseguendo un comando come
apt-cache showsrc nomedelmiopacchetto e guardando la riga
"Directory:". Per esempio, i pacchetti apache sono
immagazzinati in pool/main/a/apache/.
Inoltre, 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/.
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.
Normalmente nessuno dovrebbe installare cose da questo posto. Comunque, per alcuni rari casi di emergenza, la directory incoming è disponibile su https://incoming.debian.org/. Si possono scaricare i pacchetti manualmente, controllare la firma GPG e i codici di controllo MD5 nei file .changes e .dsc, e poi installarli.
Se si sono compilati alcuni pacchetti Debian privati che si desiderano installare usando gli strumenti standard per la gestione dei pacchetti Debian, si può impostare un proprio archivio di pacchetti usabile con apt. Questo è utile anche se si desiderano condividere i propri pacchetti Debian quando questi non sono distribuiti dal progetto Debian. Le istruzioni per farlo sono contenute nel Wiki Debian.
[2] Quando sid non esisteva ancora, l'organizzazione del sito FTP aveva un diffetto principale: c'era la presunzione che quando un'architettura veniva creata nell'attuale unstable, essa sarebbe stata rilasciata quando tale distribuzione diventava stable. Per molte architetture ciò non è vero, con il risultato che tali directory dovevano essere rimosse al momento del rilascio. Ciò non era pratico perché lo spostamento consumava moltissima banda.
Gli amministratori dell'archivio aggirarono questo problema per diversi anni mettendo i binari per le architetture non rilasciate in una directory speciale chiamata "sid". Per tali architetture non ancora rilasciate, al momento del primo rilascio c'era un collegamento dell'attuale stabile a sid e da quel momento in avanti venivano create normalmente all'interno dell'albero unstable. Questa disposizione era per gli utenti fonte di una certa confusione.
Con l'avvento dei pool di pacchetti (vedere Sezione 6.10, «Cosa c'è nella directory pool?»), i
pacchetti binari iniziarono ad essere archiviati in una posizione canonica
nel pool, indipendentemente dalla distribuzione, perciò il rilascio di una
distribuzione non causava più un grande consumo di banda sui mirror (c'è
tuttavia molto consumo graduale di banda durante tutto il processo di
sviluppo).
[3]
dists/stable/main,
dists/stable/contrib,
dists/stable/non-free e
dists/unstable/main/, ecc.
[4] Storicamente, i pacchetti erano tenuti nella sottodirectory
dists corrispondente alla distribuzione di cui facevano
parte. Questo si è rivelato fonte di vari problemi, come un grosso consumo
di banda dei mirror ogni volta che venivano fatti dei cambiamenti
importanti. Il problema è stato risolto con l'introduzione dei pool di
pacchetti.
Le directory dists sono ancora utilizzate per i file
indice utilizzati dai programmi come apt.
| | | |
| Capitolo 5. Software disponibile nel sistema Debian |  | Capitolo 7. Fondamenti sul sistema di gestione dei pacchetti Debian |