RPM Package Manager
Da Wikipedia, l'enciclopedia libera.
Rpm è un sistema di gestione dei pacchetti, utilizzato per installare, verificare, aggiornare e disinstallare i pacchetti in alcune distribuzioni del sistema operativo GNU/Linux; il nome deriva da RedHat Packet Manager, e vede tra i suoi principali utilizzatori Red Hat, Fedora, Mandriva, Suse e loro derivate.
Sono stati sviluppati anche dei sistem di installazione e gestione automatica delle dipendenze.
Indice |
[modifica] Esempi di utilizzo
Per installare un pacchetto, si utilizza la seguente sintassi:
rpm -i <nome pacchetto>
Per disinstallarlo, invece, si utilizza: rpm -e <nome pacchetto>
Per ulteriori informazioni, consultare la pagina di manuale.
[modifica] Etichette del pacchetto
Ogni pacchetto RPM ha un'etichetta di pacchetto, non necessariamente essere identica al nome del file, che contiene le seguenti sezioni informative:
- Il nome del software
- La versione del software (la versione presa dallo "upstream" orginale della fonte del software)
- Il numero di rilascio del pacchetto (il numero di volte che il pacchetto è stato ricostruito utilizzando la stessa versione del software) questo campo viene spesso utilizzato per indicare la distribuzione specifica alla quale è destinato il pacchetto, p.es aggiungendo "strings" come "mdv" (prima, "mdk") per Mandriva Linux; "fc4" per Fedora Core 4; "rhl9" per Red Hat Linux 9; "suse100" per SuSE Linux 10.0, etc.
- L'architettura del processore per la quale il pacchetto è stato compilato (i386, i686, athlon, ppc, etc.)
I nomi dei file RPM normalmente hanno il seguente formato:
<name>-<version>-<release>.<arch>.rpm
Ad esempio:
nano-0.98-2.i386.rpm
All'interno del pacchetto è contenuta una package label (etichetta del pacchetto), È possibile trovare degli RPM contenenti del codice sorgente, le cui package label non hanno una porzione dedicata all'architettura, che viene sostituita dalla dicitura "src".
Ad esempio:
libgnomeuimm2.0-2.0.0-3.src.rpm
Un software può venire distribuito in più pacchetti separati: per esempio uno contiene il codice precompilato, l'altro i file necessari allo sviluppo, come gli header, e altri file particolari per la documentazione. I pacchetti utili solo per lo sviluppo hanno il postfisso "-devel" concatenato al loro nome mentre quelli contenenti la documentazione riguardante il pacchetto hanno tipicamente il postfisso "-doc".
Gli RPM con estensione noarch.rpm contengono dati che non sono dipendenti dall'architettura di un computer in particolare. Questi file includono, di solito, file grafici o di testo che devono essere usati da un altro programma, oppure script.
[modifica] Vantaggi e svantaggi del formato RPM
[modifica] Vantaggi del formato RPM
I vantaggi più citati dell'utilizzo dei pacchetti RPM su altre vie (come i pacchetti binari compressi con tar, con gunzip o con bunzip) per scaricare ed installare il software, sono:
- Un metodo uniforme per installare i programmi.
- Semplicità nella disinstallazione dei programmi, anche per utenti inesperti.
- Popolarità: vi sono migliaia di pacchetti disponibili, anche se spesso essi devono essere ricompilati per funzionare in altre distribuzioni.
- Installazione non-interattiva: rende facile l'installazione automatica.
- L'inclusione dell'archivio originale dei sorgenti (ad.es. *.tar.gz, *.tar.bz2), rende facile la verifica del loro CRC.
- Verifica crittografica con GNU Privacy Guard (GPG) e md5.
- I pacchetti Delta RPM, che sono l'equivalente per gli RM di un semplice file di "patch", si combinano da soli con gli RPM installati per eseguire aggiornamenti del software che venne installato tramite RPM. Questo è un modo molto più conveniente di aggiornare il software installato tramite RPM, dal momento che i DeltaRPM non necessitano del pacchetto originale per eseguire l'aggiornamento.
- Le dipendenze verificate sono sui singoli file, ciò rende più semplice l'utilizzo di pacchetti di terze parti.
[modifica] Svantaggi del formato RPM
Tra gli svantaggi spesso citati si segnala:
- Spesso hanno cambi nel formato del pacchetto che li rendono incompatibili retroattivamente.
- Hanno spesso una documentazione incompleta e non aggiornata.
- La comprensione da parte dell'utente, degli aspetti del "packaging" ha tipicamente una curva di apprendimento ripida.
- Non possono essere spacchettati con programmi ordinari, come avviene con i pacchetti "deb" e "tgz", dal momento che il file sorgente "tarball rpm" include uno script di shell - rpm2cpio.sh - che estrae la parte di archivio cpio dallo "rpm" utilizzando i tool di Unix od, expr, dd e gunzip. [1]
- Elenca i problemi di dipendenza menzionandoli come "dipendenze per file" e non come dipendenze del pacchetto che contiene questi file.
Il sistema degli RPM è stato criticato per la sua mancanza di coerenza nel nominare i pacchetti e nella evidenziazione del loro contenuto, cosa che può rendere la gestione delle dipendenze automatiche abbastanza difficile. Questo non è un problema radicato nella natura stessa del formato degli RPM, ma piuttosto un grave problema di non coordinazione nella nomenclatura, diffuso tra le maggiori distribuzioni Linux, che utilizzano i pacchetti RPM, come ad esempio Red Hat Linux, SUSE, e Mandriva Linux.
Quando si utilizzano packages destinati ad una certa distribuzione (ad esempio Red Hat Linux) o costruiti per una particolare distribuzione (ad es. Freshrpms per Red Hat Linux[2]), il sistema automatico di controllo delle dipendenze funziona, usando programmi come Yum su Red Hat Linux, apt, YaST su SuSE, urpmi su Mandriva Linux. Questi strumenti risolvono l'inferno delle dipendenze in Linux'.
[modifica] Creazione dei pacchetti RPM
La "ricetta" per la creazione di una pacchetto RPM è un file "spec". I file spec finiscono con l'estensione ".spec" e contengono il nome del pacchetto, la versione, il numero di revisione RPM, i passi per costruire, installare, e "pulire" il pacchetto, e un elenco dei cambiamenti. Molti pacchetti (destinati a diversi sistemi operativi e processori) possono essere costruiti da un singolo spec file RPM, se lo si desira. I pacchetti RPM vengono creati dai file RPM spec, utilizzando il comando "rpmbuild".
[modifica] Distribuzioni Linux che supportano il sistema RPM
 |
