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).
Cosa cambia ancora? Allora, conoscete DeltaRPM? Si tratta di un tool che è in grado di costruire dei pacchetti RPM speciali. Esso non costruisce un pacchetto RPM completo, ma usando due versioni di uno stesso pacchetto ne ricava un terzo che contiene solo le differenze ("Delta"). In questo modo è possibile costruire pacchetti più piccoli, ed è anche più semplice gestire gli upgrade e i downgrade (passaggio da una versione più aggiornata ad una più datata). Le funzionalità di DeltaRPM saranno incluse in RPM.
C´è qualcosa di più tecnico? Si. Verrà aggiunto il supporto ai "file trigger", agli "update scriptlets" e alla "tilde" (~).
I "file trigger" sono delle azioni automatiche da eseguire ogni volta che si verifica un evento. Sono da considerarsi eventi situazioni del tipo: installazione di un nuovo font, modifica del contenuto della cartella /usr/lib, aggiunta di un nuovo file di configurazione in /etc/. Un File Trigger rileva queste situazioni e intraprende delle azioni di default definite da chi ha preparato la distribuzione.
Gli "update scriptlets" sono semplicemente degli script di sistema, tipo quelli bash, creati da chi prepara il pacchetto RPM. Essi sono due, i cui nomi sono %preup e %postup, e vengono invocati prima e dopo aver effettuato l´update di un pacchetto. Un´altra futura novità di RPM.
Infine, veniamo alla "tilde" (~). Verrà usata per arricchire la nomenclatura della versione. Usando la tilde situazioni come foo-2.5.99.2 potranno essere rappresentate anche con foo-2.6~beta2. Più leggibile, più comprensibile.
Quando tutto questo? Quando potremo iniziare a "gustare" il nuovo RPM? Date e scheduling non sono stati forniti. Bisognerà aspettare. Nel frattempo fateci avere i vostri commenti. Vi interessano le nuove funzionalità di RPM? Cosa aggiungereste voi? Cosa manca ancora?