autospec HOWTO: Guida alla creazione e manutenzione di rpm con autospec Davide Madrisan, 13 ottobre 2008 Questo documento descrive come creare ed aggiornare pacchetti rpm con `autospec', la suite di script e moduli bash che permette di velocizzare ed automatizzare una buona parte delle operazioni necessarie alla gestione dei pacchetti rpm, nonchè al controllo del loro livello qualitativo ed alla ricerca di comuni problemi di sicurezza. Autospec è stato utilizzato con successo dagli sviluppatori delle distribuzione Linux - QiLinux (http://www.qilinux.org) - openmamba (http://www.openmamba.org). Aggiornato alla versione 1.4.0 di autospec 1. Introduzione Autospec è nato con l'intento di facilitare e sveltire le attività di creazione e aggiornamento dei pacchetti di distribuzioni Linux basate sul sistema di pacchettizzazione rpm. In particolare è stato in primis il tool di QiLinux che ha permesso la creazione di specfile standard e l'aggiornamento ed update (semi)automatico dei pacchetti già presenti nella distribuzione QiLinux, in particolare dei pacchetti presenti nei rami sviluppo `devel' e `devel-contrib', il ramo dei contributori esterni. E' ora il sistema principale di manutenzione dei pacchetti adottato dagli sviluppatori della distribuzione openmamba. Autospec è stato strutturato in modo modulare e parametrizzato in ogni suo aspetto e componente per permettere il suo utilizzo in qualsiasi distribuzione basata sul sistema di pacchetti rpm, mediante la sola modifica dei valori assegnate alle variabili presenti nel file di configurazione. 1.1. Licenza autospec-it-HOWTO - copyright (C) 2004-2008 by Davide Madrisan. E' concessa la copia, la distribuzione e/o modifica di questo documento nei termini della licenza `GNU Free Documentation License', versione 1.1 od ogni successiva versione pubblicata dalla Free Software Foundation, senza variazione delle sezioni, senza testi di Front-Cover o di Back-Cover. Una copia della licenza è disponibile presso http://www.gnu.org/copyleft/fdl.html 1.2. Perchè questo documento? Questo documento è stato creato per fornire alcune linee guida a coloro che vogliono creare e mantenere pacchetti rpm con la suite di script autospec. In particolare vengono descritte le procedure di creazione e di upgrade dei pacchetti. Autospec risulta di particolare utilità nella creazione di librerie e moduli perl ed in genere di rpm di software pacchettizzati utilizzando gli autotools GNU (automake, autoconf, libtool). 1.3. Nuove versioni di questo documento Il documento è archiviato sul sito FTP della distribuzione openmamba, in particolare nel pacchetto sorgente (srpm) di autospec presente nel ramo devel. Si è autorizzati ed incoraggiati a spedire domande o commenti su questo HOWTO e su autospec a Davide Madrisan . 2. Come installare il software autospec Autospec è disponibile in formato tarball ed in formato rpm. In particolare gli utenti QiLinux 1.1 possono installare il pacchetto con il comando, eseguito da utente root, yum install autospec ed aggiornarlo con il comando, sempre eseguito da utente root, yum update autospec. Per gli utenti di QiLinux-devel e QiLinux 1.2pre1 o successive release, e per gli utenti openmamba è possibile installare o aggiornare autospec mediante il seguente comando apt-get install autospec o alternativamente tramite l'interfaccia grafica `synaptic'. Durante l'installazione viene creato un file di configurazione /etc/autospec.conf che è consigliabile non modificare. Per rendere autospec funzionante e per personalizzarne il comportamento è necessario creare manualmente il file ~/.autospec nella propria cartella home inserendovi i **soli** dati personali e le opzioni diverse dalle scelte di default presenti nel file principale. Riportiamo qui di seguito un esempio di file di configurazione utente per autospec che potrà essere utilizzato da un `contributor' come fac-simile per creare il proprio file di configurazione personale. [~/.autospec] # [configuration file for `autospec'] proxy= proxy_user= packager_fullname="" packager_email="@openmamba.org" ftp_rw_user[1]="" ftp_rw_passwd[1]="" arch_list=(i586 ppc arm x86_64) curl_opts_netlink="--connect-timeout 15 --retry 3 --limit-rate 250k" 3. Funzionamento di autospec Autospec è costruito da uno script principale di frontend ed una serie di plugin che effettuano le operazioni di creazione di specfile, di aggiornamento di pacchetti rpm e di estrazione di file da pacchetti rpm e srpm. Vi sono inoltre alcune `librerie', cioè moduli contenenti funzioni utiizzate nei plugin o utilizzabili da script creati da terze parti, su cui non ci soffermeremo. Autospec ed i suoi plugin sono script di shell che richiedono bash v2.0. Il comando autospec --help fornisce l'elenco dei comandi disponibili. Analizzaremo nelle sezioni seguenti alcuni di tali comandi e forniremo esempi pratici di utilizzo di tali opzioni. 3.1. Come utilizzare autospec per la creazione di specfile Per creare uno specfile di partenza tramite autospec è necessario avere il sorgente del software (tarball) che si vuole pacchettizzare. Utilizzeremo come esempio il tarball del `autospec' stesso, salvato nella cartella `/usr/src/RPM/SOURCES/'. La sintassi generica di autospec per la creazione di uno specfile è la seguente: autospec -s [-n ] [-v ] [-t ] [-o ] dove le precedenti opzioni significano, nell'ordine: -s, --source Cerca di creare uno specfile per il indicato -n, --pck-name Nome del pacchetto (default: ricavato dal nome del tarball) -v, --pck-version Versione del pacchetto (default: ricavato dal nome del tarball) -t, --type Categoria dello specfile da generare standard : specfile standard (default) gnome : specfile per pacchetti gnome kde3 : specfile per pacchetti kde3 kde4 : specfile per pacchetti kde4 library : specfile per librerie librarytools: specfile per librerie con tool perl : specfile per singoli moduli perl python : specfile per moduli python -o, --output Redirige lo standard output sul file Le opzioni tra parentesi quadre sono opzionali. Generiamo lo specfile di esempio con il comando: autospec -s /usr/src/RPM/SOURCES/autospec-1.0.1.tar.bz2 \ -t standard -o /usr/src/RPM/SPECS/autospec.spec o anche autospec -s http://ftp.qilinux.it/devel/tools/autospec/autospec-0.8.8.tar.bz2 \ -t standard -o /usr/src/RPM/SPECS/autospec.spec Viene in questo modo creato il file `/usr/src/RPM/SPECS/autospec.spec' che contiene le istruzioni per la generazione dei pacchetti rpm e srpm del tool autospec stesso. Nel secondo caso viene effettuato il download del software e quindi viene creato lo specfile. Si noti che nell'esempio è stato scelto il formato `standard' (formato di default). Altre scelte di formato attualmente disponibili sono - `library', per la generazione di specfile relativi a librerie, - `perl', per la generazione di specfile relativi a moduli perl - `python' per la creazione di specfile per pacchetti python. Nella directory /usr/share/autospec/templates sono presenti i templati degli specfile per le categorie di specfile di cui sopra. Si noti ancora che se si omette il comando `-o', il listato dello specfile verrà visualizzato su standard output. Consideriamo come ulteriore esempio il comando di creazione dello specfile della libreria avifile: autospec -s /usr/src/RPM/SOURCES/avifile-0.7-0.7.40.tar.gz \ -t library -n libavifile -v 0.7.40 In questo caso sono state utilizzate le opzioni `-n' per forzare il nome di specfile `libavifile' e l'opzione `-v' per forzare la versione `0.7.40'. Tali parametri infatti non sono ricavabili da autospec in automatico utilizzando il nome del tarball (avifile-0.7-0.7.40.tar.gz). Si noti che, trattandosi di una libreria, si è scelto di seguire lo standard QiLinux/openmamba che richiede che tali pacchetti abbiano sempre il prefisso `lib'. Completato manualmente lo specfile con un editor di testo, è possibile creare i pacchetti rpm e srpm con il comando seguente: autospec -u libavifile -a5 ed effettuare i test di simulazione di installazione, verifica di presenza di alcuni tipi di vulnerabilità ed i test di qualità dei pacchetti creati: autospec -u libavifile -a7,8 ed effettuare l'upload sul sito ftp di QiLinux, con il comando autospec -u -a10 libavifile se in possesso del necessario account sul branch `devel-contrib'. Si noti che se una versione precedente è presente nel repository, questa verrà rimossa oppure verrà spostata nella cartella `ftpdir_rw_old', se tale variabile è definita nel/i file di configurazione. Si veda il paragrafo successivo dove l'opzione `-u' viene esaminata in dettaglio. 3.2. Come utilizzare autospec per aggiornare pacchetti rpm Il tool autospec è molto utile durante la fase di aggiornamento di pacchetti rpm. La sintassi da utilizare è la seguente: autospec -u -a [] [] [-d v1=r1[,v2=r2,...]] \ [-l usr:pswd] [-S ] [-A ] \ [--server-download ] [--server-upload ] \ [--changelog "msg" ] [--nosrpm|--norpm] \ [--force-update] [--force-build] [--force-install] \ [--ignore-test t1[,t2,...]] [-c] [-f] [-L] [-R] dove le opzioni significano: -u, --update Aggiorna automaticamente il pacchetto , versione -a, --action Esegue la lista di azioni separate da virgole 0. cerca se il pacchetto è disponibile nei repository 1. download ed installazione del pacchetto srpm 2. controlla se è disponibile un aggiornamento 3. download dei nuovi file sorgente 4. aggiornamento e controllo dello specfile 5. creazione dei pacchetti rpm e srpm 6. creazione della lista dei build requirement 7. simulazione dell'installazione dei pacchetti rpm 8. esecuzione dei test di qualità e sicurezza 9. calcolo dei valori di hashing md5 e sha1 10. upload dei nuovi pacchetti sul sito ftp, *rimozione* dei vecchi pacchetti dal sito ftp (backup in `$ftp_rw_old_dir', se definita) 11. installazione dei nuovi pacchetti rpm --force-update Forza l'aggiornamento dei pacchetti rpm e srpm --force-build Ricrea comunque i pacchetti rpm e srpm --force-install Installa i nuovi pacchetti anche in caso di errori rpm --force Cerca di eseguire comunque le azioni specificate --ignore-test Non esegue i test indicati (t1[,t2,...]) -d, --define Assegna alle variabili v1,v2,... i valori r1,r2,... --server-download Server da utilizzare nel download dei pacchetti --server-upload Server dove effettuare l'upload dei pacchetti --server Server per l'upload e il download dei pacchetti -l, --login User (usr) e password (pswd) per l'upload sul sito FTP -S, --specfile Nome dello specfile (default: .spec) -A, --arch Forza un valore per l'architettura --changelog Scrive il messaggio indicato nel changelog del pacchetto --nosrpm azione 5: Crea soltanto i pacchetti rpm azione 10: Non effettua l'upload del pacchetto srpm --norpm azione 5: Crea soltanto il pacchetto srpm azione 10: Non effettua l'upload dei pacchetti rpm -c, --clear Rimuove tutti i file temporanei -f, --format Abilita la riformattazione dello specfile -L, --log Abilita il log su file (nella directory: `$logging_dir') -R, --rebuild Attiva modalità ed impostazioni di rebuild (azione 4) Per aggiornare ad esempio ad esempio il pacchetto `util-linux' alla versione 2.12b, si esegua il seguente comando: autospec -u -a1,3:5,7,8 util-linux 2.12b E' necessario avere una connessione attiva internet poichè verranno eseguiti i seguenti download: step 1 : download del pacchetto corrente srpm di `util-linux' dal primo sito indicato nei file di configurazione, o dal suo successivo se non trovato, ecc. step 3 : download del nuovo software, nell'esempio il tarball `util-linux-2.12b.tar.bz2'. In particolare, affinchè lo step `3' abbia successo, è necessario che nello specfile sia specificata una URL completo e valida alla voce `Source' o `Source0'. Naturalmente è possibile eseguire solo alcuni degli step precedenti, utilizzando l'opzione `-a' in modo opportuno. Segnaliamo in particolare l'opzione `-f' che forza l'autoformattazione dello specfile secondo lo standard QiLinux. Si noti che viene creata una copia di backup del precedente specfile, in caso si voglia o debba procedere ad un suo ripristino. Se si ha un account in scrittura nel repository `devel' o `devel-contrib' o un repository personale (come nel caso dei contributor in openmamba) è possibile infine effettuare l'upload con il comando autospec -u -a10 util-linux 2.12b E' anche possibile utilizzare l'opzione `--server-upload' per indicare ad autospec quale server utilizzare durante l'upload del pacchetti rpm e srpm. Il parametro intero che questo comando richiede è l'indice del server nel vettore `ftp_rw_server' (vedi file di configurazione). Nota: Si noti che il comportamento predefinito di autospec prevede la rimozione automatica dei vecchi pacchetti dal repository ftp dopo avere effettuato l'upload delle nuove versioni. Se tuttavia i precedenti pacchetti sono stati trovati in `ftpurl_ro_srpms[n]' e `ftpurl_ro_rpms[n]' e se la variabile `ftpdir_rw_old[n]' è stata configurata con un valore non vuoto (cioè non ""), invece della rimozione autospec effettuerà il backup dei pacchetti, utilizzando come directory radice il valore indicato in `ftpdir_rw_old[n]'. Ad esempio se i pacchetti sono stati trovati in ftpurl_ro_srpms[0]="ftp://ftp.qilinux.it/pub/QiLinux/devel/SRPMS" e se sono state inizializzate in ~/.autospec le variabili seguenti ftp_rw_server[0]="ftp.qilinux.it" ftpdir_rw_old[0]="/devel/old" verrà effettuerà il backup dei pacchetti sul server `ftp.qilinux.it' nella directory /devel/old/_ 4. Convenzioni relative agli specfile di QiLinux e openmamba Vengono qui elencate alcune convenzioni utilizzate negli specfile QiLinux e openmamba che puntano ad ottenere principalmente una uniformità e facile leggibilità degli stessi. 1. I file indicati in `Source', `Source0', `Source1', ..., che si riferiscono a risorse internet (file presenti su server ftp o http) devono avere indicata l'URL completa. Questo per permettere il loro download automatico al tool `autospec' ed in generale l'immediata reperibilità 2. I nomi delle patch dovrebbero avere la seguente struttura: %{name}--.patch dove '' indica il numero di versione del software in cui la patch è stata per la prima volta applicata, e `' indica una stringa esplicativa dello scopo della patch. es. %{name}-20040813-winelauncher.patch (wine-20040813) %{name}-2.0-gcc34.patch (libfaad2-2.0) %{name}-3.00-freetype2.patch (xpdf-3.00) %{name}-2.03-fonts.patch %{name}-3.00-xpdfrc.patch %{name}-3.00-can-2004-0888.patch Si noti un particolare l'ultima patch che si riferisce ad un fix di sicurezza ed in cui è utilizzato come descrizione l'ID del progetto Common Vulnerabilities and Exposures (CVE). 3. In caso di più patch può essere utile inserire una breve descrizione delle stesse nel blocco `%prep', se possibile es. %patch0 -p1 -b .freetype2 (xpdf-3.00) %patch1 -p1 -b .fonts %patch2 -p1 -b .xpdfrc %patch3 -p1 -b .can-2004-0888 4. Nel preambolo dello specfile è necessario inserire tutti i `BuildRequires' relativi ai pacchetti di sviluppo (devel) richiesti durante il processo di compilazione. Per far questo occorre controllare in modo molto attento l'output generato dallo script `configure', se utilizzato, e la documentazione fornita con il sorgente (generalmente i file REAME e/o REQUIREMENTS o simili). Questo permette la ricompilazione dei pacchetti source rpm su computer diversi da quelli su cui sono stati creati senza problemi e senza perdita di feature (in molti casi infatti, i check falliti dello script configure comportano la disabilitazione di feature altrimenti supportate dal software che si desidera ricompilare). Nota: questa pratica può significare la necessità di dover creare anche molti pacchetti supplementari, richiesti dal software principale che si desidera compilare per inserirlo nella distribuzione. E' bene infatti che il software abbia attive il maggior numero di feature, in modo da permettere il suo utilizzo pi generale possibile da parte di un utente generico. Nota: Se è installato il pacchetto `sudo' con una configurazione in cui siano presenti le seguenti righe (file `/etc/sudoers') # Cmnd alias specification Cmnd_Alias DISTO_CMD = /usr/bin/apt-get, /bin/rpm %packager ALL = NOPASSWD: DISTO_CMD autospec sar�in grado di installare automaticamente i build requiremnts indicati nello specfile. 5. I pacchetti devel devono generalmente avere la voce `Requires: %{name} = %{version}' es. %package devel Summary: Static libraries and headers for %{name} Group: Development/Libraries Requires: %{name} = %{version} 6. Utilizzare quando possibile le seguenti macro rpm %configure %make %makeinstall -oppure- %makeoldinstall in luogo rispettivamente di ./configure \ --prefix %{_prefix} \ --infodir %{_infodir} \ (se presente documentazione info) --mandir %{_mandir} (se presente documentazione man) ... make %{?_smp_mflags} make install DESTDIR=%{buildroot} make install \ prefix=%{buildroot}%{_prefix} \ exec_prefix=%{buildroot}%{_exec_prefix} \ bindir=%{buildroot}%{_bindir} \ ... Nota1: autospec v0.4.10 e successive versioni utilizzano queste macro durante la creazione automatica degli specfile. Nota2: se occorresse utilizzare il compilatore gcc-3.3.x invece di quello corrente (4.x), è possibile utilizzare in QiLinux e openmamba le macro `%configure33' e `%make33'. Altre macro rpm disponibili sono %install_info %uninstall_info Occorre utilizzarle quando nel pacchetto sono presenti pagine info. Ad esempio (pacchetto `coreutils') %post %install_info coreutils.info %preun %uninstall_info coreutils.info exit 0 Ed infine: %find_lang da utilizzarsi se il pacchetto supporta l'internazionalizzazione via `gettext' (file /usr/share/locale/*/LC_MESSAGES/*.mo). Ad esempio (pacchetto `tar') %install [ "%{buildroot}" != / ] && rm -rf "%{buildroot}" %makeinstall ... %find_lang %{name} %files -f %{name}.lang %defattr(-,root,root) /bin/tar ... Si noti come l'argomento `%{name}' della macro `%find_lang' vada sostituito dal nome effettivo dei file *.mo creati, in quei rari casi in cui tali file hanno un nome diverso da `%{name}'. Ad esempio (pacchetti libgtk-2.6.x) %find_lang gtk20 ... %files -f gtk20.lang ... Nota: E' necessario utilizzare rpm versione 4.0.4-22qilnx o successive per potere utilizzare le macro rpm qui descritte. 7. Se si sta creando un pacchetto per modulo perl, sono disponibili le macro rpm `%perl_sitearch' e `%perl_archlib'. Il valore di tali variabili si può ottenere con il comando `rpm --eval='. Ad esempio: $ rpm --eval=%perl_archlib /usr/lib/perl5/5.8.8/i386-linux-thread-multi Se si sta creando un pacchetto python è possibile utilizzare la macro `%python_version' $ rpm --eval=%python_version 2.3 8. Per motivi di sicurezza è opportuno inserire nei blocchi `%prep' e `%clear' il comando [ "%buildroot" != / ] && rm -rf "%buildroot" in luogo dell'istruzione `rm -rf "%buildroot"' o simili. Questa pratica previente spiacevoli situazioni nel caso in cui i pacchetti vengano creati dall'utente root (pratica comunque **assolutamente sconsigliata**) e la variabile `%buildroot' sia settata in modo errato. 9. Quando si elencano i file contenuto nei vari sottopacchetti, utilizzare le variabili rpm, se non i nomi delle directory. Ad esempio, utilizzare `%{_bindir}' in luogo di `/usr/bin', `%{sbindir}' invece di `/usr/sbin'. Per sapere quali sono le variabili rpm disponibili, utilizzare il comando rpm --showrc 10. Le entry del blocco '%changelog' devono rispettare la struttura indicata dal seguente esempio: %changelog * Thu Aug 26 2004 Davide Madrisan 20040813-1qilnx - udpate to 20040813 In particolare deve cioè essere presente il nome e l'indirizzo mail del packager, seguito dalla versione corrente del pacchetto. Nota importante: della maggior parte delle convenzioni indicate nei punti precedenti si occupa 'autospec' in modo automatico. 5. Come contribuire allo sviluppo di autospec Autospec è un tool in fase di sviluppo e seppur testato lungamente potrete imbatterervi in bachi oppure trovare che alcune feature che voi reputate utili siano mancanti. E' possibile inviare sia bugreport che commenti e suggerimenti per migliorare autospec al seguente indirizzo I bug report devono essere dettagliati (versione di autospec, comando eseguito, file di configurazione se necessario, URL del software, se il problema riscontrato riguarda la creazione di uno specfile, il suo aggiornamento, ecc.), in modo da permettere la riproducibilità del problema. Si veda anche il file BUGS contenente un elenco dei bachi noti e feature da implementare. Sono naturalmente ben accette anche le patch. Per il debugging di un problema potrebbe essere utile utilizzare l'opzione `--debug' di autospec. Se si desidera infine contribuire allo sviluppo diretto del tool autospec, inviare una mail all'indirizzo indicato sopra. 6. Traduzioni . English