Vai al contenuto

RPM Package Manager

Da Wikipedia, l'enciclopedia libera.
RPM Package Manager
software
Logo
Logo
GenereSistema di gestione dei pacchetti
SviluppatorePanu Matilainen
Data prima versione1997
Ultima versione4.20.0 (7 ottobre 2024)
Sistema operativoLinux
Unix-like
LinguaggioC
LicenzaGNU GPL v2 e GNU General Public License
(licenza libera)
Sito webrpm.org
Modifica dati su Wikidata · Manuale

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 è 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 | 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 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 | 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 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 | 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

[modifica | modifica wikitesto]

Vantaggi

[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

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

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

Diverse distribuzioni Linux supportano gli RPM. Queste includono (ma non si limitano alle sottocitate):[senza fonte]

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. ^ a b c d e Foster-Johnson.
  2. ^ a b (EN) Edward C. Bailey, Maximum RPM: Taking the Red Hat Package Manager to the Limit, su rpm5.org, Red Hat, Inc., 2000.
  3. ^ a b c d (EN) About RPM, su rpm.org.
  4. ^ (EN) Adam Miller, Maxim Svistunov e Marie Doleželová, RPM Packaging Guide, su rpm-packaging-guide.github.io.
  5. ^ (EN) Software Installation, su Linux Standard Base Core Specification, Linux Standard Base, Linux Foundation.
  6. ^ (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»
  7. ^ (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.»
  8. ^ (EN) RPM Project Roadmap, su rpm package manager, 29 maggio 2007.
  9. ^ Re: [rhn-users] Bootstrapping RPM - how?[collegamento interrotto]

Bibliografia

[modifica | modifica wikitesto]

Voci correlate

[modifica | modifica wikitesto]

Collegamenti esterni

[modifica | modifica wikitesto]
  Portale Software libero: accedi alle voci di Wikipedia che trattano di software libero
Estratto da "https://it.wikipedia.org/w/index.php?title=RPM_Package_Manager&oldid=136856455"