584 lines
24 KiB
Plaintext
584 lines
24 KiB
Plaintext
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>
|