Qualche giorno fa ci siamo interessati della possibile evoluzione di APT, il package manager di alto livello di Ubuntu e Debian. Sembra però che anche sul fronte RPM (RedHat Package Manager) ci sia del movimento.
Lo scorso mese di settembre durante la openSUSE Conference, tenutasi dal 17 al 20 a Nuremberg, si sono riunite le persone più importanti che lavorano al progetto RPM. Ingegneri e sviluppatori Novell e Red Hat, insieme ad alcuni volontari indipendenti, hanno discusso di cosa bisognerebbe cambiare nell’attuale RPM, e delle implicazioni sui tool YUM (Yellowdog Updater Modified) e Zypper.
Addentriamoci anche noi nella discussione, e cerchiamo di capire cosa cambierà nel prossimo futuro di RPM.
Partiamo dal “payload format” cioè il formato binario dei singoli pacchetti RPM. Ogni singolo pacchetto RPM è un archivio impacchettato usando CPIO (usato anche per le initramfs del Kernel Linux). CPIO ha origini storiche molto lontane, e risale agli albori dei sistemi UNIX. Questa sua “anzianità” oggi presenta un limite, perché CPIO non consente di gestire file più grandi di 8GB. È un problema per RPM? Dipende. Il pacchetto RPM di un tool software o di una libreria spesso non è più grande di qualche decina di MegaByte, quindi per queste situazioni CPIO non è un problema. Oggigiorno però RPM viene anche usato per impacchettare una intera distribuzione, si pensi alle Software Appliance; in questo caso il limite degli 8GB di CPIO è un problema. Quale il possibile sostituito? L’antagonista di sempre: tar.
Veniamo alla seconda evoluzione. “logging and recovery“. Una cosa che sembra certamente mancare ad RPM è la possibilità di poter registrare l’evoluzione di una operazione (transazione), e conseguentemente di poter recuperare una situazione di errore. Tool come YUM e Zypper hanno cercato di sopperire a questa carenza cercando di implementare loro una sorta di avanzamento dell’operazione. Ora, però, sembra venuto il momento di inserire questa funzionalità direttamente in RPM, e poi di apportare i dovuti allineamenti ai tool di alto livello (yum, zypper).

Bhe, probabilemente è una funzionalità che dovrebbe essere implementata in yum o zypper però, visto che siamo in argomento, ho sempre sognato una funzione diario, cioè una sorta di timeline in cui posso vedere i pacchetti che ho installato/rimosso in un dato giorno/settimana/mese, con la possibilità di aggiungere anche commenti…
di r p - 13 ottobre 2009 - 12:39
Articolo molto interessante. Per fortuna è da un paio di anni che Red Hat, Novell e Mandriva collaborano per migliorare lo stato di RPM e devo dire che qualche risultato già si vede.
di Diego - 13 ottobre 2009 - 14:18
voto anche io per il log delle modifiche ai pacchetti
anche senza una gui specifica, basta che zypper mi crei questo log e che non lo cancelli dopo x giorni…
un’altra cosa che secondo me sarebbe interessante è la possibilità di rimuovere automaticamente (previa conferma dell’utente ovviamente) tutte le dipendenze non più necessarie quando si rimuove un pacchetto.
es: installo firefox, zypper aggiunge anche delle librerie mozilla; se poi lo rimuovo queste librerie restano installate inutilmente: mi piacerebbe ci fosse un’opzione per almeno segnalarle così che l’utente decida se tenerle o meno.
La cosa andrebbe implementata per la maggior parte in zypper, ma credo che serva anche un supporto da rpm (magari un flag nel database dei pacchetti installati?)
ciao, Matteo
di Matteo - 14 ottobre 2009 - 09:27
@ rimuovere le dipendenze non più richieste durante la disinstallazione di un pacchetto
yum lo ha già: yum remove nome_pacchetto –remove-leaves
di pinguinows - 14 ottobre 2009 - 21:01
Nella realtà il summit ratifica solo alcune delle funzionalità richieste, e trascura, per motivi politici, quanto già implementato da anni dal precedente maintainer dell’RPM Jeff Johnson. Comunque se vogliamo parlare di collaborazione fra distro è utile precisare che al momento nella build factory di SUSE la ultima versione di RPM pacchettizzata da @rpm.org contiene solo 61 patch addizionali, non upstream.
Largamente sconosciuto comunque è rpm5.org. Ma non è un problema ai più.
di devzero2000 - 15 ottobre 2009 - 14:36