<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
<TITLE>Building and Installing Software Packages for Linux: Binari preimpacchettati</TITLE>
<LINK HREF="Software-Building-HOWTO-5.html" REL=next>
<LINK HREF="Software-Building-HOWTO-3.html" REL=previous>
<LINK HREF="Software-Building-HOWTO.html#toc4" REL=contents>
</HEAD>
<BODY>
<A HREF="Software-Building-HOWTO-5.html">Avanti</A>
<A HREF="Software-Building-HOWTO-3.html">Indietro</A>
<A HREF="Software-Building-HOWTO.html#toc4">Indice</A>
<HR>
<H2><A NAME="s4">4. Binari preimpacchettati</A></H2>
<P>
<P>
<H2><A NAME="ss4.1">4.1 Cosa c'è che non va negli rpm?</A>
</H2>
<P>
<P>La compilazione e l'installazione manuale dei pacchetti dal sorgente
è un compito apparentemente così spaventoso per alcuni utenti
Linux che essi hanno abbracciato i popolari formati di pacchetti <EM>rpm</EM>
e <EM>deb</EM>, o il più recente Stampede <EM>slp</EM>. Sebbene possa essere
vero che l'installazione di un <EM>rpm</EM> di solito procede tanto facilmente
e tanto velocemente quanto l'installazione del software di un certo altro noto
sistema operativo, è il caso di spendere qualche parola riguardo gli
svantaggi della installazione-fai-da-te dei binari preimpacchettati.
<P>Primo, sappiate che i pacchetti software vengono di solito rilasciati
inizialmente come pacchetti tar, e i binari preimpacchettati li seguono
giorni, settimane, persino mesi dopo. Un pacchetto <EM>rpm</EM> corrente
è tipicamente almeno un paio di versioni minori indietro rispetto
all'ultimo pacchetto tar. Quindi, se desiderate stare al passo con tutto il
software dell'ultima generazione, potreste non voler aspettare che appaia
un <EM>rpm</EM> o un <EM>deb</EM>. Alcuni pacchetti meno popolari potrebbero
non essere mai convertiti in <EM>rpm</EM>.
<P>Secondo, il pacchetto tar potrebbe facilmente essere più completo,
avere più opzioni, e prestarsi meglio ad una personalizzazione ed una
messa a punto. La versione binaria rpm potrebbe non avere alcune delle
funzionalità della versione completa. Gli <EM>rpm</EM> sorgenti
contengono il codice sorgente completo e sono equivalenti ai corrispondenti
pacchetti tar, e allo stesso modo necessitano di essere compilati ed
installati usando l'opzione <B>rpm --recompile nomepacchetto.rpm</B>
oppure <B>rpm --rebuild nomepacchetto.rpm</B>.
<P>Terzo, alcuni binari preimpacchettati non si installano bene, e anche se
si installano, potrebbero piantarsi e fare un core dump. Essi potrebbero
dipendere da versioni di libreria diverse da quelle presenti nel vostro
sistema, o potrebbero essere stati preparati impropriamente o essere
semplicemente difettosi. Ad ogni modo, quando installate un <EM>rpm</EM> o
un <EM>deb</EM> necessariamente fate affidamento sulla competenza delle
persone che hanno preparato quel pacchetto.
<P>Infine, aiuta avere il codice sorgente in mano, per poter effettuare delle
riparazioni ed imparare da esso. È molto più conveniente avere il
sorgente nell'archivio da cui si stanno compilando i binari, piuttosto che
in un differente pacchetto <EM>rpm</EM>.
<P>
<P>L'installazione di un pacchetto <EM>rpm</EM> non è necessariamente una
bazzecola. Se c'è un conflitto di dipendenza, l'installazione
dell'<EM>rpm</EM> fallirà. L'<EM>rpm</EM> potrebbe richiedere una
versione delle librerie diversa da quelle presenti sul vostro sistema,
l'installazione potrebbe non funzionare, anche se create dei link
simbolici alle librerie mancanti da quelle a posto. Malgrado la loro
convenienza, le installazioni degli <EM>rpm</EM> spesso falliscono per le
stesse ragioni per cui lo fanno quelle dei pacchetti tar.
<P>Dovete installare gli <EM>rpm</EM> e i <EM>deb</EM> come root, per avere i
necessari permessi di scrittura, e ciò apre un buco di sicurezza
potenzialmente serio, poiché potreste inavvertitamente massacrare i
binari di sistema e le librerie, o anche installare un <EM>cavallo di
Troia</EM> che potrebbe liberare il caos sul vostro sistema. È quindi
importante ottenere pacchetti <EM>rpm</EM> e <EM>deb</EM> da una "fonte
fidata". In ogni caso, dovreste eseguire una 'verifica della firma'
(rispetto ad un codice di controllo MD5) sul pacchetto, <B>rpm
--checksig nomepacchetto.rpm</B>, prima di installarlo. Allo stesso
modo è fortemente raccomandata l'esecuzione di <B>rpm -K --nopgp
nomepacchetto.rpm</B>. I comandi corrispondenti per i pacchetti
<EM>deb</EM> sono <B>dpkg -I | --info nomepacchetto.deb</B> e
<B>dpkg -e | --control nomepacchetto.deb</B>.
<P>
<UL>
<LI><CODE>rpm --checksig gnucash-1.1.23-4.i386.rpm</CODE>
<BLOCKQUOTE><CODE>
<PRE>
</PRE>
</CODE></BLOCKQUOTE>
<CODE>gnucash-1.1.23-4.i386.rpm: size md5 OK</CODE></LI>
</UL>
<P>
<UL>
<LI><CODE>rpm -K --nopgp gnucash-1.1.23-4.i386.rpm</CODE>
<BLOCKQUOTE><CODE>
<PRE>
</PRE>
</CODE></BLOCKQUOTE>
<CODE>gnucash-1.1.23-4.i386.rpm: size md5 OK</CODE></LI>
</UL>
<P>Per i tipi veramente paranoici (e in questo caso ci sarebbe
molto da dire a proposito di paranoia), ci sono le utilità
<EM>unrpm</EM> e <EM>rpmunpack</EM> disponibili presso la
<A HREF="ftp://metalab.unc.edu/pub/Linux/utils/package">directory utils/package di Sunsite</A> per estrarre e controllare i singoli
componenti dei pacchetti.
<P>
<A HREF="mailto:klee@debian.org">Klee Diene</A> ha scritto il pacchetto
sperimentale <EM>dpkgcert</EM>, per la verifica dell'integrità dei file
<EM>.deb</EM> installati, usando i codici di controllo MD5.
È disponibile nell'
<A HREF="ftp://ftp.debian.org/pub/debian/project/experimental">archivio ftp Debian</A>. L'attuale nome / versione è
<EM>dpkgcert_0.2-4.1_all.deb</EM>. Il sito
<A HREF="http://dpkgcert.jimpick.com">Jim Pick Software</A> mantiene un
server database sperimentale per fornire certificati <EM>dpkgcert</EM>
per i pacchetti di una tipica installazione Debian.
<P>Nella loro forma più semplice, i comandi <B>rpm -i
nomepacchetto.rpm</B> e <B>dpkg --install nomepacchetto.deb</B>
automaticamente aprono il pacchetto ed installano il software. Siate cauti,
comunque, poiché usare tali comandi ciecamente può essere
pericoloso per la salute del vostro sistema!
<P>Notate che gli avvertimenti suddetti si applicano anche, sebbene in
minor misura, all'utilità di installazione <EM>pkgtool</EM> della
Slackware. Tutto il software di installazione "automatico" richiede
cautela.
<P>I programmi
<A HREF="http://www.people.cornell.edu/pages/rc42/program/martian.html">martian</A> e
<A HREF="http://kitenet.net/programs/alien/">alien</A> permettono la conversione tra i formati dei pacchetti
<EM>rpm</EM>, <EM>deb</EM>, Stampede <EM>slp</EM> e <EM>tar.gz</EM>.
Ciò rende questi pacchetti accessibili a tutte le distribuzioni Linux.
<P>Leggere attentamente le pagine di manuale dei comandi <EM>rpm</EM>
e <EM>dpkg</EM>, e fare riferimento all'
<A HREF="ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/RPM-HOWTO">RPM HOWTO</A>, alla
<A HREF="http://www.tfug.org/helpdesk/linux/rpm.html">Quick Guide to Red Hat's Package Manager</A> del TFUG, e a
<A HREF="http://www.debian.org/doc/FAQ/debian-faq-7.html">The Debian Package Management Tools</A> per informazioni più dettagliate.
<P>
<H2><A NAME="ss4.2">4.2 Problemi con gli rpm: un esempio</A>
</H2>
<P>
<P>
<A HREF="mailto:hubicka@paru.cas.cz">Jan Hubicka</A> ha scritto un
bellissimo pacchetto per i frattali, chiamato <EM>xaos</EM>. Sulla sua
<A HREF="http://www.paru.cas.cz/~hubicka/XaoS">home page</A> sono
disponibili entrambi i pacchetti <CODE>.tar.gz</CODE> e <CODE>rpm</CODE>. In nome
della comodità proviamo la versione rpm, piuttosto che il pacchetto
tar.
<P>Sfortunatamente, l'rpm di <EM>xaos</EM> non si installa. Due diverse
versioni rpm fanno i capricci.
<P><B>rpm -i --test XaoS-3.0-1.i386.rpm</B>
<BLOCKQUOTE><CODE>
<PRE>
error: failed dependencies:
libslang.so.0 is needed by XaoS-3.0-1
libpng.so.0 is needed by XaoS-3.0-1
libaa.so.1 is needed by XaoS-3.0-1
</PRE>
</CODE></BLOCKQUOTE>
<P><B>rpm -i --test xaos-3.0-8.i386.rpm</B>
<BLOCKQUOTE><CODE>
<PRE>
error: failed dependencies:
libaa.so.1 is needed by xaos-3.0-8
</PRE>
</CODE></BLOCKQUOTE>
<P>La cosa strana è che <CODE>libslang.so.0</CODE>, <CODE>libpng.so.0</CODE>,
e <CODE>libaa.so.1</CODE> sono tutte presenti nella directory <CODE>/usr/lib</CODE>
del sistema usato. Gli rpm di <EM>xaos</EM> devono essere stati compilati
con delle versioni leggermente diverse di quelle librerie, anche se i
numeri di versione sono identici.
<P>Come test, proviamo ad installare <CODE>xaos-3.0-8.i386.rpm</CODE> con l'opzione
<EM>--nodeps</EM> per forzarne l'installazione. Provando ad eseguire
<EM>xaos</EM> si pianta.
<P>
<BLOCKQUOTE><CODE>
<PRE>
xaos: error in loading shared libraries: xaos: undefined symbol: __fabsl
</PRE>
</CODE></BLOCKQUOTE>
<P>(errore nel caricamento delle librerie condivise, il simbolo __fabsl non
è definito)
<P>Cerchiamo testardamente di andare in fondo alla cosa. Lanciando <EM>ldd</EM>
sul binario di <EM>xaos</EM>, per trovare da quali librerie dipende, vediamo
che le librerie necessarie ci sono tutte. Lanciando <EM>nm</EM> sulla
libreria <CODE>/usr/lib/libaa.so.1</CODE>, per vedere i suoi riferimenti
simbolici, ci accorgiamo che <EM>__fabsl</EM> manca davvero. Naturalmente
il riferimento che manca <EM>potrebbe</EM> non essere presente in una
qualsiasi delle altre librerie... Non c'è niente da fare, salvo
rimpiazzare una o più librerie.
<P>Basta! Scarichiamo il pacchetto tar, <CODE>XaoS-3.0.tar.gz</CODE>,
disponibile sul
<A HREF="ftp://ftp.ta.jcu.cz/pub/linux/hubicka/XaoS/3.0">sito ftp</A> o reperibile dalla home page. Proviamo a compilarlo.
L'esecuzione di <B>./configure</B>, <B>make</B> e infine (come root)
<B>make install</B> procede senza intoppi.
<P>Questo è solo uno fra i tanti esempi di binari preimpacchettati
che portano più problemi che vantaggi.
<P>
<P>
<P>
<P>
<HR>
<A HREF="Software-Building-HOWTO-5.html">Avanti</A>
<A HREF="Software-Building-HOWTO-3.html">Indietro</A>
<A HREF="Software-Building-HOWTO.html#toc4">Indice</A>
</BODY>
</HTML>
