Capitolo 3. Creazione dei pacchetti personalizzati

È possibile incontrare numerosi problemi durante la creazione dei pacchetti software, soprattutto durante il processo di consegna e di installazione dei pacchetti stessi tramite Red Hat Network. Questo capitolo fornisce una panoramica su come creare i pacchetti e consegnarli correttamente tramite Red Hat Network. Gli argomenti affrontati riguardano il motivo per il quale viene utilizzato RPM, la creazione dei pacchetti per RHN, e come firmarli in modo corretto.

3.1. Creazione di pacchetti per Red Hat Network

Red Hat Network utilizza la tecnologia RPM Package Manager (RPM), per determinare il tipo di aggiornamento o le implementazioni software aggiuntive applicabili ad ogni sistema client. I pacchetti ripristinati da Red Hat Network sono generalmente in formato RPM. Tuttavia le immagini ISO sono disponibili attraverso la tabella Software del sito web di Red Hat Network, ma non sono disponibili nelle installazioni RHN Satellite Server. Se il supporto Solaris è stato abilitato sul vostro Satellite, è possibile utilizzare RHN Push per caricare i pacchetti Solaris sui canali personalizzati utilizzati dai client di Solaris.
RPM è un tool in grado di fornire agli utenti un metodo molto semplice di installazione, disinstallazione, aggiornamento e verifica dei pacchetti software. Altresì permette agli sviluppatori software di contenere il codice sorgente e le versioni compilate di un programma per utenti finali e sviluppatori.

3.1.1. Vantaggi offerti da RPM

RPM fornisce i seguenti vantaggi:
Processi di aggiornamento semplici
Utilizzando RPM è possibile aggiornare singoli componenti di un sistema senza eseguire un processo completo di reinstallazione. Quando Red Hat rende disponibile una nuova versione di Red Hat Enterprise Linux, per poter eseguire un processo di aggiornamento, gli utenti non dovranno eseguire un nuovo processo di installazione. RPM rende possibile l'esecuzione di processi di aggiornamento intelligenti e completamente automatizzati. Durante l'esecuzione dei suddetti processi, i file di configurazione presenti all'interno dei pacchetti non verranno alterati, in questo modo gli utenti non perderanno le proprie impostazioni. Non è necessario alcun tipo di file di aggiornamento per eseguire tale operazione su di un pacchetto, poichè viene utilizzato lo stesso tipo di file RPM per installare o aggiornare il pacchetto.
Interrogazione dei pacchetti
RPM fornisce delle opzioni per il processo di interrogazione atte ad eseguire una ricerca, attraverso il vostro database RPM, di pacchetti o di determinati file. È possibile altresì stabilire il file di appartenenza di un pacchetto e la sua provenienza. I file contenuti nel pacchetto si trovano in un archivio compresso, con un header binario personalizzato contenente infiromazioni utili sul pacchetto e sui rispettivi contenuti. RPM interroga gli header in modo veloce a semplice.
Verifica del sistema
Un'altra caratteristica è quella della verifica dei pacchetti. Se credete che un file relativo ad un pacchetto è stato cancellato, è possibile verificare il pacchetto in modo da controllare lo stato del file corrispondente. Tale verifica notificherà la presenza di eventuali anomalie. Se sono presenti degli errori sarà possibile reinstallare i file in modo semplice ed accurato. I file di configurazione modificati vengono conservati durante il processo di reinstallazione.
Pristine Sources
Uno degli scopi più importanti di RPM è quello di permettere l'utilizzo dei pristine software sources, come diffuso dagli autori originali del software. Insieme a RPM sono presenti all'interno di un prodotto sia i pristine sources che le patch utilizzate insieme alle istruzioni per l'impostazione. Tale caratteristica rappresenta un vantaggio per diversi motivi. Per esempio, nel caso in cui viene rilasciata una nuova versione di un programma, non sarà necessario eseguire la sua compilazione partendo da zero. È necessario solo controllare la patch relativa per seguire le fasi a voi necessarie. Tutti i valori di default e le modifiche eseguite per impostare correttamente il vostro software, sono facilmente visibili utilizzando questa tecnica.
Il mantenimento inalterato dei codici sorgenti non solo potrebbe interessare gli sviluppatori, ma potrebbe anche dar luogo ad un software con qualità maggiori per gli utenti finali.

