Questo capitolo fornisce le informazioni fondamentali sul sistema debian per i 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 una delle numerose
directory su ciascun Mirror
Debian raggiungibili tramite FTP o HTTP.
Queste sono le directory presenti su ciascun mirror, sotto la directory /debian/:
/dists/:Contents-*.gz, ed i files
Packages.gz sono ancora qui.
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
collegamento simbolico alla directory reale, tramite un nome proprio nella
directory dists.
Le voci dei pacchetti per la distribuzione stable, Debian Woody
(3.0r0), vengono inserite nella directory stable (collegamento
simbolico 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 Linee guida Debian per
il Software Libero (DFSG) (disponibile anche come
/usr/share/doc/debian/social-contract.txt installato da
debian-doc).
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.
stable/contrib/: Contiene i pacchetti che sono di per sè DFSG-free
e DFSG-liberi, ma dipendono in qualche modo da un pacchetto che non
è DFSG-libero.
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 dei bachi della distribuzione stable è riportato
in sulla pagina Web Problemi di
Stable.
Le voci dei pacchetti per la distribuzione testing, Debian Sarge,
sono registrate nella directory testing (collegamento simbolico 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://www.debian.org/devel/testing.
Lo stato aggiornato della distribuzione testing è riportato presso:
Le voci dei pacchetti della distribuzione unstable, sempre con
nome in codice "Sid", sono registrate nella directory
unstable (collegamento simbolico 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 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 collegamento simbolico
frozen, così frozen non era una distribuzione, ma
solo uno stadio di sviluppo della distribuzione testing.)
Viene tenuto un registro dei bug della distribuzione frozen che possono impedire il rilascio di un pacchetto o di tutta la distribuzione. Una volta che il conteggio dei bug 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 collegamento simbolico a
woody e testing è un collegamento simbolico a
sarge. Ciò significa che Woody è la distribuzione
attualmente stable e Sarge è l'attuale testing.
unstable è un collegamento 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, "Potato" per la 2.2, "Woody" per la 3.0 e "Sarge" per la 3.1.
Finora sono stati presi dai nomi dei personaggi del film Toy Story della Pixar.
pool
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 file: 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 sono in grado di gestire la cosa
senza problemi. Se volete maggiori informazioni, andate a vedere RFC:
implementazione dei pool dei pacchetti.
Quando il Sid attuale non esisteva, l'organizzazione dell'archivio Debian aveva
un problema principale: l'assunto che quando un'architettura veniva creata
nell'attuale unstable, 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 collegamento 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 su ciascun Mirror Debian, gli archivi per
le distribuzioni più vecchie, tipo Scollegamento , 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 file necessari all'implementazione di una serie di comandi o di funzionalità. Esistono due tipi di pacchetti:
dpkg; i dettagli si possono vedere alla pagina di manuale
corrispondente.
dpkg-source impacchetta e spacchetta questo tipo di
pacchetti. Per i dettagli, ovviamente, la pagina man corrispondente.
L'installazione del software attraverso il sistema dei pacchetti utilizza delle
"dipendenze", che sono state dichiarate 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 collegamento 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).) Per dettagli aggiuntivi, vedere più sotto in Dipendenze dei pacchetti, 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. [1]
I dettagli dei pacchetti binari Debian sono descritti nella pagina di manuale
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 file.
Almeno fino a Sarge, 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_ver-rev_arch.deb
Dove in genere foo sta per il nome del pacchetto. ver è la versione del programma originale, rev è il numero di revisione Debian e arch è l'architettura per la quale il pacchetto è stato compilato. I file vengono facilmente rinominati, naturalmente. Potete scoprire quale pacchetto è realmente contenuto in un dato file di none filename dando il comando seguente:
dpkg --info filename
Il numero di revisione Debian viene specificato dallo sviluppatore Debian o da chiunque compili il pacchetto. Un cambio nel numero di revisione in genere indica che qualche aspetto nel pacchetto è cambiato.
I file che sono considerati modificabili dall'amministratore locale si trovano
in /etc. Le linee guida Debian prescrivono che tutte le modifiche
ai file localmente configurabili vengano mantenute attraverso gli aggiornamenti
dei pacchetti.
Se una versione predefinita di un file localmente configurabile viene fornita con il pacchetto stesso, allora il file viene etichettato come un "conffile". Il sistema di gestione dei pacchetti non aggiorna i conffile che sono stati modificati dall'amministratore dopo l'ultima installazione del dato pacchetto senza prima aver chiesto il permesso dell'amministratore stesso. D'altro canto, se il conffile non è stato modificato, allora verrà aggiornato insieme al resto del pacchetto. Ciò è sempre auspicabile, così è vantaggiorso minimizzare le modifiche ai conffile.
Per elencare i conffile appartenenti ad un dato pacchetto, lanciare:
dpkg --status package
L'elenco segue la riga "Confflies".
Per maggiori informazioni sui conffile potete leggere la sezione del Debian Policy Manual intitolata "Configuration files" (Vedere Riferimenti, Sezione 15.1).
Gli script 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 file fanno parte della sezione
"control" di un file Debian.
I singoli file sono:
Tutti i file di controllo possono essere localizzati nella directory
/var/lib/dpkg/info. I file 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
file installati con il pacchetto foo. (Notate che la
localizzazione di questi file è 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.
Notate le differenze fra "Priority: required", "Section:
base" ed "Essential: yes" nella descrizione dei pacchetti.
"Section: base" significa che il pacchetto viene installato prima
tutti su un nuovo sistema. Molti dei pacchetti in "Section: base"
hanno "Priority: required" o almenot "Priority: important"
e molti di loro sono etichettati con "Essential: yes".
"Essential: yes" significa che il pacchetto richiede di specificare
un'ulteriore opzione force al sistema di gestione dei pacchetti, tipo
dpkg quando viene rimosso dal sistema. Per esempio,
libc6, mawk e makedev sono
"Priority: required" and "Section: base" ma non
"Essential: yes".
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 exim4, sendmail e
postfix forniscono la funzionalità di un agente di trasporto posta
(mail transport agent). Perciò, provvedono al pacchetto virtuale mail
transport agent. Se uno di loro è installato, qualsiasi programma che
dipenda dall'installazione di un agente di trasporto posta 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 utilizzate per esprimere il fatto che un pacchetto, per funzionare, o per funzionare meglio, ha bisogno dell'installazione di un altro pacchetto:
Informazioni più dettagliate possono essere trovate nel Packaging Manual e nel Policy Manual.
Notate 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.
dpkg conigura sempre un pacchetto da cui ne Dipende un altro prima
di configurare quast'ultimo. Tuttavia, dpkg in genere
spacchetterà il file seguendo un ordine arbitrario, indipendentemente dalle
dipendenze. (Spacchettare il file vuol dire che estrarre i file e metterli al
posto giusto). Se, però un pacchetto Pre-Dipende da un altro,
allora quast'ultimo veràà spacchettato e configurato prima che quello che ne
Pre-Dipende sia anche solo spacchettato. [2] L'uso di questo tipo di dipendenza è ridotto al minimo.
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, da Woody in poi, 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 di manuale
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 impostare 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 "apt-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 ed un processo
sicuro di aggiornamento. Il sistema di gestione dei pacchetti avverete
l'amministratore delle modifiche importanti e talvolta gli chiede di prendere
delle decisioni. Dovreste leggere anche le Note di Rilascio; vengono fornite
con tutti i CD Debian e sono disponibili sul WWW presso http://www.debian.org/releases/stable/releasenotes
oppure http://www.debian.org/releases/testing/releasenotes.
Una guida pratica viene fornita in Gestione dei pacchetti in Debian, Capitolo 6. Questa sezione fornisce una panoramica generale, cominciando con gli strumenti di gestione dei pacchetti.
dpkg
E' il programma principale per la manipolazione dei pacchetti. Per ulteriori
informazioni, leggere la pagina di manuale dpkg(8).
dpkg è fornito con parecchi programmi supplementari di base.
dpkg-deb: Manipola i files .deb.
dpkg-deb(1)
dpkg-ftp: Vecchio comando per il recupero dei pacchetti.
dpkg-ftp(1)
dpkg-mountable: Vecchio comando per il recupero dei pacchetti.
dpkg-mountable(1)
dpkg-split: Divide grossi pacchetti in files più piccoli.
dpkg-split(1)
dpkg-ftp e dpkg-mountable sono stati resi obsoleti
dall'introduzione del sistema APT.
APT (Advanced Packaging Tool) è un'interfaccia 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.4.
Per ulteriori informazioni, installare install-doc e leggere
/usr/share/doc/install-doc/dselect-beginner.en.html oppure
Documentazione
per dselect per Principianti.
Il kernel (filesystem) in Debian supporta la sostituzione dei file anche mentre sono in uso. Quando i pacchetti vengono aggiornati, tutti i servizi forniti da essi vengono riavviati se sono configurati per girare nel runlevel corrente. Il sistema Debian non ha bisogno della modalità singolo utente per aggiornare un sistema in funzione.
Se avete scaricato i pacchetti 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, ecc. all'interno del programma script(1).
init
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.
Quello che accade poi dipende se è installato il pacchetto sysv-rc
oppure file-rc. Quanto segue assume che sia installato
sysv-rc. (file-rc il proprio script
/etc/init.d/rcS ed usa un file invece che collegamenti simbolici
nelle directory rc per controllare quali servizi siano stati avviati ed in
quali runlevel.)
Il file /etc/init.d/rcS del pacchetto sysv-rc lancia
tutti gli script in /etc/rcS.d/ per eseguire l'inizializzazione,
tipo controllo e montaggio dei filesystem, caricamento dei moduli, lancio dei
servizi di rete, impostazione dell'orologio, e così via. Poi, per
compatibilità, lancia tutti i file (tranne quelli con `.' nel filename)
localizzati in /etc/rc.boot/. Quest'ultima è riservata
all'amministratore di sistema, ed il suo utilizzo è deprecato. Vedere Inizializzazione del sistema, Sezione
9.1 e System run
levels and init.d scripts nel Debian Policy Manual per maggiori
informazioni.
Debian non usa una directory rc.local in stile BSD.
Dopo il completamento del processo di boot, init lancia tutti i
servizi configurati per girare nel runlevel predefinito. Questo è definito
dalla riga per id in /etc/inittab. Debian arriva con
id=2.
Debian usa i seguenti runlevel:
I runlevel 7, 8, e 9 possono essere utilizzati, ma le loro directory rc non vengono popolate quando i pacchetti vengono installati.
Scambiate i runlevel mediante il comando telinit.
Quando si entra in un runlevel tutti gli script in
/etc/rcrunlevel.d/ vengono eseguiti. La prima lettera
del nome determina il modo in cui lo script viene lanciato:
quelli che iniziano con K vengono lanciati con l'argomento
stop. Quelli che iniziano per S vengono lanciati con
l'argomento start. Gli script vengono eseguiti in ordine
alfabetico; per cui quelli "stop" vengono lanciati prima di quelli
"start" e i numeri a due cifre che seguono K o
S determinano l'ordine in cui venono eseguiti.
Gli script in /etc/rcrunlevel.d sono infatti semplici
collegamenti simbolici agli script in /etc/init.d/. Essi
accettano anche argomenti tipo "restart" e "force-reload";
questi ultimi metodi possono essere utilizzati dopo che un sistema è stato
avviato per riavviare i servizi o forzarli a ricaricare i loro file di
configurazione.
Per esempio:
# /etc/init.d/exim4 reload
La personalizzazione dei runlevel è un compito avanzato di amministrazione di sistema. Il suggerimento seguente vale per gran parte dei servizi.
Per abilitare il servizio service nel runlevel R create
il collegamento simbolico
/etc/rcR.d/Sxyservice con
obiettivo ../init.d/service. Il numero di sequenza
xy dovrebbe essere quello che è stato assegnato al servizio quando
il pacchetto è stato installato.
Per disabilitare il servizio, rinominate il the collegamento simbolico in maniera che il nome inizi con K invece che con S ed il suo numero di sequenza sia 100 meno xy.
E' conveniente usare un editor di runlevel, come sysv-rc-conf o
ksysv per questi scopi.
E' possibile cancellare il collegamento simbolico S ad un servizio
in una data directory di un dato runlevel invece di rinominarlo. Ciò non
disabilita il servizio, ma lo lascia in uno stato "fluttuante",
finchè il sistema di inizio sysv-rc è interessato: al cambio di
runlevel il servizio non sarà nè lanciato nè fermato, ma verrà lasciato così
com'è, che stia girando o no. Notate comunque che un servizio lasciato in uno
stato tale verrà lanciato se il pacchetto corrispondente verrà aggiornato, che
girasse o meno prima dell'aggiornamento. Questo è un limite noto del sistema
Debian attuale. Notate anche che dovreste mantenere i collegamenti simbolici
K di un servizio nei runlevel 0 e 6. Se cancellate tutti i
collegamenti simbolici di un servizio, allora durante un aggiornamento il
pacchetto corrispodente ripristinerà tutti i collegamenti simbolici al loro
stato predefinito iniziale.
Not è consigliabile modificare i collegamenti simbolici in
/etc/rcS.d/.
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) e Il
metodo Debian standard, Sezione 7.1.1.
Tutti i file in /usr/local/ appartengono all'amministratore di
sistema e Debian non li toccherà. Gran parte dei 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 di 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 (l10n), Sezione 9.7.
Vedere Il kernel Linux su Debian, Capitolo 7.
Bisogna comprendere le linee guida Debian nei confronti degli header.
Le librerie C Debian sono compilate con le versioni stabili più recenti degli header del kernel.
Ad esempio, le versione Debian-1.2 usava la versione 5.4.13 degli header.
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 header. Gli header distribuiti con i sorgenti del kernel sono
localizzati in /usr/include/linux/include/.
Se avete bisogno di compilare un programma con header 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 kernel cambiavano alcune
istruzioni relative al NFS, amd aveva necessità di esserne al
corrente. Ciò ha richiesto l'inclusione degli header 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 di manuale 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/share/doc/kernel-package/README.gz.
Per utilizzare boot loader 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 floppy nel formato syslinux. Questi
sono floppy formattati MS-DOS i cui master boot record 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 file in
/etc/modutils/, e /etc/modules (che elencano i moduli
che devono essere caricati al boot).
Così come i (nuovi) file Configure.help ora disponibili per
aiutare nella compilazione di kernel 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
CVS, lun apr 3 22:57:30 UTC 2005osamu@debian.orgdsewell@virginia.edumc0315@mclink.it