Cos'e' un RPM (era Re: [Primipassi] Kernel 2.4.2)

[Sergio Ballestrero]

 continua...

On Wed, 28 Feb 2001, theold wrote:

> >> Come mai, nonostante l'aggiornamento del pacchetto (per es. pppd 2.4.0),
> >> se
> >> eseguo "rpm -qa | grep ppp" mi appare ancora il ppp-2.3.11-7 relativo
> >> alla
> >> precedente versione. L'installazione di un aggiornamento di un pacchetto
> >> non
> >> dovrebbe sostituire in toto il pacchetto presente sul sistema, anche se
> >> questo era stato generato col comando rpm ?
> >
> > Ma hai installato degli rpm nuovi, o hai preso tarball o sorgenti ?
> > Perche' se non hai usato l'rpm per installarli, allora nel database dei
> > pacchetti installati non ci puo' essere traccia di quello che hai fatto.
> 
> Forse non ho capito cosa siano gli rpm. Io credevo che fossero una specie di
> files di copia "zippata" dei programmi che costituiscono un pacchetto. Per
> esempio, io potrei installare da cd un programma (per es. excel per windows)
> e poi, per comodità di successive installazione su altre macchine, generare
> un file zippato, ovvero l' rpm, della directory contenente l'applicativo.
> Con l'rpm, a questo punto, potrei installare il pacchetto su altri pc senza
> passare per la laboriosa fase di setup.
> 
> Evidentemente gli rpm non sono tutto questo. Cosa sono ? e cos'è tarball ?

 cominciamo dalla risposta facile: un tarball e' il nomignolo che si da a
quello tu pensavi fosse un RPM: un tar.gz della installazione di un
programma. E' appena passata in lista una esauriente risposta di Leandro
su come si installa una tarball, e come mai sia una _pessima_ idea farlo.
 
 Viceversa, un rpm (per RH e consimili), o un deb (per debian e
consimili), e' una struttura piu' complessa. Contiene tutti i file come
devono essere installati nel sistema, con owner e permessi corretti. Ma
poi contiene anche :
 - script pre- e post-installazione
 - script pre- e post-disinstallazione
 - dipendenze del pacchetto
 - elenco dei file del pacchetto, firmati e classificati.
 
 Il package manager (rpm, apt, varie interfaccie piu' o meno grafiche
degli stessi) utilizza le dipendenze per sapere quali altri pacchetti sono
necessari (ad es. librerie, servizi) perche' il pacchetto in questione
possa essere installato: non puoi installare Netscape se non hai X11. 
 Lo stesso quando disinstalli: se vuoi disinstallare X11, rpm di dira'
"hei, guarda che serve per Netscape !"
 Quando sono soddisfatte le dipendenze, il pacchetto viene installato, e
vengono eseguiti gli script, che sistemano quello che serve - ad esempio
creano l'utente postgres se installi PostgreSQL.
 Al momento dell'installazione, il package manager registra nel database
una lista di tutti i file del pacchetto, e le loro firme MD5. Quindi puoi
ad esempio usare

[sb@pcsash /boot]$ rpm -V apache
S.5....T c /etc/httpd/conf/httpd.conf

questo ti dice che del pacchetto apache e' stato modificato il file
/etc/httpd/conf/httpd.conf, che e' un file di configurazione (la c).      
Questo puo' essere utile per controlli di sicurezza (ammesso di fidarsi   
che il database non sia stato hackerato); ma soprattutto e' importante per
gli upgrade, dato che se un file di configurazione e' stato modificato, il
package manager, quando installa un upgrade dello stesso pacchetto, non lo
sovrascrive con la nuova versione, ma, a seconda dell'upgrade, lo lascia  
stare (e magari ne crea uno nel nuovo formato come file.rpmnew), o lo   
rinomina a file.rpmold .

 La lista dei file, ovviamente, serve anche ad evitare conflitti - cosi'
un pacchetto non puo' impunemente sovrascrivere il file di un altro.
 I pacchetti rpm classificano a parte anche i file di documentazione
all'interno di un pacchetto, e quindi si potrebbe installare i pacchetti
senza doc e man; ma non conosco nessuna interfaccia grafica (o
installazione) che dia questa scelta.

 Quando disinstalli, vengono eseguiti gli script di disistallazione (se
esistono), che possono eliminare cose che non servono piu'.

 Quindi, un rpm, o un deb, ti permettono di installare in tutta sicurezza
un programma, di fare gli upgrade senza perdere le configurazioni, di
rimuovere un pacchetto senza lasciare traccie (salvo dati e magari backup
dei file di configurazione). Come vorrebbero fare gli installer sotto Win,
salvo che questi invece funzionano davvero :-)

 Morale: se devi installare un binario, installa un pacchetto, non una
tarball - piuttosto che la tarball, meglio i sorgenti, che tante volte
hanno un make uninstall.
 Il meglio in assoluto, a mio parere, sono i pacchetti sorgenti, che con
poco lavoro (ma talvolta non facile, sigh) si aggiustano alle necessita',
e poi creano i pacchetti da installare con il package manager. Anche su
questi era passato un thread in lista non molto tempo fa.

 Un'ultima nota: diverse distribuzioni usano RPM. Se puo' non essere un
problema installare un applicativo di una diversa distribuzione, occorre
invece stare molto attenti ad installare un daemon, dato che diverse
distribuzioni hanno idee diverse su permessi, utenti 'di sistema' etc.
 Non e' una buona idea neache fare upgrade con pacchetti di una diversa
distribuzione, o mischiare componenti di una stessa applicazione (ad
es. la suite di compilatori). Non e' impossibile, anzi spesso funziona, ma
richiede un minimo di attenzione.
 Esiste anche Alien, che permette di trasformare rpm<->deb, con risultati
buoni, ma a cui applicare quanto ho scritto subito sopra.

 Ciao,
  Sergio

(le flame rpm-deb mandatele su alcool, a cui non sono iscritto ;-> )

-- 
--------------------------------------------------------------------------
 Things will get better despite             Sergio Ballestrero
our efforts to improve them.                       S.Ballestrero@iname.com
	-- Will Rogers