RPM è stato creato da Marc Ewing e Erik Troan[6], basato su pms, il sistema di pacchetti della distribuzione Linux BOGUS.[1][2] Il software è distribuito sotto GNU General Public License.[1][3] Jeff Johnson, ex dipendente di Red Hat, ha realizzato un fork di RPM denominato RPM 5.[7][8]
Il programma rpm di per sé non risolve in modo automatico le dipendenze, tuttavia sono stati sviluppati anche dei sistemi di installazione e gestione automatica delle stesse.
Il formato .rpm, al pari di .deb per Debian od Ubuntu e derivati, permette l'installazione automatica di programmi, librerie e dati aggiuntivi. Concettualmente è paragonabile ai file .msi usati in Microsoft Windows. I file SRPM (Source RPM, generalmente con estensione .src.rpm) contengono sorgenti e possono semplificare ed automatizzare la compilazione di software, risolvendo automaticamente le dipendenze da programmi e librerie di sviluppo (-devel) se usati con front-end, come DNF, zypp o urpmi.
Esempi di utilizzo
Una breve panoramica sui comandi, con alcune utili opzioni:
Installare un pacchetto
rpm -i (--nodeps) pacchetto.rpm
opzioni correlate:
--nodeps si usa per ignorare le dipendenze
--force serve per forzare l'installazione ignorando eventuali conflitti
--test esegue un tentativo di installazione e mostra eventuali conflitti, ma senza installare nulla realmente
--hash mostra la barra di progresso dell'operazione
Aggiornare un pacchetto
rpm -U pacchetto.rpm
l'opzione --nodeps si usa per ignorare le dipendenze
Rimuovere un pacchetto
rpm -e pacchetto
opzioni che potrebbero tornare utili in caso di rimozione, sono:
--allmatches: indica di rimuove TUTTE le occorrenze del pacchetto ed è utilizzata in caso di situazioni anomale in cui un pacchetto appare nell'elenco come installato più volte (con versioni differenti o con la stessa);
--repackage: prima di rimuovere il pacchetto ne crea uno partendo dai file attualmente installati nel sistema (assorbendo quindi le eventuali modifiche effettuate). Il pacchetto creato verrà posto in /var/spool/repackage/
--nodeps: esclude il controllo delle dipendenze prima della disinstallazione
Fare una ricerca per il pacchetto nel database di rpm
rpm -q pacchetto
opzioni correlate:
--all per mostrare tutti i pacchetti installati
--state per mostrare lo stato di un pacchetto
Capire a quale pacchetto appartiene un determinato file
rpm -qf /etc/passwd
opzioni correlate
l'opzione -f specifica il file
l'opzione -q esegue una ricerca
Stampare l'elenco dei file contenuti in un pacchetto
rpm -ql setup
l'opzione -l sta per list
Ricostruire il database dei pacchetti:
rpm --initdb o rpm --rebuilddb
è possibile infatti che il database dei pacchetti in seguito ad anomalie o malfunzionamenti si corrompa non permettendo il regolare funzionamento del sistema di pacchettizzazione.
In questo caso è necessario cancellare i file esistenti e ricostruire il database con le opzioni:
--initdb, che provvede all'inizializzazione del database esistente, accertandosi che esso sia validamente costruito.
--rebuilddb, invece creerà un nuovo database ex novo secondo gli headers dei pacchetti installati, utilizzando però come opzione --dbpath (ove sarà la directory da usare per il database), usando poi—root si specificherà di usare come la directory di livello superiore
Opzioni di uso generico:
-? o --helpMostra l'help esteso—version Mostra il numero di versione di rpm attualmente in uso—quiet Stampa a video meno messaggi possibile - normalmente verranno visualizzati solo i messaggi d'errore
-v o --verbose(verbose mode) verranno stampati i messaggi che indicano il progresso delle operazioni in corso.
Per ulteriori informazioni, consultare la pagina di manuale.
Etichetta del pacchetto
Le informazioni relative alla struttura dei pacchetti installati, sulle distribuzioni GNU/Linux che adoperano il formato .rpm, sono memorizzate in file con formato db4 depositati nella cartella /var/lib/rpm
Ogni pacchetto RPM reca in sé un'etichetta di pacchetto (detta anche header), non necessariamente identica al nome del file, che contiene le seguenti sezioni informative:
Il nome del software
La versione del software (la versione presa dallo "upstream" originale 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.)
L'elenco delle librerie di cui il programma ha bisogno per funzionare
I programmi con i quali va in conflitto.
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.
Vantaggi e svantaggi
Vantaggi
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 pacchetti e tenerne traccia, anche riguardo ai file che un pacchetto dissemina nel sistema.
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.
I pacchetti Delta RPM, che sono l'equivalente per gli RPM 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.
Gestione delle dipendenze: un pacchetto non può essere installato se non sono presenti quelli necessari al suo funzionamento e non può essere disinstallato se è necessario al funzionamento di altri.
Le dipendenze verificate sono sui singoli file, ciò rende più semplice l'utilizzo di pacchetti di terze parti.
Svantaggi
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[9].
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 nell'evidenziarne il 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 una grave mancanza di coordinazione nella nomenclatura, diffusa tra le maggiori distribuzioni Linux che utilizzano i pacchetti RPM, come ad esempio Red Hat Linux, SUSE, e Mandriva Linux. Il problema è stato risolto sviluppando programmi, come ad esempio Yum su Red Hat Linux, apt-rpm, YaST su SuSE, urpmi su Mandriva Linux, che consentono di risolvere il cosiddetto inferno delle dipendenze in Linux (dependency hell).
Creazione dei pacchetti RPM
La "ricetta" per la creazione di un 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, il riferimento a uno o più file sorgente e i passi per costruire il pacchetto.
Un pacchetto sorgente RPM (detto SRPM) contiene solitamente un file compresso in tar.gzip con i sorgenti del programma e un file .spec.
Se si ha necessità di fare delle modifiche al/ai file sorgente, è preferibile non operare direttamente sul file sorgente modificato, ma fare solo modifiche a quello originario attraverso opportuni file che descrivono le modifiche e che saranno utilizzati dal programma patch in sede di costruzione del pacchetto.
Molti pacchetti (destinati a diversi sistemi operativi e processori) possono essere costruiti da un singolo spec file RPM, se lo si desidera. I pacchetti RPM vengono creati dai file RPM spec, utilizzando il comando "rpmbuild". È preferibile che la fase di creazione del pacchetto RPM venga eseguita da un utente senza privilegi (quindi non root) in quanto errori nel file "spec" possono, se "rpmbuild" viene eseguito da root, danneggiare il sistema operativo che si sta utilizzando.
Vi sono diversi programmi di gestione dei pacchetti RPM, che trovano le dipendenze tra pacchetti collegati, risolvono le dipendenze ed aggiornano automaticamente i programmi.
Yum Extender conosciuto anche come YumEX – un'interfaccia grafica per il programma yum
Smart Package Manager, altro gestore di pacchetti, da riga di comando, disponibile per molte distribuzioni.
Le moderne versioni di SuSE ed OpenSUSE utilizzano Zypper, gestore di pacchetti da riga di comando e un backend grafico per ambiente desktop, Yet Another Setup Tool (YaST).
«The first commit to what was a state-of-the art CVS repository back then. Whether this was done by Marc Ewing or Erik Troan is lost in history as the commit was done as root»
(EN) Eric Foster-Johnson, Stuart Ellis e Ben Cotton, Fedora Draft Documentation RPM Guide, su Fedora Project (archiviato dall'url originale il 28 giugno 2022).