Per approfondire, vedi la voce Distribuzioni Linux. |
Diverse distribuzioni Linux supportano gli RPM. Queste includono (ma non si limitano alle sottocitate):
[modifica] Programmi di gestione dei pacchetti RPM ("frontends")
Vi sono diversi programmi di gestione dei pacchetti RPM, che trovano le dipendenze tra pacchetti collegati, risolvono le dipendenze ed aggiornano automaticamente i programmi.
I più conosciuti sono:
- Yet Another Setup Tool (YaST) utilizzato in SuSE Linux
- urpmi utilizzato in Mandriva Linux
- Yellow dog Updater, Modified (yum) usato da Yellow Dog Linux e da Fedora Core.
- apt-rpm, una versione della Advanced Packaging Tool (APT) di Linux Debian, che spesso viene raccomandata da alcune delle "repositories" di Fedora. Attualmente viene meno attivamente sviluppata ma in genere utilizza un minor numero di cicli della CPU per effettuare la decompressione.
- Smart Package Manager, disponibile per molte distribuzioni.
Nelle moderne versioni di SuSE si può trovare anche Zypper, che fornisce un programma da linea di comando e un backend per Yet Another Setup Tool (YaST).
[modifica] Fonti
- (EN) Detailed information on RPM file format
- Eric Foster-Johnson, Red Hat RPM Guide, , 2003. ISBN 0-7645-4965-0
[modifica] Collegamenti esterni
- (EN) Red Hat RPM Guide from the Fedora project.
- (EN) Fox, Pennington, Red Hat 2003: Fedora Project Developer's Guide: Chapter 4. Building RPM Packages
- (EN) RPM Package Manager homepage
- (EN) RPM Find Net: (per trovare i pacchetti)
- (EN) RPM Building as a User
- (EN) Bailey, Ed 2000: Maximum RPM, an outdated but popular rpm reference
- (EN) SUSE Package Conventions
- (EN) Website della Packman in Austria, dove si trovano pacchetti RPM per Open SuSE 10.0
- (EN) Package File Format - Linux Standards Base
- (EN) Who maintains RPM? - Addresses the issue of RPM's current maintainer.
