diff --git a/autospec-it-HOWTO b/autospec-it-HOWTO deleted file mode 100644 index 367ce3b..0000000 --- a/autospec-it-HOWTO +++ /dev/null @@ -1,583 +0,0 @@ - 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