openmamba/autospec
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
0484d69511
autospec/autospec-it-HOWTO
Silvan Calarco aa237198c2 Initial commit
2011-04-26 21:39:44 +02:00

584 lines
24 KiB
Plaintext
Raw Blame History

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 <davide.madrisan(a)gmail.com>.
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="<Your Name>"
packager_email="<email>@openmamba.org"
ftp_rw_user[1]="<user>"
ftp_rw_passwd[1]="<passwd>"
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 <tarball> [-n <name>] [-v <ver>] [-t <type>] [-o <outfile>]
dove le precedenti opzioni significano, nell'ordine:
-s, --source Cerca di creare uno specfile per il <tarball> 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 <outfile>
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 <pck> -a<lst> [<ver>] [<rel>] [-d v1=r1[,v2=r2,...]] \
[-l usr:pswd] [-S <specfile>] [-A <arch>] \
[--server-download <int>] [--server-upload <int>] \
[--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 <pck>, versione <ver>
-a, --action Esegue la lista di azioni separate da virgole <lst>
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: <name>.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/<nomepacchetto>_<data><ora>
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}-<versione>-<descrizione>.patch
dove '<versione>' indica il numero di versione del software in cui la
patch è stata per la prima volta applicata, e `<descrizione>' 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<61>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=<rpmmacro>'.
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 <davide.madrisan@qilinux.it> 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
<davide.madrisan(a)gmail.com>
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 <http://will be available ASAP>
Reference in New Issue View Git Blame Copy Permalink