Introduzione al software WPkg

Wpkg è un gestore di pacchetti software. Molti altri programmi già esistenti suppliscono a questa esigenza (es. rpm di RedHat, dpkg di Debian, pkgtool di Slackware, ecc..), ma tutti partono dall'assunto che la situazione del sistema, oggetto dell'installazione, sia staticamente definita a priori. WPkg, diversamente, fornisce un approccio meno vincolato: creare un pacchetto che si adatti le proprie procedure alle peculiarità del sistema.

Per capire meglio quali sono i vantaggi di questo approccio analiziamo il seguente caso pratico che mi ha portato allo sviluppo di questo progetto: dovevo produrre un singolo pacchetto per un software composto da alcune parti platform-independent e molte altre platform-dependent, disponibili per varie piattaforme differenti. Inoltre, l'installazione avrebbe coinvolto diversi sistemi operativi. Il pacchetto (o il suo gestore) doveva quindi essere dotato di sufficiente intelligenza per capire cosa installare, dove, e come integrarlo con le strutture esistenti. La soluzione fu appunto WPkg, un framework in cui è possibile installare un numero indefinito di moduli per eseguire test e azioni conseguenti, al fine di adattare il processo di installazione a qualsiasi ambiente.

Livelli di utilizzo

Le funzionalità offerte da Wpkg sono fruibili a diversi livelli, a seconda delle esigenze.

Livello 0
Nel caso in cui non si utilizzino le estensioni, dal punto di vista dell'utente, il gestore di pacchetti svolge le seguenti funzioni:

Installazione Ricerca di informazioni per i software installati
Uninstall Verifica

A questo livello, aggiungendo la sola estensione relativa alla verifica MD5 dei files, WPkg ottiene le stesse funzionalità di RPM. Prendo il software di RedHat come termine di paragone in quanto è indubbiamente uno dei più diffusi e dei più completi, sebbene non molto flessibile. Il gestore di pacchetti di Slackware, al contrario, è estremamente flessibile, ma lascia al creatore di ogni singolo supporto l'onere di implementare qualsiasi funzione non sia la mera copia dei files

Cambiando prospettiva, analiziamo (allo stesso livello) le differenze per chi produce il supporto installante:

Anche WPkg, come RPM, prevede che ci possa essere uno script da lanciare prima che i file vengano fisicamente copiati nel sistema, e un altro da eseguire al termine qi questa procedura. Ma i suddetti script (pre_install.sh e post_install.sh) non vengono mantenuti all'interno di un database, ma al contrario rimangono nella home del paccheto. Quest'ultima è una directory che conterrà le informazioni sul software installato sotto forma di file XML, e tutti gli script che personalizzano l'operazione di installazione e rimozione del pacchetto.

In molti casi poter disporre di più files è una grande comodità: prendiamo per esempio la generazione dei pacchetti con gli strumenti messi a disposizione da Linuxwoodo. Questi consentono di automatizzare il processo di creazione di tre tipologie di files: Archivi autoinstallanti, RPM (RedHat) e TGZ (Slackware)
Nel caso i pacchetti contengano dei file destinati ad essere interpretati, è necessario che lo script di post-installazione verifichi l'ubicazione dell'interprete (Perl, Tcl/Tk...) e il percorso dove esso andrà a cercare eventuali librerie. LW automatizza la produzione di tali script utilizzando dei templates, ottenendo un file per ogni interprete utilizzato. Questa soluzione si adattava perfettamente ai supporti TGZ (Slackware) o agli archivi auto-installanti (.sh). Ma RPM memorizza lo script in questione all'interno del file con estensione spec. Quindi, al fine di ottenere un singolo file lasciando però lo sviluppo dello script centralizzato, è stato necessario trasformare i files in funzioni e automatizzare un complesso insieme di operazioni di copia-incolla. Il risultato funziona ed è abbastanza elegante, ma questo ha richiesto un impiego di tempo ingiustificato, dovuto solo a questo vincolo.

Livello 1: accesso al database
Restando nel caso precedente è possibile scoprire un ulteriore vantaggio di WPkg. Prima ci siamo occupati dell'installazione di file interpretati, ma come procedere per rimuoverli automaticamente? Per i pacchetti conformi agli standard Slackware è stato semoplice. Infatti tutti i dati che verranno utilizzati dal processo di disinstallazione sono contenute in un file associato al pacchetto, è quindi stato sufficiente aggiungere i files interpretati alla lista relativa a quel pacchetto. Ma per ottenere lo stesso risultato nel caso di RPM sarebbe stato necessario accedere al database dall'interno dello spec-file. Ma il DB in questione è basato su file, quindi chi avrebbe gestito gli accessi concorrenti? Quindi, la soluzione è stata sviluppare lo script di post-disinstallazione in modo tale da recuperare le informazioni sui file installati, e rimuoverli. Avere un accesso al DB avrebbe consentito una soluzione più contenuta, più integrata, e senza dubbio più elegante.

WPkg si basa su un database XML (wlxdb) veloce ed essenziale, questo permette a gli script di accedere in modo facile alle informazioni sul software che si sta installando, e modificarle.

Livello 2: le estensioni
Con le funzionalità esposte nel "livello 1", è possibile costruire comodamente un supporto di installazione per qualsiasi ambiente: sarebbe sufficiente implementare test e azioni all'interno dei due script sopra citati e fare interagire questi con il database. Ma ad ogni creazione di un supporto di installazione sarebbe necessario riscrivere le procedure in considerazione delle peculiarità del software di cui si vuole ottenere un pacchetto. Inoltre sarebbe difficile standardizzare e condividere tali procedure.

Quindi al fine di riutilizzare il codice in modo efficente esiste una soluzione migliore: le estensioni. Queste sono piccoli moduli che realizzano test o azioni e vengono utilizzati all'interno del file di configurazione xml. In questo modo, è possibile creare dei supporti di installazione capaci di capire come e quali file installare, dove posizionarli, quali impostazioni modificare... Inoltre tali moduli potranno essere facilmente riutilizzati per altri pacchetti

Cambiamo prospettiva e torniamo all'utente. Per quest'ultimo i vantaggi offerti da WPkg potrebbero concretizzarsi nell'avere un singolo pacchetto per piìù architetture (Sparc, x86, MIPS...), sistemi operativi (Solaris, Linux, FreeBSD...), librerie (GTK, FLTK, QT...)... Il supporto si installerebbe in modo trasparente adattandosi al sistema di destinazione.

Inoltre anche l'opzione di verifica di un software installato può essere ampliata usando le estensioni. In tal modo sarà possibile implementare qualsiasi controllaro (MD5, permessi, utente...).

Sviluppi futuri

Attualmente WPkg è disponibile in Tcl/Tk (2.x.x) e Bash (1.x.x), prossimamente riprenderò lo sviluppo della versione in C (3.x.x)