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
- Esecuzione dello script di pre-installazione (solo se previsto nel pacchetto)
- Controllo della firma digitale del pacchetto
- Controllo delle dipendenze
- Gestione del backup dei file che sarebbero sovrascritti
- Installazione dei file nel sistema
- Esecuzione dello script di post-installazione (solo se previsto nel pacchetto)
Ricerca di informazioni per i software installati
- Lista dei software installati
- Informazioni generali di un pacchetto
- Lista dei files appartenenti a un pacchetto
- Quale pacchetto ha installato un determinato file
Uninstall
- Controllo delle dipendenze
- Rimozione dei file dal sistema
- Esecuzione dello script di post-disinstallazione (solo se previsto nel pacchetto)
Verifica
- Controllo dei file installati nella corretta posizione
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)