RPM Package Manager
RPM Package Manager[1] (precedentemente noto come Red Hat Package Manager[1][2], abbreviato RPM[3]) è un sistema di gestione dei pacchetti libero e open source. Utilizzato in numerose distribuzioni Linux tra cui Red Hat, Fedora, CentOS, openSUSE e Tizen[3], il software viene distribuito in file archivio denominati pacchetti RPM che presentano l'estensione .rpm.[4] Il formato dei pacchetti RPM è considerato uno standard ufficiale all'interno del Linux Standard Base.[1][3][5]
| RPM Package Manager software | |
|---|---|
 | |
| Genere | Sistema di gestione dei pacchetti |
| Data prima versione | 1997 |
| Ultima versione |
|
| Sistema operativo | Linux Unix-like |
| Linguaggio | C |
| Licenza | GNU GPL v2 (licenza libera) |
| Sito web | rpm.org |
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]
Descrizione modifica
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 modifica
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 modifica
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 modifica
Vantaggi modifica
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.
- Verifica crittografica con GNU Privacy Guard (GPG) e md5.
- 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 modifica
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 modifica
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.
Distribuzioni Linux che utilizzano RPM modifica
Diverse distribuzioni Linux supportano gli RPM. Queste includono (ma non si limitano alle sottocitate):[senza fonte]
- Fedora Core (dalla versione 7 in poi semplicemente Fedora)
- Mandriva Linux
- Openmamba
- OpenSUSE
- PCLinuxOS
- PS2 Linux
- Red Flag Linux
- Red Hat Linux e derivati:
Programmi di gestione dei pacchetti RPM modifica
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 nelle distribuzioni Linux SuSE ed OpenSUSE
- apt-rpm una versione modificata di apt, per gestire i file .rpm
- urpmi utilizzato in Mandriva Linux
- Yellow dog Updater, Modified (yum) usato da Yellow Dog Linux e da Fedora.
- 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).
Note modifica
- ^ a b c d e Foster-Johnson.
- ^ a b (EN) Edward C. Bailey, Maximum RPM: Taking the Red Hat Package Manager to the Limit, su rpm5.org, Red Hat, Inc., 2000.
- ^ a b c d (EN) About RPM, su rpm.org.
- ^ (EN) Adam Miller, Maxim Svistunov e Marie Doleželová, RPM Packaging Guide, su rpm-packaging-guide.github.io.
- ^ (EN) Software Installation, su Linux Standard Base Core Specification, Linux Standard Base, Linux Foundation.
- ^ (EN) Timeline, su rpm.org.«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) Max Spevack, [Rpm-announce] RPM -- plans, goals, etc., su lists.rpm.org, 14 dicembre 2006.«Several years ago, the maintainer of RPM worked for Red Hat. When he left, he continued his own work on RPM, which he acknowledges is a fork.»
- ^ (EN) RPM Project Roadmap, su rpm package manager, 29 maggio 2007.
- ^ Re: [rhn-users] Bootstrapping RPM - how?[collegamento interrotto]
Bibliografia modifica
- (EN) Eric Foster-Johnson, Red Hat RPM Guide, Wiley Publishing, 2003, ISBN 0-7645-4965-0.
- (EN) Edward C. Bailey, Maximum RPM: Taking the RPM Package Manager to the Limit, Red Hat, 2000, ISBN 1-888172-78-9. URL consultato il 9 settembre 2023.
Voci correlate modifica
Collegamenti esterni modifica
- (EN) Sito ufficiale, su rpm.org.
- RPM Package Manager, su packages.debian.org.
- Repository sorgenti di RPM Package Manager, su github.com.
- Sito di segnalazione bug, su github.com.
- (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).
- (EN) Package File Format, su Linux Standard Base Core Specification, Linux Standard Base, Linux Foundation. URL consultato il 9 settembre 2023.
- (EN) Documentation, su rpm.org.
- (EN) RPM Documentation, su rpm package manager.
- (EN) Who maintains RPM?, su LWN.net, 22 agosto 2006.
