RPM Package Manager

Da Wikipedia, l'enciclopedia libera.

Il Red Hat Package Manager (abbr. RPM) indica, in informatica, uno dei primi, se non il primo, sistema di gestione dei pacchetti mai creati per Linux. Il suo nome si deve alla Red Hat, l'azienda statunitense nata nel 1995, che creò tale programma, per gestire files con estensione .rpm, formato la cui nascita va rintracciata sempre nell'opera di detta società. L'acronimo rpm indica inoltre anche il formato di file dei pacchetti, ossia .rpm.

È presente nelle distribuzioni linux basate e derivate da Red Hat Linux, e vede tra i suoi principali utilizzatori altre distribuzioni come Fedora, derivata da Red Hat, Mandriva, SuSe, OpenSUSE e loro derivate.

Caratteristiche generali[modifica | modifica wikitesto]

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 o Ubuntu un cosiddetto formato binario, poiché una volta aperto (eseguito) provvede in modo automatico ad installarsi (spacchettarsi e copiare tutti i files nel sistema). Concettualmente è paragonabile ai files .exe usati in MS-DOS e Windows. Si distingue perciò dal "formato sorgente", di solito files compressi in formato tar.gz o tar.gz2, che richiedono dapprima l'estrazione dei files contenuti in esso, nonché tutta una serie di operazioni necessarie per l'installazione dello stesso (la cosiddetta compilazione da sorgenti)

Esempi di utilizzo[modifica | modifica wikitesto]

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 fa sì che una volta finta l'installazione e mostra eventuali conflitti

--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: Eslude il controllo delle dipendenze prima della disintallazione


  • 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 files 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 | modifica wikitesto]

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 del formato RPM[modifica | modifica wikitesto]

Vantaggi del formato RPM[modifica | modifica wikitesto]

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 del formato RPM[modifica | modifica wikitesto]

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 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 | modifica wikitesto]

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, 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 GNU/Linux che utilizzano RPM[modifica | modifica wikitesto]

Exquisite-kfind.png Per approfondire, vedi Distribuzione GNU/Linux.

Diverse distribuzioni GNU/Linux supportano gli RPM. Queste includono (ma non si limitano alle sottocitate):

Programmi di gestione dei pacchetti RPM[modifica | modifica wikitesto]

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:

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 | modifica wikitesto]

  1. ^ Re: [rhn-users] Bootstrapping RPM - how?

Bibliografia[modifica | modifica wikitesto]

Voci correlate[modifica | modifica wikitesto]

Collegamenti esterni[modifica | modifica wikitesto]