remove italian howto
Signed-off-by: Davide Madrisan <davide.madrisan@gmail.com>
This commit is contained in:
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