3.1.2. Direttive RPM di RHN

Il vantaggio di RPM stà nel fatto che esso è in grado di definire le dipendenze e di identificare i conflitti in modo accurato, per questo motivo Red Hat Network si affida molto a questa caratteristica. Red Hat Network offre altresì un ambiente automatizzato, ciò significa che non è possibile eseguire alcun intervento manuale durante il processo di installazione di un pacchetto. Pertanto, al momento della creazione di RPM per una distribuzione tramite Red Hat Network, è necessario seguire le regole di seguito riportate:
  1. Conoscere RPM. È cruciale comprendere in modo approfondito l'importanza delle funzioni essenziali di RPM in modo da creare correttamente i pacchetti. Per maggiori informazioni su RPM, consultate le seguenti risorse:
  2. Quando create un RPM per un canale figlio, create il pacchetto tramite una nuova installazione di Red Hat Enterprise Linux con la stessa versione del canale di base del figlio. Assicuratevi di applicare prima tutti gli aggiornamenti provenienti da Red Hat Network.
  3. È necessario installare il pacchetto RPM senza l'utilizzo delle opzioni --force o --nodeps. Se non siete in grado d'installare in modo pulito un RPM sul vostro sistema di compilazione, Red Hat Network non sarà in grado di installarlo automaticamente sul sistema.
  4. Il filename del pacchetto RPM deve essere in formato NVR (name, version, release), e deve contenere l'architettura per il pacchetto. Il formato corretto è name-version-release.arch.rpm. Per esempio, un filename valido per il pacchetto RPM è pkgname-0.84-1.i386.rpm, dove il nome è pkgname, la versione è 0.84, la release è 1, e l'architettura è i386.
  5. Il pacchetto RPM dovrebbe essere firmato dal manutentore del pacchetto. I pacchetti non firmati possono essere distribuiti attraverso Red Hat Network, ma il Red Hat Update Agent (up2date) deve essere forzato ad accettarli. La firma dei pacchetti è fortemente consigliata e viene affrontata nella Sezione 3.2, «Firme digitali per pacchetti RHN».
  6. Se il pacchetto viene in alcun modo modificato, incluso la modifica della firma o la sua ricompilazione, la versione o la release deve essere aumentata in maniera incrementale. In altre parole, il NVRA (incluso il tipo di architettura) per ogni RPM distribuito attraverso RHN, deve corrispondere ad una creazione unica nel genere per evitare doppioni.
  7. Nessun pacchetto RPM può rendere la propria versione obsoleta.
  8. Se il pacchetto viene diviso in due o più pacchetti separati, fate molta attenzione alle dipendenze. Non dividete un pacchetto esistente a meno che non siete costretti a farlo.
  9. Nessun pacchetto si può affidare agli script di pre-installazione, post-installazione, pre-disinstallazione o post-disinstallazione interattiva. Se il pacchetto in questione ha bisogno dell'intervento di un utente durante l'installazione, tale procedura non sarà in grado di funzionare con Red Hat Network.
  10. Qualsiasi script di pre-installazione, post-installazione, pre-disinstallazione e post-disinstallazione non dovrebbe mai eseguire alcun processo di scrittura su stderr o stdout. Ridirezionate i messaggi su /dev/null, se essi non risultano necessari, in caso contrario scriveteli su di un file.
  11. Quando create il file spec, utilizzate le definizioni del gruppo presenti in /usr/share/doc/rpm-<version>/GROUPS. Se non è disponibile un abbinamento ideale, selezionate quello più idoneo.
  12. Utilizzate le caratteristiche della dipendenza RPM, in modo da assicurarvi che il programma venga eseguito correttamente dopo la sua installazione.

Importante

Non create alcun RPM tramite il processo di archiving e unarchiving dei file all'interno dello script post-installazione. Tale processo annulla l'obiettivo di RPM.
Se i file presenti all'interno dell'archivio non vengono inclusi nell'elenco, essi non possono essere verificati o esaminati per la presenza di conflitti. Nella maggior parte dei casi RPM è in grado di compattare e scompattare gli archivi nel modo migliore. Per esempio, non create alcun file in un %post non riordinato in una sezione %postun.