Avanti Indietro Indice

4. Binari preimpacchettati

4.1 Cosa c'è che non va negli rpm?

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 rpm e deb, o il più recente Stampede slp. Sebbene possa essere vero che l'installazione di un rpm 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.

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 rpm 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 rpm o un deb. Alcuni pacchetti meno popolari potrebbero non essere mai convertiti in rpm.

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 rpm 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 rpm --recompile nomepacchetto.rpm oppure rpm --rebuild nomepacchetto.rpm.

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 rpm o un deb necessariamente fate affidamento sulla competenza delle persone che hanno preparato quel pacchetto.

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

L'installazione di un pacchetto rpm non è necessariamente una bazzecola. Se c'è un conflitto di dipendenza, l'installazione dell'rpm fallirà. L'rpm 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 rpm spesso falliscono per le stesse ragioni per cui lo fanno quelle dei pacchetti tar.

Dovete installare gli rpm e i deb 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 cavallo di Troia che potrebbe liberare il caos sul vostro sistema. È quindi importante ottenere pacchetti rpm e deb da una "fonte fidata". In ogni caso, dovreste eseguire una 'verifica della firma' (rispetto ad un codice di controllo MD5) sul pacchetto, rpm --checksig nomepacchetto.rpm, prima di installarlo. Allo stesso modo è fortemente raccomandata l'esecuzione di rpm -K --nopgp nomepacchetto.rpm. I comandi corrispondenti per i pacchetti deb sono dpkg -I | --info nomepacchetto.deb e dpkg -e | --control nomepacchetto.deb.

Per i tipi veramente paranoici (e in questo caso ci sarebbe molto da dire a proposito di paranoia), ci sono le utilità unrpm e rpmunpack disponibili presso la directory utils/package di Sunsite per estrarre e controllare i singoli componenti dei pacchetti.

Klee Diene ha scritto il pacchetto sperimentale dpkgcert, per la verifica dell'integrità dei file .deb installati, usando i codici di controllo MD5. È disponibile nell' archivio ftp Debian. L'attuale nome / versione è dpkgcert_0.2-4.1_all.deb. Il sito Jim Pick Software mantiene un server database sperimentale per fornire certificati dpkgcert per i pacchetti di una tipica installazione Debian.

Nella loro forma più semplice, i comandi rpm -i nomepacchetto.rpm e dpkg --install nomepacchetto.deb 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!

Notate che gli avvertimenti suddetti si applicano anche, sebbene in minor misura, all'utilità di installazione pkgtool della Slackware. Tutto il software di installazione "automatico" richiede cautela.

I programmi martian e alien permettono la conversione tra i formati dei pacchetti rpm, deb, Stampede slp e tar.gz. Ciò rende questi pacchetti accessibili a tutte le distribuzioni Linux.

Leggere attentamente le pagine di manuale dei comandi rpm e dpkg, e fare riferimento all' RPM HOWTO, alla Quick Guide to Red Hat's Package Manager del TFUG, e a The Debian Package Management Tools per informazioni più dettagliate.

4.2 Problemi con gli rpm: un esempio

Jan Hubicka ha scritto un bellissimo pacchetto per i frattali, chiamato xaos. Sulla sua home page sono disponibili entrambi i pacchetti .tar.gz e rpm. In nome della comodità proviamo la versione rpm, piuttosto che il pacchetto tar.

Sfortunatamente, l'rpm di xaos non si installa. Due diverse versioni rpm fanno i capricci.

rpm -i --test XaoS-3.0-1.i386.rpm 

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

rpm -i --test xaos-3.0-8.i386.rpm 

error: failed dependencies:
        libaa.so.1 is needed by xaos-3.0-8

La cosa strana è che libslang.so.0, libpng.so.0, e libaa.so.1 sono tutte presenti nella directory /usr/lib del sistema usato. Gli rpm di xaos devono essere stati compilati con delle versioni leggermente diverse di quelle librerie, anche se i numeri di versione sono identici.

Come test, proviamo ad installare xaos-3.0-8.i386.rpm con l'opzione --nodeps per forzarne l'installazione. Provando ad eseguire xaos si pianta. 

xaos: error in loading shared libraries: xaos: undefined symbol: __fabsl

(errore nel caricamento delle librerie condivise, il simbolo __fabsl non è definito)

Cerchiamo testardamente di andare in fondo alla cosa. Lanciando ldd sul binario di xaos, per trovare da quali librerie dipende, vediamo che le librerie necessarie ci sono tutte. Lanciando nm sulla libreria /usr/lib/libaa.so.1, per vedere i suoi riferimenti simbolici, ci accorgiamo che __fabsl manca davvero. Naturalmente il riferimento che manca potrebbe non essere presente in una qualsiasi delle altre librerie... Non c'è niente da fare, salvo rimpiazzare una o più librerie.

Basta! Scarichiamo il pacchetto tar, XaoS-3.0.tar.gz, disponibile sul sito ftp o reperibile dalla home page. Proviamo a compilarlo. L'esecuzione di ./configure, make e infine (come root) make install procede senza intoppi.

Questo è solo uno fra i tanti esempi di binari preimpacchettati che portano più problemi che vantaggi.

Avanti Indietro Indice