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