remove italian howto
Signed-off-by: Davide Madrisan <davide.madrisan@gmail.com>
This commit is contained in:
Davide Madrisan
parent
7b881f8e4f
commit
2af2c5bdc7
@ -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 <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>
|
|
||||||
Loading…
Reference in New Issue
Block a user