1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<HTML LANG="it">
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html">
<META NAME="Generator" CONTENT="Alml">
<META NAME="Description" CONTENT="GNU/Linux e altro software libero">
<META NAME="Keywords" CONTENT="Linux, GNU/Linux, Unix, software, software libero, free software">
<META NAME="Author" CONTENT="Daniele Giacomini daniele @ swlibero.org">
<META NAME="Date" CONTENT="2001.08.18 ">
<META NAME="Resource-type" LANG="en" CONTENT="Document" >
<META NAME="Revisit-after" LANG="en" CONTENT="15 days" >
<META NAME="Robots" CONTENT="ALL" >
<TITLE> Appunti di informatica libera</TITLE>
<LINK REL="stylesheet" TYPE="text/css" HREF="a2.css">
<LINK REL="Start" TITLE="Start" HREF="a2.html">
<LINK REL="Prev" TITLE="Previous" HREF="a230.html">
<LINK REL="Next" TITLE="Next" HREF="a232.html">
</HEAD>
<BODY>
<P>
<A HREF="a232.html">[successivo]</A>
<A HREF="a230.html">[precedente]</A>
<A HREF="a2.html">[inizio]</A>
<A HREF="a2506.html">[fine]</A>
<A HREF="a21.html">[indice generale]</A>
<A HREF="a26.html">[violazione GPL]</A>
<A HREF="a2504.html">[licenze]</A>
<A HREF="a2505.html">[indice analitico]</A>
<A HREF="a29.html">[tomo]</A>
<A HREF="a229.html">[parte]</A>
</P>
<HR>
<DIV>
<H1>Capitolo 17. <A NAME="title359"></A><A NAME="anchor424"></A> Pacchetti applicativi confezionati appositamente per le distribuzioni GNU/Linux <A NAME="index1789"></A> </H1>
<P>Ogni distribuzione GNU/Linux utilizza un metodo per il confezionamento dei pacchetti (blocchi) che compongono l'intero sistema. Il problema principale è quello di tenere traccia della collocazione dei file di ogni applicazione, delle sue dipendenze da altri pacchetti e di permetterne l'aggiornamento o l'eliminazione senza danneggiare il sistema e senza lasciare file ignoti inutilizzati.</P>
<P>La distribuzione GNU/Linux particolare può avere un'attenzione differente rispetto alla preparazione e alla gestione del sistema che si occupa di installare e disinstallare questi pacchetti. È il caso di citare la distribuzione <A NAME="index1790"></A>Debian, a questo proposito, in cui tale sistema è particolarmente complesso. Naturalmente, una gestione troppo semplificata dei pacchetti di applicativi è un incentivo all'utilizzo della distribuzione per un principiante, ma poi tutto questo si traduce in gravi difficoltà nel momento in cui si vuole aggiornare la distribuzione, o semplicemente si desidera fare qualcosa di più rispetto al solito.</P>
<H2>17.1 <A NAME="title360"></A><A NAME="anchor425"></A>
Distinguere tra «pacchetti» e «archivi» </H2>
<P>Per evitare di fare confusione, sarebbe bene distinguere tra «il pacchetto», che rappresenta un componente installato, da installare, o da eliminare dal sistema, rispetto al suo contenitore, ovvero «l'archivio». Per esempio, si può dire che l'archivio <CODE>make_3.77-4.deb</CODE> contenga il pacchetto <SAMP>make</SAMP> nella versione 3.77-4.</P>
<P>Purtroppo, questa distinzione non viene utilizzata da tutti; ci sono distribuzioni in cui si parla indifferentemente di «pacchetto» per fare riferimento all'archivio che lo contiene e a ciò che si ottiene installandolo. Questa anomalia, poi, la si riscontra anche nelle sigle usate nelle opzioni della riga di comando, dove potrebbe capitare che si utilizzi la lettera «p» (<EM>package</EM>) per fare riferimento ai file degli archivi.</P>
<H2>17.2 <A NAME="title361"></A><A NAME="anchor426"></A>
Binari e sorgenti </H2>
<P>Gran parte del software distribuito con i sistemi GNU/Linux è sottoposto alla licenza GNU-GPL (<EM>GNU General Public License</EM>, appendice <A HREF="a2494.html#anchor7226">F</A>), che impone la disponibilità dei sorgenti. Per questo motivo, una distribuzione GNU/Linux, oltre a organizzare i pacchetti compilati e archiviati opportunamente, quando richiesto dalla licenza, deve mettere a disposizione i sorgenti, assieme alle modifiche eventuali, generalmente in forma di <A NAME="index1791"></A>file di differenze. Si distingue così tra pacchetti binari (archiviati in qualche modo) e pacchetti sorgenti.</P>
<P>Il pacchetto binario si compone dei file già compilati e pronti per essere collocati dove previsto. Il pacchetto sorgente è qualcosa di diverso: contiene l'archivio originale dell'applicativo (quello dei sorgenti), assieme a tutte le informazioni necessarie per modificarlo e per compilarlo nel modo più appropriato per la distribuzione GNU/Linux in cui deve essere installato. Inoltre, dovrebbe contenere le informazioni necessarie a generare il pacchetto binario relativo.</P>
<P>In generale, quando si parla di «pacchetti», si fa riferimento implicitamente a quelli contenenti i binari, o comunque i file finali da installare.</P>
<H2>17.3 <A NAME="title362"></A><A NAME="anchor427"></A>
Interdipendenza tra i pacchetti </H2>
<P>I pacchetti, ovvero i vari blocchi in cui è suddiviso il software, devono convivere in modo armonico nel sistema. Questo fatto sembra ovvio, ma la cosa più difficile da definire è proprio la relazione corretta tra questi.</P>
<P>Con il termine «dipendenza», si fa riferimento al fatto che un pacchetto può dipendere da altri per il suo funzionamento. In pratica, se il pacchetto «A» richiede che sia presente anche il pacchetto «B», si dice che «A» dipende da «B». Con il termine «incompatibilità», si fa riferimento al fatto che un pacchetto non può coesistere con un altro per qualche ragione. Per esempio, se il pacchetto «A» non può stare assieme a «C» si dice che «A» è incompatibile con «C».</P>
<P>I due concetti sono abbastanza semplici, ma a questi se ne aggiunge un altro: la dipendenza prima dell'installazione. Infatti, un pacchetto potrebbe dipendere da un altro che deve essere già presente prima che questo venga installato. A questo proposito, si parla a volte di «pre-dipendenza». Questo tipo di dipendenza impone quindi un ordine nell'installazione dei pacchetti.</P>
<P>In certi casi, un pacchetto può dipendere da una funzionalità che può essere offerta da diversi altri pacchetti. Per esempio, un programma può richiedere la presenza del comando <SAMP>mail</SAMP> per inviare dei messaggi; più in generale questo dipenderebbe dalla funzionalità di invio della posta elettronica. Nel caso della distribuzione <A NAME="index1792"></A>Debian, si parla di «pacchetti virtuali», per fare riferimento a queste funzionalità generiche da cui possono dipendere altri pacchetti (reali).</P>
<H2>17.4 <A NAME="title363"></A><A NAME="anchor428"></A>
Fasi dell'installazione e della disinstallazione di un pacchetto </H2>
<P>Da quanto esposto, si possono intuire alcune delle fasi riferite all'installazione e alla disinstallazione di un pacchetto:</P>
<UL>
<LI>
<P>prima dell'installazione occorre verificare che siano rispettate le dipendenze, e che non ci siano incompatibilità;</P>
</LI>
<LI>
<P>prima della disinstallazione occorre verificare che non ci siano altri pacchetti che rimangono installati e dipendono da quello che si vuole eliminare.</P>
</LI>
</UL>
<P>Ma i problemi non si limitano a questi. Infatti, un pacchetto che si installa può richiedere la predisposizione di qualcosa, come dei collegamenti simbolici, dei file di dispositivo nella directory <CODE>/dev/</CODE>, e anche dei file di configurazione. In generale, gli archivi dei pacchetti utilizzati dalle distribuzioni GNU/Linux contengono degli <A NAME="index1793"></A>script realizzati specificatamente per questo, cioè per sistemare le cose in fase di installazione e anche quando si disinstalla un pacchetto. Volendo si può arrivare a distinguere tra quattro <A NAME="index1794"></A>script corrispondenti ad altrettante fasi:</P>
<OL>
<LI>
<P>uno <A NAME="index1795"></A>script da eseguire prima dell'estrazione dell'archivio contenente il pacchetto da installare;</P>
</LI>
<LI>
<P>uno <A NAME="index1796"></A>script da eseguire dopo l'estrazione dell'archivio contenente il pacchetto da installare;</P>
</LI>
<LI>
<P>uno <A NAME="index1797"></A>script da eseguire prima della cancellazione dei file che compongono un pacchetto da disinstallare;</P>
</LI>
<LI>
<P>uno <A NAME="index1798"></A>script da eseguire dopo la cancellazione dei file che compongono un pacchetto da disinstallare.</P>
</LI>
</OL>
<P>Naturalmente, dipende dalle caratteristiche di un pacchetto il fatto che siano necessari o meno questi <A NAME="index1799"></A>script. In generale, la configurazione rappresenta un problema particolare, che viene affrontato in maniera differente dalle varie distribuzioni GNU/Linux.</P>
<H3>17.4.1 <A NAME="title364"></A><A NAME="anchor429"></A>
Configurazione di un pacchetto </H3>
<P>Per poter utilizzare un pacchetto, oltre all'installazione può essere necessaria la sua configurazione. La configurazione può richiedere di fatto la creazione o la modifica di un file di testo, secondo una sintassi determinata, oppure l'interazione con un programma apposito (che si occupa di fare le domande necessarie e di memorizzare le risposte nel modo più opportuno). I file che contengono le informazioni sulla configurazione di un pacchetto, fanno parte del pacchetto, e sono candidati per la cancellazione nel momento in cui si decide di disinstallarlo. Tuttavia, il sistema di gestione dei pacchetti potrebbe distinguere opportunamente il caso in cui si vuole disinstallare un pacchetto conservando però i file di configurazione, rispetto al caso in cui si vuole eliminare tutto senza porsi problemi di alcun tipo.</P>
<P>A parte il dettaglio importante relativo al fatto di trattare in modo distinto i file di configurazione nel momento della disinstallazione, le distribuzioni GNU/Linux possono distinguersi in modo notevole in base alla gestione della configurazione stessa. In pratica si potrebbero avere due estremi:</P>
<UL>
<LI>
<P>definire una configurazione minima e indispensabile <STRONG>prima</STRONG> di iniziare una nuova installazione della distribuzione GNU/Linux, lasciando che il resto venga fatto dall'utilizzatore quando vuole, dopo che l'installazione è terminata;</P>
</LI>
<LI>
<P>definire la configurazione mano a mano che i pacchetti vengono installati.</P>
</LI>
</UL>
<P>Nel primo caso, la procedura di installazione si limiterebbe a chiedere le informazioni indispensabili per il completamento della stessa (i dischi, le partizioni, la tastiera, eventualmente la rete, ecc.); successivamente verrebbero installati i pacchetti senza disturbare più l'utilizzatore, che alla fine deve configurare per conto proprio i servizi che gli interessano.</P>
<P>Nel secondo caso, ogni volta che si installa un pacchetto che richiede una configurazione (indipendentemente dal fatto che si tratti della prima installazione della distribuzione o che si tratti di un lavoro fatto in seguito), gli <A NAME="index1800"></A>script che lo corredano interrogano l'utilizzatore su come configurare, almeno in modo grossolano, ciò che serve.</P>
<P>Tra i due estremi ci sono delle situazioni intermedie, nelle quali si possono fissare alcune informazioni che tornano utili ai pacchetti più importanti, già in fase di prima installazione, in modo da alleggerire il carico di notizie da fornire nel momento della configurazione finale legata all'installazione del singolo pacchetto.</P>
<P>L'esempio tipico di una distribuzione GNU/Linux in cui la configurazione avviene mano a mano che i pacchetti vengono installati è quello della <A NAME="index1801"></A>Debian. Quando si installa un pacchetto nuovo in un sistema GNU/Linux già funzionante, il fatto che durante l'installazione vengano richieste (eventualmente) le informazioni necessarie a dargli una configurazione minima, è sicuramente un fatto positivo. Tuttavia, quando l'utente inesperto tenta di installare per la prima volta questa distribuzione dopo avere selezionato una grande quantità di pacchetti, questo si trova disorientato di fronte alla quantità di cose che devono essere configurate e che non aveva previsto, oltre all'eccessiva quantità di tempo necessaria per completare l'installazione.</P>
<TABLE BORDER="3" WIDTH="100%">
<TR><TD>
<P>Da quanto scritto si intuisce che: di fronte a una distribuzione GNU/Linux organizzata in modo da gestire la configurazione dei pacchetti mano a mano che questi vengono installati, è indispensabile, in fase di prima installazione del sistema, iniziare con la selezione del minimo possibile, riservandosi di aggiungere ciò che manca in un momento successivo.</P>
</TD></TR>
</TABLE>
<H2>17.5 <A NAME="title365"></A><A NAME="anchor430"></A>
Caratteristiche di un pacchetto nei confronti di un sistema funzionante </H2>
<P>Un sistema sofisticato di gestione dei pacchetti di una distribuzione GNU/Linux, potrebbe non limitarsi a riportare il fatto che un pacchetto sia installato o meno, dando qualche informazione in più. Un pacchetto potrebbe essere:</P>
<UL>
<LI>
<P>non installato;</P>
</LI>
<LI>
<P>installato (correttamente);</P>
</LI>
<LI>
<P>non installato, ma con i file di configurazione ancora presenti (in pratica, è stato installato e successivamente disinstallato senza eliminare i file di configurazione);</P>
</LI>
<LI>
<P>installato in parte (l'archivio è stato estratto, ma gli <A NAME="index1802"></A>script necessari al completamento della procedura hanno rilevato un qualche tipo di errore, per cui il pacchetto potrebbe non essere operativo).</P>
</LI>
</UL>
<H2>17.6 <A NAME="title366"></A><A NAME="anchor431"></A>
Aggiornamento </H2>
<P>L'aggiornamento di un pacchetto implica la sostituzione di quello installato con uno di una versione più aggiornata. Si tratta di un problema comune, tuttavia pone dei problemi importanti. Un aggiornamento, perché non vada a danno di chi lo fa, dovrebbe preservare la sua configurazione precedente. In pratica, se il pacchetto «A» utilizza il file di configurazione <CODE>/etc/A.conf</CODE>, è bene che questo file non venga sovrascritto, o almeno venga conservato in qualche modo.</P>
<P>La politica delle distribuzioni GNU/Linux può essere varia:</P>
<UL>
<LI>
<P>i file di configurazione potrebbero essere sostituiti senza salvare quelli precedenti;</P>
</LI>
<LI>
<P>i file di configurazione potrebbero essere sostituiti salvandone una copia a cui viene data un'estensione particolare;</P>
</LI>
<LI>
<P>i file di configurazione potrebbero non essere sostituiti, affiancando eventualmente la nuova versione standard di questi file con un'estensione particolare.</P>
</LI>
</UL>
<P>Tanto per fare un esempio pratico, la distribuzione <A NAME="index1803"></A>Red Hat salva i file di configurazione precedenti utilizzando l'estensione <CODE>.rpmorig</CODE>, mentre la distribuzione <A NAME="index1804"></A>Debian si limita a non sostituire i file vecchi, affiancando eventualmente una copia della configurazione nuova, distinguendola con l'aggiunta dell'estensione <CODE>.dpkg-dist</CODE>.</P>
<H2>17.7 <A NAME="title367"></A><A NAME="anchor432"></A>
File di configurazione comuni </H2>
<P>Alcuni pacchetti potrebbero condividere uno stesso file di configurazione, oppure potrebbero dipenderne in qualche modo. Questo comporta dei problemi che non sono facili da risolvere in generale, tanto che si cerca di evitare il più possibile che questo debba succedere. Il caso più evidente di una tale dipendenza è quello dei file <CODE>/etc/passwd</CODE> e <CODE>/etc/group</CODE>, che potrebbero richiedere una modifica ogni volta che si installa un servizio particolare per il quale si deve definire un utente fittizio specifico, oppure un gruppo.</P>
<P>In questa situazione, l'installazione di un pacchetto può richiedere la modifica di un file di configurazione già esistente. Questo potrebbe avvenire per opera degli <A NAME="index1805"></A>script che lo accompagnano, ma in tal caso, questi dovrebbero avere l'accortezza di salvare una copia della versione precedente di questo file. Di solito si notano estensioni del tipo <CODE>.orig</CODE> oppure <CODE>.old</CODE>. Al contrario, un'estensione del tipo <CODE>.new</CODE> suggerisce trattarsi di un file che dovrebbe essere usato in sostituzione di quello attuale, lasciando all'utilizzatore il compito di sostituirlo manualmente.</P>
Appunti di informatica libera 2001.08.18 --- <EM>Copyright © 2000-2001 Daniele Giacomini -- daniele @ swlibero.org</EM></DIV>
<HR>
<P>Dovrebbe essere possibile fare riferimento a questa pagina anche con il nome <A HREF="pacchetti_applicativi_confezionati_appositamente_per_le_dist.html">pacchetti_applicativi_confezionati_appositamente_per_le_dist.html</A></P>
<P>
<A HREF="a232.html">[successivo]</A>
<A HREF="a230.html">[precedente]</A>
<A HREF="a2.html">[inizio]</A>
<A HREF="a2506.html">[fine]</A>
<A HREF="a21.html">[indice generale]</A>
<A HREF="a26.html">[violazione GPL]</A>
<A HREF="a2504.html">[licenze]</A>
<A HREF="a2505.html">[indice analitico]</A>
</P>
</BODY>
</HTML>
|
