Questo capitolo spiega un sistema Debian a partire dai suoi fondamentali, ed è indirizzato ai non-sviluppatori. Per avere informazioni più autorevoli, vedere:
reperibili sotto Riferimenti, Sezione 15.1.
Se state cercando una qualsiasi risposta che li riguarda senza, però, tutti i loro dettagli,andate direttamente a Gestione dei pacchetti in Debian, Capitolo 6 o ad altri capitoli.
Questo capitolo è formato da documenti presi dalla "Debian FAQ", e profondamente riorganizzati, per permettere ad un qualsiasi amministratore di un sistema Debian di avere un solido punto di partenza.
Il software impacchettato per la debian, è disponibile in uno dei numerosi
alberi directory su ciascun Debian mirror site
raggiungibili tramite FTP o HTTP.
Queste sono le directories presenti su ciascun mirror, sotto la directory /debian/:
/dists/
:/pool/
:/tools/
:/doc/
:/indices/
:/project/
:project/experimental/
:project/orphaned/
:Di norma sono tre le distribuzioni contenute nella directory dists. Sono definite come la distribuzione "stable", la "testing" e la "unstable". Talvolta se ne aggiunge una quarta, la "frozen". Ogni distribuzione viene definita con un link simbolico alla directory reale, tramite un nome proprio nella directory dists.
E' contenuta nella directory stable:
Le voci dei pacchetti per la distribuzione stable, Debian Woody (3.0r0), vengono inserite nella directory stable (symlink a Woody):
stable/main/
: Contiene i pacchetti che costituiscono formalmente
il rilascio più recente del sistema Debian
Tutti i pacchetti sono totalmente complianti con le Debian Free Software
Guidelines
(disponibile anche come
/usr/share/doc/debian/social-contract.txt
installato da
debian-doc
), e sono utilizzabili e distribuibili liberamente.
stable/non-free/
: Contiene i pacchetti la cui distribuzione è in
qualche modo limitata, tale da richiedere ai distributori delle cautele dovute
ai loro requisiti specifici di copyright.
Per esempio alcuni pacchetti hanno licenze che ne vietano la distribuzione commerciale. Altri possono essere ridistribuiti, ma sono degli shareware di fatto, e non freeware. Prima che tali pacchetti possano essere inclusi in qualsiasi ridistribuzione (come un CD-ROM, p.es.), le loro licenze devono essere studiate e possibilmente rinegoziate.
stable/contrib/
: Contiene i pacchetti che sono di per sè DFSG-free
e liberamente distribuibili, ma dipendono in qualche modo da
un pacchetto che non è liberamente distribuibile, ed è quindi
disponibile nella sezione non-free.
Ora, in aggiunta alle locazioni sopra descritte, i nuovi pacchetti sono fisicamente localizzati nella directory pool (La directory pool, Sezione 2.1.10).
Lo stato attuale della distribuzione stable è riportato in sulla
pagina Web Stable
Problems
.
Le voci dei pacchetti per la distribuzione testing, Debian Sarge, sono registrate nella directory testing (symlink a Sarge) dopo aver subito un periodo di prova in unstable. Ora, in aggiunta alle locazioni sopra descritte, i nuovi pacchetti sono fisicamente localizzati nella directory pool (La directory pool, Sezione 2.1.10). La directory testing ha delle sottodirectory, main, contrib e non-free, che hanno le stesse funzioni che in stable.
I pacchetti 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
in unstable. In questo modo si auspica che testing
sia sempre molto vicina ad essere candidata al rilascio. Per maggiori dettagli
sul meccanismo che regola la distribuzione vedere http://ftp-master.debian.org/testing/
.
Lo stato aggiornato della distribuzione testing è riportato presso:
Le voci dei pacchetti della distribuzione unstable, sid, sono registrate nella directory unstable (symlink a sid) dopo essere state caricate nell'archivio Debian, rimanendovi finchè non vengono spostate in testing. I nuovi pacchetti sono fisicamente localizzati nella directory pool (La directory pool, Sezione 2.1.10). La directory unstable ha delle sottodirectory, main, contrib e non-free, che hanno le stesse funzioni che in stable.
La distribuzione unstable contiene le immagini più recenti del sistema in fase di sviluppo. Gli utenti possono liberamente usare e testare questi pacchetti, ma vengono avvisati del loro precario stato di preparazione. Il vantaggio di usare la distribuzione unstable è quello di essere sempre al massimo dell'aggiornamento del progetto Debian relativo al software—siate però pronti a raccogliere i pezzi se qualcosa va storto.
Lo stato aggiornato della distribuzione unstable è riportato
presso la pagina Web Unstable
Problems
.
Una volta che la distribuzione testing è sufficientemente matura, diventa frozen; ciò significa che nessun nuovo codice viene più accettato, solo eliminazioni di bachi, se necessari. In aggiunta un nuovo albero testing viene creato nella directory dists, con un nuovo nome. La distribuzione frozen passa attraverso un ciclo di test (chiamato appunto 'test cycles') di qualche mese caratterizzato da aggiornamenti intermittenti ed importanti stabilizzazioni.(Il recente processo di rilascio di woody non ha prodotto un link simbolico frozen, così frozen non era una distribuzione, ma solo uno stadio di sviluppo della distribuzione testing.)
Viene tenuto un registro dei bachi della distribuzione frozen che possono impedire il rilascio di un pacchetto o di tutta la distribuzione. Una volta che il conteggio dei bachi scende al di sotto di una valore massimo prestabilito, la distribuzione frozen diventa stable e viene rilasciata. La precedente distribuzione stable diventa obsoleta e finisce in archivio.
I nomi delle directory localizzate fisicamente nella directory dists, come Woody e Sarge, sono semplicemente dei nomi in codice. Quando una distribuzione Debian è nella fase di sviluppo le viene assegnato un nome in codice e non un numero di versione. Lo scopo di questi nomi è di rendere il mirroring delle distribuzioni Debian più semplice (se, ad esempio, una directory reale come unstable cambiasse improvvisamente di nome in stable, una gran quantità di programmi dovrebbe essere nuovamente scaricata senza motivo).
Attualmente stable è un link simbolico a Woody e testing è un link simbolico a Sarge. Ciò significa che Woody è la distribuzione attualmente stable e Sarge è l'attuale testing.
unstable è un link simbolico permanente a sid, dato che sid è sempre la distribuzione unstable.
I nomi in codice che sono già stati utilizzati sono: buzz per la release 1.1, rex per la 1.2, bo per la 1.3.x, hamm per la 2.0, slink per la 2.1 e potato per la 2.2.
Finora sono stati presi dai nomi dei personaggi del film" Toy Story" della Pixar.
Storicamente i pacchetti erano contenuti nella subdirectory di dists corrispondente alla distribuzione di cui facevano parte. Questo portò a vari problemi, tipo un grosso consumo di banda di connessione dei mirror ogni volta che venivano fatti dei cambiamenti di grossa entità.
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 per la prima lettera del nome del pacchetto sorgente. Queste directory contengono svariati files: binari per ciascuna architettura ed i pacchetti sorgente da cui i pacchetti binari sono stati generati.
E' possibile sapere dove ciascun pacchetto è situato eseguendo un comando tipo:
apt-cache showsrc nomemiopacchetto ed andando a leggere
la riga "Directory:". Per esempio, i pacchetti apache
sono immagazzinati in pool/main/a/apache/
. Essendo molteplici, i
pacchetti lib* 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 tipo apt. Inoltre, al momento attuale le vecchie distribuzioni non sono state convertite ad usare le vasche, per cui si troveranno i percorsi contenenti distribuzioni tipo potato o woody nel campo "Filename" dell'intestazione.
Di norma non avete da preoccuparvi di ciò, poichè il nuovo apt e
probabilmente il vecchio dpkg-ftp (vedere Metodi per aggiornare un sistema Debian, Sezione
2.3.1) sono in grado di gestire la cosa senza problemi. Se volete maggiori
informazioni, andate a vedere RFC:
implementation of package pools
.
Quando il sid attuale non esisteva, l'organizzazione dell'archivio Debian aveva un problema principale: l'assunto che quando un'architettura veniva creata nell'unstable attuale, sarebbe stata rilasciata quando la distribuzione diventava la nuova stable. Però per molte architetture questo non era il caso, con il risultato che quelle directory dovevano essere mosse al momento del rilascio. Fatto poco pratico, poichè lo spostamento avrebbe fagocitato grosse quantità di banda.
Gli amministratori dell'archivio hanno evitato questo problema per pacchetti anni piazzando i binari delle architetture ancora non rilasciate in una directory speciale chiamata sid. Al momento del loro rilascio esisteva un link dall'architettura a quel momento stable a sid e da quel momento in poi essa veniva creata all'interno dell'albero unstable, come di norma. Tutto ciò era motivo di confusione per gli utenti.
Con l'avvento della vasca dei pacchetti (vedere La directory pool, Sezione 2.1.10) durante lo sviluppo della distribuzione woody i pacchetti binari cominciarono ad essere immagazzinati in una locazione canonica nella vasca, indipendentemente dalla distribuzione; in tal modo il rilascio di una distribuzione non determina più la grossa dispersione di banda sui mirror (c'è, ovviamente, un notevole consumo, ma graduale, di banda durante la fase di sviluppo).
incoming
I pacchetti che vengono caricati nell'archivio vengono dapprima immagazzinati
in http://incoming.debian.org/
prima
di accertarsi che provengano realmente da uno sviluppatore Debian (e vengono
piazzati nella sottodirectory DELAYED
in caso di Non-Maintainer
Upload (NMU)). Una volta al giorno, vengono mossi da incoming ad
unstable.
In caso di emergenza, potreste voler installare i pacchetti da qui, prima che raggiungano unstable.
Mentre le distribuzioni Debian più recenti vengono tenute nella directory
debian directory su ciascun Mirror Debian
, gli
archivi per le distribuzioni più vecchie, tipo Slink, sono tenuti su http://archive.debian.org/
o sotto
la directory debian-archive di ciascun mirror Debian.
I vecchi pacchetti testing ed unstable sono
localizzati in http://snapshot.debian.net/
.
All'interno di ciascun albero directory principale
(dists/stable/main
, dists/stable/contrib
,
dists/stable/non-free
dists/unstable/main/
, etc.), le
voci dei pacchetti binari risiedono all'interno di sottodirectory i cui nomi
indicano l'architettura per la quale sono stati compilati.
binary-all/
, per pacchetti architettura-indipendenti.
Comprendono, per esempio, scripts Perl o pura documentazione.
binary-piattaforma/
, per pacchetti che girano su una
particolare piattaforma.
Ricordate che i reali pacchetti binari per testing ed
unstable non risiedono più in queste directory, ma al livello
principale della directory pool. I file elenco
(Packages
e Packages.gz
) sono stati comunque
mantenuti, per compatibilità con il vecchio sistema.
Per sapere quali architetture sono al momento supportate, leggetevi le Note di
Rilascio per ciascuna distribuzione. Possono essere trovate presso i siti
delle Note di Rilascio per stable
e
testing
.
Il codice sorgente è disponibile per ogni cosa contenuta nel sistema Debian. In più, 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 li accompagni.
Di regola il codice viene reperito nelle directory source, che sono in parallelo a tutte le directory dei binari architettura-specifiche, o più di recente alla directory pool (vedere La directory pool, Sezione 2.1.10). Per scaricare il codice sorgente senza la necessità di essere addentro alla struttura dell'archivio Debian, provate un comando tipo apt-get source nomemiopacchetto.
Alcuni pacchetti, in particolare pine
, sono disponibili solamente
come sorgenti, a causa delle limitazioni delle licenze. (Recentemente è stato
fornito il pacchetto pine-tracker
per facilitare l'installazione
di Pine). Le procedure descritte in Portare un pacchetto nel sistema
stable, Sezione 6.4.10 e Creare pacchetti debian, Sezione
13.10 dovrebbero fornire tutto il necessario per compilare un pacchetto
manualmente.
Il codice sorgente potrebbe non essere disponibile, invece, per i pacchetti
delle directory contrib
e non-free
, che formalmente
non fanno parte del sistema Debian.
Normalmente i pacchetti contengono tutti i files necessari all'implementazione di una serie di comandi o di funzionalità. Esistono due tipi di pacchetti:
L'installazione del software attraverso il sistema dei pacchetti utilizza delle
"dipendenze", che sono state accuratamente costruite dal responsabile
(manutentore) del pacchetto. Le dipendenze vengono descritte nel file
control, associato a ciascun pacchetto. Ad esempio, il pacchetto
contenente il compilatore GNU C (gcc
) "dipende" dal
pacchetto binutils
che include il linker e l'assembler. Se si
prova ad installare gcc
senza aver prima installato
binutils
, il sistema di gestione dei pacchetti (dpkg) invierà un
messaggio di errore riguardo alla necessità di avere anche
binutils
e bloccherà l'installazione di gcc
. (Questo
comportamento può comunque essere scavalcato dall'utente tenace, vedere al
riguardo dpkg(8)
.) Vedere più sotto in Dipendenze, Sezione 2.2.8.
Gli strumenti Debian per la gestione dei pacchetti possono essere usati per:
Un "pacchetto" Debian, od un file dell'archivio Debian contiene gli eseguibili,le librerie e tutta la documentazione associata ad un gruppo o suite di programmi correlati. I file dell'archivio Debian, di norma, hanno il suffisso .deb.
I dettagli dei pacchetti binari Debian sono descritti nella pagina man
deb(5)
. Il loro formato interno è soggetto a cambiamenti (tra una
versione maggiore e l'altra di Debian), per cui leggete sempre
dpkg-deb(8)
prima di manipolare i.deb files.
Almeno fino a Woody, gli archivi Debian sono sempre stati manipolabili anche
dai normali comandi Unix, tipo ar
e tar
, anche quando
i comandi dpkg non erano disponibili.
Il nome di un pacchetto Debian segue la convenzione seguente:
foo_NumeroVersione-NumeroRevisioneDebian.deb
foo sta per il nome del pacchetto. Come prova, si può risalire al nome del pacchetto associato ad un archivio Debian particolare (file .deb) in uno dei seguenti modi:
VVV rappresenta il numero di versione specificato dallo sviluppatore principale. Non esiste uno standard, per cui il numero può presentarsi in formati diversi, tipo "19990513" e "1.3.8pre1".
RRR rappresenta il numero di revisione Debian e viene specificato dallo sviluppatore Debian (o da un utente qualsiasi, se decide di costruirsi il pacchetto da sè). Il numero corrisponde al livello di revisione del pacchetto Debian, quindi un nuovo numero in genere significa dei cambiamenti nel Makefile Debian (debian/rules), nel file di controllo Debian (debian/control), negli scripts di installazione o rimozione (debian/p*) oppure nei file di configurazione utilizzati con il pacchetto.
Il mantenimento di files configurabili dall'utente viene ottenuto tramite il
meccanismo dei "conffiles" Debian. I file di configurazione
dell'utente (di norma inseriti in /etc
) vengono specificati nei
conffiles all'interno del sistema dei pacchetti Debian. Il
sistema di gestione dei pacchetti garantisce che, all'aggiornamento, i file di
configurazione non vengano sovrascritti.
Quando è possibile configurare il sistema senza modificare i file che appartengono ai vari pacchetti Debian, è in genere buona cosa non modificarli, anche se sono dei "conffiles". Ciò assicura delle operazioni di aggiornamento più lisce e veloci.
Per determinare esattamente quali files saranno preservati durante un aggiornamento, lanciare:
dpkg --status package
E guardare sotto "Conffiles:".
Le specifiche riguardo al contenuto dei conffiles Debian si trovano nel Debian Policy Manual, sezione 11.7, vedere Riferimenti, Sezione 15.1.
Gli scripts di gestione Debian sono degli script eseguibili che vengono lanciati automaticamente prima o dopo l'installazione di un pacchetto. Insieme ad un file chiamato control, tutti questi files fanno parte della sezione "control" di un file Debian.
I singoli files sono:
Tutti i file di controllo possono essere localizzati nella directory
/var/lib/dpkg/info
. I files correlati con il pacchetto
foo iniziano, appunto, con il nome "foo" ed hanno le
estensioni "preinst", "postinst", ecc. a seconda della
funzione. Il file foo.list nella stessa directory elenca tutti i
files installati con il pacchetto foo. (Notate che la
localizzazione di questi files è interna a dpkg e può essere soggetta a
modifiche.)
Ad ogni pacchetto viene assegnata una priorità dai responsabili della distribuzione, come aiuto al sistema di gestione dei pacchetti. Le priorità sono:
Comprende tutti gli strumenti necessari alla riparazione di difetti di sistema.
Questi pacchetti non devono essere rimossi, pena la completa inutilizzabilità
del sistema, probabilmente nemmeno con dpkg
si riuscirebbe a
mettere le cose a posto. I sistemi con solo i pacchetti Richiesti
probabilmente sarebbero inutilizzabili, ma hanno abbastanza funzionalità per
permettere all'amministratore di sistema di fare un boot ed installare altri
programmi.
Altri pacchetti necessari ad un corretto funzionamento del sistema, senza i quali non sarebbe utilizzabile. Tra questi non sono inclusi Emacs o X11 o TeX o qualsiasi altra grossa applicazione. Qui si parla di pacchetti che costituiscono l'infrastruttura di base.
Questo è ciò che viene installato di base se l'utente non seleziona altro. Non include grosse applicazioni, però include Emacs (più un pezzo di infrastruttura che un'applicazione) ed un ragionevole sottogruppo di TeX e LaTeX (se è possibile senza X).
Comprende X11, una distribuzione completa di TeX e molte applicazioni.
Il termine pacchetto virtuale è un termine generico che si applica a tutti i pacchetti di un gruppo che provvede alla medesima funzione. Per esempio, i programmi tin e trn sono entrambi dei newsreader, in grado di soddisfare qualsiasi dipendenza di un programma che richieda un newsreader su un sistema, al fine di funzionare correttamente. Entrambi, quindi, si dice che provvedano il "pacchetto virtuale" definito news-reader.
Allo stesso modo exim e sendmail forniscono entrambi la funzionalità di un agente di trasporto posta (mail transport agent). Entrambi, quindi, provvedono al pacchetto virtuale "mail transport agent". Se uno dei due è installato, qualsiasi programma che dipenda dall'installazione di un mail-transport-agent vedrà le proprie dipendenze soddisfatte dall'esistenza di questo pacchetto virtuale.
La Debian ha un meccanismo tale che, se più di un pacchetto che fornisce lo stesso pacchetto virtuale è installato, l'amministratore di sistema è in grado di sceglierne uno come pacchetto preferito. Il comando che viene chiamato in causa èupdate-alternatives e verrà descritto in dettaglio oltre, in Comandi alternativi, Sezione 6.5.3.
Il sistema dei pacchetti Debian ha una serie di "dipendenze" che sono pensate per indicare (con un singolo termine) il livello di indipendenza di un dato Programma A a cui può operare, indipendentemente dalla esistenza di un Programma B su un dato sistema:
Informazioni più dettagliate possono essere trovate nel manuale di Packaging ed in quello di Policy.
Bisogna ricordare che dselect ha un controllo molto più raffinato sui pacchetti contrassegnati da raccomanda e suggerisce rispetto ad apt-get, che prende semplicemente tutti i pacchetti specificati da dipende e lascia quelli indicati da raccomanda e suggerisce. Entrambi i programmi nelle forme più moderne utilizzano come back-end APT.
"Pre-Depends" è una dipendenza speciale. Con la maggior parte dei
pacchetti dpkg
ne spacchetterà il file di archivio (ovvero il file
.deb), indipendentemente dal fatto che i files da cui dipendono
sono o no sul sistema. Semplificando, spacchettare il file vuol dire che
dpkg
ne estrarrà i file da installare e li metterà al loro posto.
Se qualche determinato pacchetto dipende dall'esistenza di
altri pacchetti nel sistema,dpkg
si rifiuterà di completare
l'installazione (eseguendo l'azione "configura"), finchè non saranno
installati gli altri pacchetti.
Per alcuni pacchetti, tuttavia, dpkg
si rifiuterà persino di
spacchettarli finchè certe dipendenze non vengono risolte. Tali pacchetti
"Pre-dipendono" (Pre-depend) dalla presenza di altri pacchetti. Il
progetto Debian previde questo meccanismo per supportare un aggiornamento
sicuro di sistemi dal formato a.out al formato ELF,
dove l'ordine in cui i pacchetti venivano estratti risultava
critico. Esistono altre situazioni di aggiornamenti estesi in cui questo
metodo si rivela utile, tipo pacchetti con priorità richiesta e dipendenza da
libC.
Come sopra, informazioni più dettagliate al riguardo possono essere reperite nel manuale di Packaging.
Lo stato di un pacchetto può essere "sconosciuto",
"installa", "rimuovi", "elimina" o
"mantieni". Queste etichette "voglio", indicano il volere
dell'utente riguardo ad un pacchetto (come indicato dalle azioni dell'utente
nella sezione "Scegli" di dselect
o dal richiamo diretto
dell'utente di dpkg
).
Il loro significato è il seguente:
Esistono due modi per evitare l'aggiornamento di un pacchetto, tramite
dpkg
o, in Woody, tramite APT.
Con dpkg
, dovete solo esportare la lista dei pacchetti selezionati
con:
dpkg --get-selections > selections.txt
Dopodichè modificate il file risultante selections.txt
,
cambiando la riga che contiene il pacchetto da mantenere, tipo
libc6
, da:
libc6 install
a:
libc6 hold
Salvate il file e ricaricatelo nel database di dpkg
con:
dpkg --set-selections < selections.txt
Se conoscete il nome del pacchetto da mantenere, basta eseguire:
echo libc6 hold | dpkg --set-selections
Questo processo evita l'aggiornamento dei pacchetti al momento dell'installazione di ciascun file.
Lo stesso risultato si ottiene tramite dselect
. Basta accedere
alla schermata [S]cegli, trovare il pacchetto da mantenere nello stato attuale
e premere il tasto `=' (o `H'). I cambiamenti saranno effettivi non appena
lasciata la schermata [S]cegli.
Il sistema APT nella nuova distribuzione Woody ha un meccanismo alternativo per
mantenere i pacchetti durante il processo di raccolta di un archivio,
utilizzando la Pin-Priority. Vedere la pagina man
apt_preferences(5)
, l'http://www.debian.org/doc/manuals/apt-howto/
o il pacchetto apt-howto
.
I pacchetti sorgente vengono distribuiti in una directory chiamata source e possono essere scaricati o manualmente, oppure tramite il comando
apt-get source foo
(vedere apt-get(8)
la pagina man su come settare APT all'uopo).
Per un dato pacchetto foo avete bisogno di tutti i
foo_*.dsc
, foo_*.tar.gz
e
foo_*.diff.gz
(nota bene: non esiste nessun
.diff.gz per un pacchetto Debian nativo).
Una volta presi, se avete installato il pacchetto dpkg-dev
il
seguente comando:
$ dpkg-source -x foo_version-revision.dsc
estrarrà il pacchetto in una directory denominata foo-version.
Date i seguenti comandi per compilare il pacchetto binario:
$ cd foo-versione $ su -c "pat-get update ; apt-get install fakeroot" $ dpkg-buildpackage -rfakeroot -us -uc
poi
$ su -c dpkg -i ../foo_version-revision_arch.deb
per installarlo. Vedere Portare un pacchetto nel sistema stable, Sezione 6.4.10.
Per maggiori dettagli al riguardo, leggete la "New Maintainers'
Guide", reperibile nel pacchetto maint-guide
oppure presso
http://www.debian.org/doc/manuals/maint-guide/
.
Uno degli scopi della Debian è di fornire un sentiero solido di aggiornamento ed un processo sicuro (sempre di aggiornamento), e si fa sempre del proprio meglio per rendere la nuova versione facilmente aggiornabile dalla precedente. Nel caso di qualcosa di importante da aggiungere al processo di aggiornamento, i pacchetti avvertiranno gli utenti, spesso provvedendo anche ad una soluzione ai possibili problemi.
Bisogna sempre leggere le Note di Rilascio (Release Notes), documento che
descrive i dettagli dei singoli aggiornamenti, che viene sempre inserito in
tutti i CD Debian, comunque disponibile sul web presso http://www.debian.org/releases/stable/releasenotes
oppure presso http://www.debian.org/releases/testing/releasenotes
.
Una guida pratica viene fornita in Gestione dei pacchetti in Debian, Capitolo 6. Questa sezione si occupa dei dettagli fondamentali.
Si può sempre fare un ftp anonimo od un wget
ad un archivio Debian
e sbirciare nelle directory finchè si trova il file desiderato, scaricarlo ed
infine installarlo con dpkg
. Notate che dpkg
installerà i file aggiornati al loro posto, persino su un sistema che sta
normalmente girando. Talvolta un pacchetto da aggiornare richiederà
l'installazione di un altro pacchetto aggiornato, in tal caso l'installazione
fallirà finchè/a meno che l'altro pacchetto venga installato.
Molti trovano che un approccio del genere sia troppo dispendioso in termini di tempo, dato che la Debian si evolve molto velocemente — tipicamente una dozzina o più di nuovi pacchetti vengono caricati ogni settimana. Questo numero diventa ben più grande in prossimità di un rilascio di una nuova versione. Per trattare con questa massa di pacchetti, molte persone preferiscono utilizzare programmi automatizzati. Per questo scopo, molti strumenti di gestione dei pacchetti sono disponibili.
Il sistema di gestione dei pacchetti Debian è focalizzato su due punti
principali, la manipolazione del pacchetto stesso, ed il suo recupero da un
archivio Debian.dpkg
è per il primo punto, APT e
dselect
per il secondo.
dpkg
E' il programma principale per la manipolazione dei pacchetti. Per ulteriori
informazioni, leggere la pagina man dpkg(8)
.
dpkg
è fornito con parecchi programmi supplementari di base.
dpkg-deb(1)
dpkg-ftp(1)
dpkg-mountable(1)
dpkg-split(1)
dpkg-ftp
e dpkg-mountable
sono stati resi obsoleti
dall'introduzione del sistema APT.
APT (Advanced Packaging Tool) è un'interfaccia più avanzata per il sistema
Debian di gestione dei pacchetti e consiste di vari programmi i cui nomi
iniziano tipicamente con "apt-". apt-get
,
apt-cache
e apt-cdrom
sono gli strumenti da riga di
comando per maneggiare i pacchetti. Funzionano anche come programmi backend
per l'utente di altri strumenti, come dselect
ed
aptitude
.
Per maggiori informazioni, installare apt
e leggere
apt-get(8)
, apt-cache(8)
, apt-cdrom(8)
,
apt.conf(5)
, sources.list(5)
,
apt_preferences(5)
(woody), e
/usr/share/doc/apt/guide.html/index.html
.
Esistono fonti di informazione alternative, come APT HOWTO
. Può
essere installato tramite apt-howto
in
/usr/share/doc/Debian/apt-howto/
.
apt-get upgrade e apt-get dist-upgrade prendono solo
i pacchetti elencati sotto "Dipende", mentre lasciano quelli sotto
"Raccomanda" e "Suggerisce". Per evitare ciò, usate
dselect
.
dselect
Questo programma rappresenta un'interfaccia utente basata su menu al sistema di
gestione dei pacchetti. E' particolarmente utile per prime installazioni ed
aggiornamenti su larga scala. Vedere dselect
, Sezione 6.2.3.
Per ulteriori informazioni, installare install-doc
e leggere
/usr/share/doc/install-doc/dselect-beginner.en.html
oppure
dselect
Documentation for Beginners
.
Il kernel (file system) in Debian supporta la sostituzione dei files anche mentre sono in uso.
Viene anche fornito un programma chiamato start-stop-daemon
che
viene impiegato per lanciare i demoni al boot o per fermarli al cambiamento di
runlevel del kernel (da multi-utente a singolo, o allo spegnimento della
macchina, per esempio). Lo stesso programma viene usato dagli scripts di
installazione quando un nuovo pacchetto che contiene un demone viene
installato, per fermare i demoni in funzione, e riavviarli al momento giusto.
Notare che il sistema Debian non ha bisogno della modalità singolo utente per aggiornare un sistema in funzione.
Se avete scaricato i file .deb nel vostro disco rigido (cosa
assolutamente non necessaria, vedere sopra per la descrizione di
dpkg-ftp
o di APT), dopo l'installazione dei pacchetti potete
rimuoverli dal vostro sistema.
Se si usa APT, i file vengono tenuti nella directory
/var/cache/apt/archives/
. Potete cancellarli dopo l'installazione
(apt-get clean), oppure copiarli sulla stessa directory
/var/cache/apt/archives/
di un'altra macchina, per evitare un
nuovo download durante la successiva installazione.
dpkg
mantiene una registrazione dei pacchetti scompattati,
configurati, rimossi e/o eliminati, ma (al momento) non tiene nessuna
registrazione dell'attività scritta su terminale durante tali manipolazioni.
Il metodo più semplice per aggirare questo impedimento è di lanciare una
qualsiasi sessione di dpkg
/dselect
apt-get
all'interno del programma script(1)
.
Come ogni buon appartenente alla famiglia degli Unix, Debian esegue il boot eseguendo il programma init. Il file di configurazione di init (che è /etc/inittab) specifica che il primo script da eseguire deve essere /etc/init.d/rcS. Questo script controlla e monta i filesystems, carica i moduli, lancia i servizi di rete, imposta l'orologio, esegue altre inizializzazioni e poi lancia tutti gli altri script (tranne quelli con `.' nel filename) localizzati in /etc/rc.boot/. Tutti gli script in quest'ultima directory sono riservati all'amministratore di sistema, ed il loro utilizzo nei pacchetti è deprecato.
Dopo il completamento del processo di boot, init esegue tutti gli script contenuti nella directory specificata dal runlevel di default (dato dalla riga per id in /etc/inittab). Come la maggior parte degli Unix compatibili con il System V, Linux ha 7 runlevels:
I sistemi Debian hanno id=2, che indica che il runlevel di default sarà il 2 quando si entra in modalità multiutente e verranno lanciati gli scripts localizzati in /etc/rc2.d/.
Di fatto gli scripts localizzati in qualsiasi directory denominata
/etc/rcN.d/
sono semplici link simbolici che si
riferiscono a scripts localizzati in /etc/init.d/
. Tuttavia, i
nomi dei files in ciascuna directory
/etc/rcN.d/
sono selezionati in modo da indicare il
modo in cui gli scripts in /etc/init.d/
saranno
lanciati. Entrando nello specifico, prima di entrare in qualsiasi runlevel
tutti gli script che iniziano con 'K' vengono lanciati; questi scripts chiudono
(uccidono) i servizi. Poi vengono lanciati tutti quelli che iniziano per 'S',
che fanno partire i servizi. Il numero a due cifre che segue la lettera 'K' o
'S' indica l'ordine nel quale lo script verrà lanciato. Script con numeri più
bassi vengono eseguiti prima.
Questo approccio funziona perchè gli scripts contenuti in /etc/init.d/ accettano un argomento che può essere "start", "stop", "reload", "restart" o "force-reload" eseguendo poi il compito indicato dallo specifico argomento. Questi scripts possono essere utilizzato anche dopo il boot del sistema per controllare svariati processi.
Per esempio, lanciato con l'argomento "reload", il comando
/etc/init.d/sendmail reload
invia al demone sendmail un segnale di rileggere il proprio file di configurazione.
Debian non usa rc.local in stile BSD per personalizzare il processo di boot; fornisce, invece, il seguente meccanismo per la personalizzazione.
Supponiamo che un sistema debba lanciare lo script foo all'avvio, o all'ingresso di uno specifico (System V) runlevel. In tal caso l'amministratore di sistema deve:
/etc/init.d/
.
update-rc.d
con gli argomenti
appropriati, per impostare i collegamenti (specificati da riga di comando) fra
le directory rc?.d e /etc/init.d/foo
. Qui
? è un numero compreso fra 0 e 6 e corrisponde a ciascun runlevel.
Il comando update-rc.d imposterà i collegamenti fra i files delle
directory rc?.d e lo script contenuto in
/etc/init.d/
. Ogni collegamento inizia con una 'S' o una 'K',
seguite da un numero, seguiti dal nome dello script. Gli scripts che iniziano
con 'S' in /etc/rcN.d/
verranno eseguiti quando si
entra nel runlevel N. Quelli che iniziano con 'K' verranno eseguiti
lasciando il runlevel N.
Si può, per esempio, lanciare lo script foo al boot mettendolo
/etc/init.d/
ed impostando i collegamenti con update-rc.d
foo defaults 19. L'argomento defaults fa riferimento ai
runlevels di default, che sono quelli da 2 a 5. L'argomento 19
assicura che lo script foo verrà chiamato prima di qualsiasi altro
script con il numero 20 o maggiore.
Debian offre parecchie opportunità per soddisfare le esigenze (e i desideri) degli amministratori di sistema, senza per questo renderlo inutilizzabile.
dpkg-divert
, vedere Il
comando dpkg-divert
, Sezione 6.5.1.
equivs
, vedere Il pacchetto
equivs
, Sezione 6.5.2.
update-alternative
, vedere Comandi alternativi, Sezione
6.5.3.
make-kpkg
può accettare svariati boot loaders. Vedere
make-kpkg(1)
.
Tutti i file in /usr/local/
appartengono all'amministratore di
sistema e Debian non li toccherà. Gran parte (o tutti) i file in
/etc
sono conffiles e Debian non li sovrascriverà in
caso di aggiornamento a meno che l'amministratore non lo richieda
espressamente.
Il sistema Debian è internazionalizzato e fornisce il supporto per la visualizzazione e la scrittura dei caratteri in molte lingue, sia da console che sotto X. Molti documenti, pagine manuali e messaggi di sistema sono stati tradotti in numero sempre crescente di lingue. Durante l'installazione Debian chiede all'utente di scegliere la lingua di installazione (e talvolta una variante locale della stessa).
Se il vostro sistema non supporta tutte le caratteristiche della lingua di cui avete bisogno, o se dovete cambiare la lingua od installare una diversa tastiera che supporti la vostra lingua, andate a leggere Localizzazione e supporto delle varie lingue, Sezione 9.7.
Vedere Il kernel Linux su Debian, Capitolo 7.
Bisogna comprendere la politica debian nei confronti degli headers.
Le librerie C Debian sono compilate con le versioni stabili più recenti degli headers del kernel.
Ad esempio, le versione Debian-1.2 usava la versione 5.4.13 degli headers.
Questa pratica è in contrasto con i pacchetti sorgente del kernel distribuiti
in tutti gli archivi Linux FTP, pacchetti che usano versioni persino più
recenti degli headers. Gli headers distribuiti con i sorgenti del kernel sono
localizzati in /usr/include/linux/include/
.
Se avete bisogno di compilare un programma con headers più recenti di quelli di
quelli forniti da libc6-dev
, quando compilate dovete aggiungere
alla riga di comando -I/usr/src/linux/include/. Un problema del
genere è uscito, per esempio, quando si è creato il pacchetto del demone
automounter (amd
). Quando i nuovi kernels cambiavano alcune
istruzioni relative al NFS, amd
aveva necessità di esserne al
corrente. Ciò ha richiesto l'inclusione degli headers più recenti.
Gli utenti che desiderano (o devono) compilare un kernel personalizzato, sono
incoraggiati a scaricare il pacchetto kernel-package
. Il
pacchetto contiene lo script per compilare il pacchetto del kernel e fornisce
le capacità di creare un pacchetto Debian kernel-image, semplicemente dando il
comando
make-kpkg kernel_image
dalla directory principale del kernel sorgente. L'aiuto è disponibile dando il comando
make-kpkg --help
o tramite la pagina man make-kpkg(8)
e Il kernel Linux su Debian, Capitolo 7.
L'utente deve scaricarsi a parte il sorgente per il kernel, sia esso il più
recente o quello di scelta, dall'archivio Linux preferito, a meno che un
pacchetto kernel-source-version non sia disponibile (dove
version sta per la versione del kernel). Lo script di boot Debian
initrd
richiede una speciale patch del kernel, chiamata
initrd
; vedere http://bugs.debian.org/149236
.
Le istruzioni dettagliate per usare il pacchetto kernel-package
sono fornite nel file /usr/doc/kernel-package/README.
Per utilizzare boot loaders alternativi, tipo grub
o
loadlin
, copiate il kernel compilato bzimage
in
un'altra locazione (tipo /boot/grub
od una partizione MS-DOS).
Questo compito è fortemente aiutato dal pacchetto Debian
boot-floppies
, reperibile normalmente nella sezione
admin dell'archivio FTP Debian. Gli script di shell di questo
pacchetto producono dei boot floppies nel formato syslinux
.
Questi sono floppy formattati MS-DOS i cui master boot records sono stati
modificati in maniera tale da fare il boot di Linux (o di qualsiasi altro S.O.
sia stato definito nel file syslinux.cfg del floppy) direttamente.
Altri script del pacchetto producono dei dischi root di emergenza e possono
persino riprodurre i dischi base.
Maggiori informazioni in /usr/doc/boot-floppies/README
dopo
l'installazione del pacchetto boot-floppies
.
Il pacchetto Debian modconf
fornisce uno script di shell
(/usr/sbin/modconf
) che può essere utilizzato per personalizzare
la configurazione dei moduli. Lo script presenta un'interfaccia a menu,
chiedendo all'utente particolari circa i device drivers caricabili presenti sul
proprio sistema. La risposte vengono utilizzate per personalizzare il file
/etc/modules.conf
(che elenca alias ed altri argomenti che devono
essere utilizzati insieme ai vari moduli), tramite i files in
/etc/modutils/
, e /etc/modules
(che elencano i moduli
che devono essere caricati al boot).
Così come i (nuovi) files Configure.help ora disponibili per aiutare nella
compilazione di kernels personalizzati, il pacchetto modconf
arriva con tutta una serie di file di aiuto (in
/usr/share/modconf/
) che forniscono informazioni dettagliate sugli
argomenti appropriati da dare a ciascun modulo. Vedere Kernel 2.4 modulare, Sezione 7.2
per gli esempi.
Si, lo script kernel-image-NNN.prerm controlla se il kernel attualmente in uso è lo stesso che state tentando di disinstallare. Perciò potete rimuovere pacchetti kernel che non volete più tramite il comando:
dpkg --purge --force-remove-essential kernel-image-NNN
(sostituite NNN con la versione ed il numero di revisione del vostro kernel, naturalmente)
La guida Debian
1.07-6, mer giu 23 21:21:03 UTC 2004osamu@debian.org
dsewell@virginia.edu
mc0315@mclink.it