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

La guida Debian
Capitolo 2 - Nozioni fondamentali della Debian


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.


2.1 Gli archivi Debian


2.1.1 Struttura della directory

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/:
Contiene le "distribuzioni" ed era il luogo canonico di accesso dei pacchetti disponibili nelle versioni rilasciate e pre-rilascio. Alcuni vecchi pacchetti ed i files Packages.gz sono ancora qui.
/pool/:
Nuova locazione, che contiene fisicamente tutti i pacchetti, sia quelli della versione rilasciata, che quelli pre-rilascio.
/tools/:
Utilità DOS per creare dischetti boot, partizionare il disco rigido, comprimere/decomprimere i files e lanciare Linux.
/doc/:
La documentazione base, come le FAQ, le istruzioni per la notifica dei bachi, ecc.
/indices/:
I files dei Manutentori, ed i files override.
/project/:
In gran parte materiale solo per sviluppatori, tipo:
project/experimental/:
Pacchetti e strumenti ancora in via di sviluppo, in fase alfa. I normali utenti non dovrebbero utilizzare i pacchetti qui contenuti, che possono essere pericolosi persino per i più esperti.
project/orphaned/:
Pacchetti lasciati dai loro vecchi manutentori e tolti dalla distribuzione.

2.1.2 Distribuzioni

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.


2.1.3 La distribuzione stable

E' contenuta nella directory stable:

Le voci dei pacchetti per la distribuzione stable, Debian Sarge (3.1r0), vengono inserite nella directory stable (symlink a Sarge):

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.


2.1.4 La distribuzione testing

Le voci dei pacchetti per la distribuzione testing, Debian Etch, sono registrate nella directory testing (symlink a Etch) 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:


2.1.5 La distribuzione unstable

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.


2.1.6 La distribuzione frozen

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.


2.1.7 Codice dei nomi della distribuzioni Debian

I nomi delle directory localizzate fisicamente nella directory dists, come Sarge e Etch, 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 Sarge e testing è un link simbolico a Etch. Ciò significa che Sarge è la distribuzione attualmente stable e Etch è l'attuale testing.

unstable è un link simbolico permanente a sid, dato che sid è sempre la distribuzione unstable.


2.1.8 Nomi in codice usati in passato

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.


2.1.9 Da dove vengono i nomi delle distribuzioni?

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


2.1.10 La directory 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 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.


2.1.11 Alcune note storiche su sid

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


2.1.12 Pacchetti caricati in 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.


2.1.13 Recuperare un vecchio pacchetto

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


2.1.14 Sezioni per architettura

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.

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.


2.1.15 Il codice sorgente

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.


2.2 Il sistema di gestione dei pacchetti Debian


2.2.1 Panoramica dei pacchetti 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:


2.2.2 Il formato dei pacchetti Debian

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.


2.2.3 Convenzioni nei nomi dei pacchetti Debian

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.


2.2.4 Mantenimento della configurazione locale

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.


2.2.5 Scripts di gestione Debian

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:

preinst
Questo script viene eseguito prima che il pacchetto venga estratto dal file Debian (.deb). Molti script "preinst" interrompono i servizi per i pacchetti che devono essere aggiornati fino a che la loro installazione o aggiornamento non sono completati (a seguire dell'esecuzione con successo dello script "postinst").
postinst
Questo script tipicamente completa ogni configurazione richiesta dal pacchetto foo dopo che foo è stato estratto dal suo file Debian (.deb). Spesso gli scripts "postinst" richiedono all'utente determinate azioni e/o lo avvertono che, qualora accettasse le impostazioni di base, deve ricordarsi di riconfigurare il pacchetto se la situazione lo richiede. Molti scripts "postinst", poi, eseguono tutti i comandi necessari a lanciare o far ripartire i servizi, dopo che il pacchetto è stato aggiornato o installato.
prerm
Questo script ferma tutti i demoni associati con un pacchetto. Viene eseguito prima della rimozione di file associati ad un determinato pacchetto.
postrm
Modifica i links od altri files correlati a foo, e/o rimuove i files creati da quel pacchetto.(Vedere anche Pacchetti Virtuali, Sezione 2.2.7.)

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


2.2.6 Priorità

Ad ogni pacchetto viene assegnata una priorità dai responsabili della distribuzione, come aiuto al sistema di gestione dei pacchetti. Le priorità sono:


2.2.7 Pacchetti Virtuali

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.


2.2.8 Dipendenze

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.


2.2.9 Cosa significa Pre-Depends

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


2.2.10 Lo stato dei pacchetti

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:


2.2.11 Evitare l'aggiornamento dei pacchetti

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.


2.2.12 Pacchetti sorgente

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


2.2.13 Compilare pacchetti binari dai sorgenti

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.


2.2.14 Creare nuovi pacchetti Debian

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


2.3 Aggiornare un sistema Debian

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.


2.3.1 Metodi per aggiornare un sistema Debian

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.


2.3.2 Panoramica degli strumenti di gestione dei pacchetti

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.


2.3.3 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-ftp e dpkg-mountable sono stati resi obsoleti dall'introduzione del sistema APT.


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


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


2.3.6 Aggiornare un sistema in funzione

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.


2.3.7 File .deb scaricati e tenuti in cache

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.


2.3.8 Tenere una registrazione dell'aggiornamento

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


2.4 La sequenza di boot della Debian


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


2.4.2 Runlevels

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.


2.4.3 Personalizzare il processo di boot

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:

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.


2.5 Supportare le differenze

Debian offre parecchie opportunità per soddisfare le esigenze (e i desideri) degli amministratori di sistema, senza per questo renderlo inutilizzabile.

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.


2.6 Internazionalizzazione

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.


2.7 Debian ed il kernel

Vedere Il kernel Linux su Debian, Capitolo 7.


2.7.1 Compilare un kernel da un sorgente non-Debian

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.


2.7.2 Gli strumenti per compilare un kernel personalizzato.

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.


2.7.3 Boot loaders alternativi

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


2.7.4 Boot floppy personalizzato

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 .


2.7.5 Funzioni speciali per trattare con i moduli

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.


2.7.6 Disinstallare un vecchio pacchetto kernel

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)


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

La guida Debian

1.07-12, mer set 8 02:54:31 UTC 2004

Osamu Aoki osamu@debian.org
Editor: David Sewell dsewell@virginia.edu
Traduzione italiana: Davide Di Lazzaro mc0315@mclink.it
Autori, Sezione A.1