Ringrazio
https://blog.prometheusproject.it/creare-pacchetti-rpm-su-centosrhel/
https://digilander.libero.it/robang/linux/makerpm-howto.htm
https://fedoraproject.org/wiki/How_to_create_an_RPM_package/it
Questo manualino non è completo, ed è rivolto per chi già dispone di una buona manualità in Linux e soprattutto conosce la programmazione.
Installazione utility
Per prima cosa installare rpm-build
Poi create una directory dove mettere (non ora) quello che vogliamo pacchettizzare. Fatela nella vostra home meglio in cartella con il nome “RPM-build”.
Partenza
Non si dovrebbe MAI creare un pacchetto usando l'utente Root. Farlo è pericoloso, poiché i file binari vengono installati nel sistema prima di essere impacchettati, quindi bisogna sempre operare come utente normale in modo da non inquinare accidentalmente il proprio sistema. |
-Creare il tar
ATTENZIONE: Il path del TAR deve corrispondere ad una vera installazione, eventuali errori o trasgressioni causano che il pacchetto non può essere fatto!
Supponiamo di dover creare un pacchetto che installa uno script in bash (mio.sh) in /opt/mioscript.
Creiamo la directory che conterrà il nostro script, ed entriamo all’interno della stessa:
mkdir mioscript-1.0
cd mioscript-1.0
Notate che dobbiamo qui specifichiamo la versione nel nome del nostro programma, in questo caso “1.0”. Questo è solo un buon modo di lavorare per non fare casini con diversi tipi. Se esiste una possibilità che sia 32bit o 64bit o altra CPU dobbiamo anche specificarla, come dobbiamo anche specificare se è legato ad un altro programma, esempio: xsane-gimp-0.996-7.fc11.x86_64 In questo caso un pacchetto di xsane per il programma Gimp versione “0.996-7.fc11” per CPU “x86” Intel da “64” Bit. |
copiamo il nostro script nella directory attuale:
cp /il-path-del-mio-script/mioscript.sh .
Adesso arriva la parte difficile… Insomma… Dobbiamo spiegare cosa facciamo al RPM.
Creiamo il file configure con relativi permessi di esecuzione:
touch configure
chmod u+x configure
Nota: In questo esempio è vuoto dato che è uno script il programma e quindi non va compilato ma poi servirà riempirlo in casi più complessi con i dati come compilarlo.
Torniamo indietro nella directory e creiamo il tar.gz
cd ..
tar cvfz mioscript-1.0.tar.gz myscript-1.0/
Una volta creato il tar.gz è possibile eliminare la directory appena creata se volete
-Creiamo la struttura
Adesso creiamo l’albero delle directory necessarie per la creazione dell’RPM, questo semplicemente con il comando:
rpmdev-setuptree
Un attimo e poi noteremo che verrà creata una directory “rpmbuild” con relative sottodirectory
Queste sono:
Percorso Predefinito | Funzione | Nome | Nome della Macro |
~/rpmbuild/SPECS | File SPEC degli RPM (.spec) | Specification directory | %_specdir |
~/rpmbuild/SOURCES | Pacchetto dei sorgenti incontaminati (es: tarballs) e patch | Source directory | %_sourcedir |
~/rpmbuild/BUILD | I file sorgente vengono spacchettati e compilati nella sua subdirectory. | Build directory | %_builddir |
~/rpmbuild/BUILDROOT | I file vengono installati qui durante la fase %install. | Build root directory | %_buildrootdir |
~/rpmbuild/RPMS | Binari RPM sono creati e immagazzinati qui sotto. | Binary RPM directory | %_rpmdir |
~/rpmbuild/SRPMS | Gli RPM sorgente sono creati e immagazzinati qui sotto. | Source RPM directory | %_srcrpmdir |
Copiamo il nostro (tar.gz creato precedentemente) nella directory rpmbuild/SOURCES con il comando:
cp mioscript-1.0.tar.gz rpmbuild/SOURCES/mioscript-1.0.tar.gz
-Il file spec
Per creare un pacchetto RPM, è necessario creare un file di testo ".spec" che fornisce informazioni sul software che viene pacchettizzato.
Ora entriamo nella directory rpmbuild/SPEC e creiamo un file .spec di esempio:
cd rpmbuild/SPEC
rpmdev-newspec
Verrà creato un file “newpackage.spec” che potremmo prendere di esempio per generare quello che ci serve.
Rinominiamolo con il nome del nostro pacchetto:
mv newpackage.spec mioscript.spec
A questo punto editiamolo in questo modo:
Name: mioscript
Version: 1.0
Release: 1%{?dist}
Summary: script in bash test
Group: Miscellaneus
License: GPLv2+
Source0: mioscript-1.0.tar.gz
BuildArch: noarch
%description
Pacchetto rpm per la copia di uno script in bash
%prep
%setup -q
%build
#%configure
#make %{?_smp_mflags}
%install
rm -rf $RPM_BUILD_ROOT
install -d -m 0755 $RPM_BUILD_ROOT/opt/mioscript
install -m 0644 mioscript.sh $RPM_BUILD_ROOT/opt/mioscript/mioscript.sh
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
/opt/mioscript/mioscript.sh
%changelog
Nota : La spiegazione verrà data dopo.
Salviamo il file .spec
-Creazione RPM
Creiamo l’RPM con il comando:
rpmbuild -ba mioscript.spec
Il nostro RPM si creerà in
rpmbuild/RPMS/noarch
Adesso possiamo procedere con la distribuzione del pacchetto.
Nota: Meglio provarlo prima se funziona.
Per interrogarlo
rpm -qi nomepacchetto
Lo SPEC
-Nomenclatura spec
Tutte le caratteristiche di un pacchetto rpm sono contenute nel relativo file .spec. Si tratta di un file ASCII strutturato in varie sezioni, ognuna delle quali inizia con un identificativo del tipo %string. In aggiunta, in testa al file stesso, devono essere presenti alcuni record di assegnamento, tipo ``Name:'', ``Release'', ecc.
Vediamo la prima parte dell’esempio
Name: mioscript
Version: 1.0
Release: 1%{?dist}
Summary: script in bash test
Group: Miscellaneus
License: GPLv2+
Source0: mioscript-1.0.tar.gz
BuildArch: noarch
%description
Pacchetto rpm per la copia di uno script in bash
Non ci dilunghiamo in quanto è palese.
Nota: %{?dist} è una macro che ricopia il nome del tipo distribuzione. Si consiglia di usarlo di default.
%prep
%setup -q
%prep : In cui il file deve essere decomposto e preparato per la compilazione. Di solito é composta semplicemente da una sottosezione %setup, che vediamo sotto e che ha come compito principale di scompattare il sorgente, eseguendo il tar sul file, il cui nome é ricavato dal tag Source, posto all'interno del file .SPEC stesso.
%build
#%configure
#make %{?_smp_mflags}
%build : Qui l'RPM, configura e compila il pacchetto, dopo averlo scompattato.
Notare che esendo uno script è inutile compilarlo e quindi abbiamo commentato con # le righe dopo per non farle eseguire. Infatti se fosse in questo modo:
%configure
make %{?_smp_mflags}
eseguirebbe il file “configure” e dopo lo compilerebbe con il comando Make.
Poi… installiamo..
%install
rm -rf $RPM_BUILD_ROOT
install -d -m 0755 $RPM_BUILD_ROOT/opt/mioscript
install -m 0644 mioscript.sh $RPM_BUILD_ROOT/opt/mioscript/mioscript.sh
Prima puliamo eventuali compilazioni e altro con “rm”. $RPM_BUILD_ROOT indica il vecchio pacchetto.
Poi come copiarlo con il comando “install”: Dopo la compilazione (se esiste o meno) i file vanno copiati nelle posizioni adeguate, e per far ció basta fare il comando install. Si noti che anche qui non usiamo il Makefile in quanto non compilato, quindi usiamo il comando install oppure un semplice cp.
Poi infine la sezione “clean”
%clean
rm -rf $RPM_BUILD_ROOT
%clean. Vengono eliminati i vecchi dati e per far questo: crm -fr nomepacchetto oppure usiamo la variabile $RPM_BUILD_ROOT (consigliato)
Quindi passiamo oltre
%files
%defattr(-,root,root,-)
/opt/mioscript/mioscript.sh
%changelog
%files. Dopo aver svolto le sessioni precedenti, i files sono posizionati sul disco rigido, ma non sono posti come dovrebbero. Bisogna dire all'RPM dove trovare i file, siccome durante l'esecuzione delle sezioni precedenti l'RPM non ne ha tenuto traccia. E questa operazione viene svolta mediante la sezione %files. I file di configurazione vanno specificati nella direttiva %config e quelli di documentazione con la direttiva %doc. che il RPM copia automaticamente quest'ultimi nella directory /usr/doc/nome-pacchetto.
%defattr : Definisce cosa si tratta, come default attributo, in questo caso “/opt/mioscript/mioscript.sh”.
--Sezione dei file di specifica RPM più usati
Sezione | Descrizione |
Summary: testo | Panoramica sul pacchetto. |
Nome: pacchetto | Nome del pacchetto. |
Versione: versione | Versione del pacchetto. |
Release: release | Release del pacchetto |
Source: file | File sorgente. |
Patch: file | Patch da applicare. |
Copyright: Testo | Tipo di licenza |
BuildRoot: directory | Directory temporanea di installazione. |
%define nomevalore | Definizione di una macro. |
%description | Segue descrizione |
%prep | Segue fase di preparazione. |
%setup | Scompatta il pacchetto. |
%patch | Applica la patch indicata. |
%build | Segue istruzioni per la compilazione. |
%install | Segue istruzioni per l'installazione. |
%clean | Segue fase rimozione fine lavoro |
%pre | Segue script di pre-installazione. |
%post | Segue script di post-installazione. |
%preun | Segue script di pre-disintallazione. |
%postun | Segue script di post-disinstallazione. |
%files | Segue elenco files. |
%config | Segue file di configurazione. |
%doc | Segue file di documentazione. |
Sezione | Descrizione |
Qui abbiamo diversi esempi da applicare:
https://digilander.libero.it/robang/linux/makerpm-howto.htm
-Esempio spec minimale
Supponiamo ad esempio di voler costruire un pacchetto rpm (denominato my), costituito dai seguenti file:
/etc/my.conf
/usr/local/man/man1/my.1
/usr/local/bin/my
/usr/local/lib/my/*.sample
Il file my.spec minimale sarebbe:
# my.spec
Name: my
Summary: Controllo periodo Conti della Famiglia
Version: 1.0
Release: 1
Copyright: SANVITTORE
Group: Application/CashControl
Packager: berl@sanvittore.it
%description
Programma per l'amministrazione periodica
e programmata dei conti bancari.
%files
/etc/my.conf
/usr/local/man/man1/my.1
/usr/local/bin/my
/usr/local/lib/my/larini
/usr/local/lib/my/intini
Si può però fare di più, identificando anche il tipo di file, separando quelli di tipo documentativi e quelli di configurazione, in questo modo:
%files
/usr/local/lib/my/larini
/usr/local/lib/my/intini
/usr/local/bin/my
%config /etc/my.conf
%doc /usr/local/man/man1/my.1
ATTENZIONE: Disinstallando il pacchetto, accade però una cosa spiacevole: la directory /usr/local/lib/my
non viene rimossa perchè il comando “rpm -e” e molto sospettoso e vuole essere certo che la directory non appartenga a qualche altro pacchetto.
Se io volessi che questa directory facesse parte del mio pacchetto (attenzione che lo sia) dovrei soltanto aggiungere la direttiva
%dir /usr/local/lib/my
ATTENZIONE: Ben diverso sarebbe il risultato se aggiungessi %dir /etc con rpm -e my, il comando rpm tenterebbe di eliminare anche la directory /etc e si arrabbierebbe, trovandola non vuota. |
-Procedure “prima, dopo, durante”
In installazione e della disinstallazione di un pacchetto è possibile attivare delle procedure predefinite, descritte con speciali direttive
%post, %preun e %pre
La prima (%post) viene attivata subito dopo l'installazione; la seconda (%preun) subito prima della disinstallazione e la terza (%pre) prima dell'installazione.
Ecco un esempio esplicativo:
%pre
echo "Sto per installare il tuo pacchetto..."
%post
echo "Installazione completata."
%preun
echo "Ok, ma attenzione! Ti stai privando "
echo "di un software vitale!"
Riepilogando:
%pre = prima dell'installazione.
%post= dopo l'installazione.
%preun = prima della disinstallazione.
Nota: Ci sono dei limiti di sicurezza, quindi quello che potete o non, sono limitati.
-Richiede in spec
Per alcuni programmi è necessario che ci siano certe librerie o altri programmi.
Esempio installazione di un programma Java
BuildRequires:unzip
BuildRequires:update-alternatives java-1_5_0-sun-devel
BuildRequires:ant
Requires: java >= 1.5.0
BuildRequires : In fare di installazione richiede di questo.
Requires : Per funzionare il programma richiede questo. Notare qui (ma anche BuildRequires) che si può usare la notazione matematica per definire la versione richiesta.
In aggiunta ai tag Requires e BuildRequires, esistono questi per il controllo delle dipendenze:
Provides: lista i nomi dei pacchetti virtuali forniti. Ad esempio, ci potrebbe essere un pacchetto "foo" che esige una particolare funzionalità "bar" da un altro programma. Se esistono parecchi pacchetti che epossono soddisfarla, è possibile specificarli con "Provides: bar" e il pacchetto "foo" può specificare "Requires: bar". Si potrebbero anche usare metodi "alternativi", ma evitare se più utenti hanno necessità differenti, visto che queste impostazioni sono a livello di sistema. Usare "rpm -q --provides PACKAGENAME" per vedere cosa fornisce un determinato pacchetto. Alcuni esempi di pacchetti virtuali in Fedora:
MTA: Usato per i mail transport agents come sendmail.
tex(latex): Usato per latex
Obsoletes: rimuove un altro pacchetto(i) nominato(i) se installato(i). Usare se il nome del pacchetto cambia o se è totalmente rimpiazzato da un differente pacchetto.
Conflicts: specifica quali altri pacchetti non possono essere installati simultaneamente a quello in oggetto. Evitarlo se possibile.
BuildConflicts: specifica quali pacchetti non possono essere installati se si costruisce il pacchetto in oggetto. Evitarlo se possibile.
Per gestire differenti architetture, ci sono due tag:
ExcludeArch: per escluderne una nella quale la costruzione del pacchetto non avviene. Ad esempio:
ExcludeArch: ppc
ExclusiveArch: per includere solo quella specificata. Evitarlo se non assolutamente corretto.
-Panoramica del file spec
ATTENZIONE: Si possono inserire commenti con il carattere "#", ma non inserire le potentially-multiline-macros (parole che iniziano con "%") in un commento (le macro vengono espanse prima); se si decommenta una linea, raddoppiare il segno percentuale ("%%"). Inoltre, non usare "#" sulla stessa linea dopo un comando script.
I principali tag sono listati di seguito.
Notare che le macro %{name}, %{version} and %{release} possono essere usate come riferimento a Nome, Versione e Release rispettivamente. Quando si cambia un tag, la macro automaticamente aggiorna al nuovo valore.
Name: Il nome del pacchetto, che dove coincidere con quello dello SPEC file. Deve seguire le Linee Guida e generalmente usa caratteri minuscoli.
Version: Il numero di versione dall'upstream. Vedere la Sezione Version tag delle linee guida sulla pacchettizzazione. Se il numero di versione contiene tag non numerici, è necessario includere il carattere non numerico nel tag Release. Se l'upstream usa la data per intero per distinguere le versioni, considerare l'uso di numeri di versione nella forma yy.mm[dd] (ad esempio 2008-05-01 diventa 8.05).
Release: Il valore iniziale dovrebbe essere 1%{?dist}. Incrementare il numero ad ogni nuovo rilascio della stessa versione. Quando arriva un nuovo rilascio, cambiare il tag Version per abbinare e reimpostare in numero Release a 1. Controllare la sezione Release delle linee guida. L'opzionale Dist tag potrebbe essere utile.
Summary: Un breve sommario one-line del pacchetto. Usare l'inglese americano per quelle pubbliche. NON finisce con una sola frase.
License: La licenza che nei repository pubblici deve essere open source. Non usare vecchi tag Copyright. Usare abbreviazioni standard ("GPLv2+") e specifiche (usare "GPLv2+" per la GPL versione 2 o successive invece del solo "GPL" oppure "GPLv2"). Vedere Licensing e le Licensing Guidelines. E' possibile listare più licenze combinandole con "and" e "or" (ad esempio "GPLv2 and BSD").
URL: L'intero URL per avere maggiori informazioni sul programma (ad esempio il sito del progetto). Nota: Non è un collegamento al codice sorgente originale che invece appare al tag Source0.
Source0: L'intero URL all'archivio compresso contenente il codice sorgente originale, come rilasciato dall'upstream. "Source" è sinonimo di "Source0". Se si fornisce l'URL completo (come dovrebbe essere), il suo nome verrà utilizzato nella cartella SOURCES. Se possibile, incorporare %{name} e %{version}, così che le modifiche possano andare al posto giusto. Preservare il timestamps quando si scaricano i file sorgente. Se esistono più sorgenti, nominarli Source1, Source2 e così via. Se si aggiungono nuovi file, listarli come sorgenti dopo quelli originali. Una copia di ognuno di questi verrà inclusa in un SRPM, se non diversamente specificato. Vedere Source URL per maggiori informazioni su casi speciali (ad esempio sulla revisione).
Patch0: Il nome della prima patch da applicare al sorgente. Se serve applicare una patch dopo la decompressione, si dovrebbero editare i file e salvarne le modifiche come "file .patch" nella cartella ~/rpmbuild/SOURCES. Le Patch dovrebbero fare una modifica alla volta, quindi è possibile avere più file .patch .
BuildArch: Se i file da pacchettizzare sono indipendenti dall'architettura (ad esempio shell script, file data), allora aggiungere "BuildArch: noarch". L'architettura per gli RPM binari sarà "noarch".
BuildRoot: La cartella "d'installazione" durante il processo %install (dopo %build). E'aggiuntivo in Fedora mentre è necessario in EPEL5. Normalmente la root build è in "%{_topdir}/BUILDROOT/".
BuildRequires: Lista dei pacchetti richiesti per la compilazione del programma. Questo campo può essere (e lo è comunemente) ripetuto su più linee. Queste dipendenze non sono automaticamente determinate così serve includerle tutte. Alcuni pacchetti comuni possono essere omessi, come gcc. E' possibile specificarle in minima parte se necessario (ad esempio "ocaml >= 3.08"). Se serve il file /EGGS, determinarne il pacchetto che lo possiede con "rpm -qf /EGGS". Se serve il programma EGGS, determinarne il pacchetto che lo possiede con "rpm -qf which EGGS". Mantenere le dipendenze ad un numero minimo (ad esempio usare sed invece di perl se non serve realmente perl), ma attenzione poiché alcune applicazioni disabilitano permanente le funzioni associate a dipendenze mancanti; in questi casi serve includere i pacchetti addizionali. Il pacchetto auto-buildrequires può essere utile.
Requires: Lista di pacchetti richiesti quando in programma è installato. Notare che il tag BuildRequires lista ciò che serve per la compilazione dell'RPM binario, mentre il tag Requires lista ciò che è necessario per installare e far funzionare il software; un pacchetto può essere presente in entrambe le liste. In molti casi rpmbuild recupera automaticamente le dipendenze quindi il Requires tag non è sempre utile. Tuttavia è possibile evidenziare pacchetti specifici richiesti.
%description: Una lunga descrizione del programma. Usare l'inglese americano. Tutte le linee devono essere al massimo di 80 caratteri. Le linee vuote indicano un nuovo paragrafo. Alcune interfaccie grafiche d'installazione software riformatteranno i paragrafi; le linee che iniziano con uno spazio vuoto verranno trattate come testo preformattato e visualizzate come sono, normalmente con caratteri fixed-width. Vedere la Guida RPM.
%prep: Comandi script per "preparare" il programma (ad esempio decomprimere) così che tutto sia pronto per la compilazione. Tipcamente "%autosetup"; una comune variante è "%autosetup -n NAME" se il file sorgente spacchetta in NAME. Vedere la sezione %prep.
%build: Comandi script per "costruire" il programma (ad esempio compilare) ed ottenerlo pronto per l'installazione. Incluse le istruzioni su come farlo.
%check: Comandi script per "testare" il programma. E' avviato tra le procedure %build e %install, quindi piazzarlo tra le due se serve. Spesso contiene semplicemente "make test" oppure "make check". E' separato da %build così da poter essere saltato a discrezione dell'utente.
%install: Comandi script per "installare" il programma. I comandi dovrebbero copiare file dalla cartella BUILD %{_builddir} nella buildroot %{buildroot}. Vedere la sezione %install.
%clean: Istruzioni su come ripulire la build root. Notare che questa sezione è ridondante. Tipicamente contiene solo:
rm -rf %{buildroot} # ridondante eccetto per RHEL 5 e superiori
%files: Lista di file che saranno installati. Vedere la sezione %files.
%changelog: Modifiche nel pacchetto. Usare l'esempio sopra. NON inserire il changelog storico del software. Questo riguarda solo quello dell'RPM stesso.
ExcludeArch: Se il pacchetto non compila, costruisce o funziona correttamente in una particolare architettura, listare le architetture coinvolte sotto questo tag.
E' possibile aggiungere sezioni in modo da avviare codice quando i pacchetti vengono installati o rimossi nel sistema reale (piuttosto che avviare soltanto lo script %install, che opera soltanto una pseudo-installazione nella build root). Queste sono chiamate "scriptlets" e solitamente sono usate per aggiornare il sistema avviato con informazioni dal pacchetto. Vedere la sezione "Scriptlets".
RPM inoltre supporta la creazione di diversi pacchetti (detti subpackage) da un singolo SPEC file, come name-libs e name-devel.
-Macro
Le macro sono consigliate al posto di percorsi e valori!
La macro è un testo nel formato %{string}. Tipiche macro:
Macro | Estensione tipica | Significato |
%{_bindir} | /usr/bin | Cartella dei binari: dove gli eseguibili vengono solitamente localizzati. |
%{_builddir} | ~/rpmbuild/BUILD | Cartella per il build: i file sono compilati all'interno della sua sottocartella. Vedere %buildsubdir. |
%{buildroot} | ~/rpmbuild/BUILDROOT | Build root: dove i file vengono "installati" durante %install, che li copia dalla sottocartella di %{_builddir} a quella di %{buildroot}. (Storicamente, %{buildroot} era in "/var/tmp/".) |
%{buildsubdir} | %{_builddir}/%{name} | Sottocartella build: interna a %{_builddir} dove i file sono compilati durante %build. E' impostata dopo %autosetup. |
%{_datadir} | /usr/share | Cartella condivisa. |
%{_defaultdocdir} | /usr/share/doc | Cartella predefinita della documentazione. |
%{dist} | .fcNUMBER | Versione della distro (ad esempio ".fc30") |
%{_linux} | NUMBER | Numero di rilascio Linux (e.g. "30") |
%{_includedir} | /usr/include |
|
%{_infodir} | /usr/share/info |
|
%{_initrddir} | /etc/rc.d/init.d | Vedere raccomandazioni nella guida completa. |
%{_libdir} | /usr/lib |
|
%{_libexecdir} | /usr/libexec |
|
%{_localstatedir} | /var |
|
%{_mandir} | /usr/share/man |
|
%{name} |
| Nome del package, set by Name: tag |
%{_sbindir} | /usr/sbin |
|
%{_sharedstatedir} | /var/lib |
|
%{_sysconfdir} | /etc |
|
%{version} |
| Versione del pacchetto, impostata tramite il tag Version: |
Se ne può sapere di più sulle macro guardando in /etc/rpm/* e /usr/lib/rpm, specialmente /usr/lib/rpm/macros.
Inoltre usare rpm --showrc per saperne i valori che RPM userà per le macro (alterate da rpmrc e i file di configurazione delle macro).
E' possibile impostare le proprie macro usando %global, ma assicurarsi di definirle prima dell'uso. (Le definizioni possono riferirsi anche ad altre macro.) Per esempio:
%global date 2012-02-08
Usare l'opzione "-E"di rpmbuild per trovare il valore della macro nello .spec file:
rpmbuild -E '%{_bindir}' myfile.spec
-Sequenza di spec
rpmbuild legge il file .spec e segue le seguenti fasi di lavoro:
N. | Nome Macro | Nome | Predefinito | Funzione |
1 | %prep | %_sourcedir | %_builddir | Legge i sorgenti e le patch nella directory %_sourcedir. Questa fase scompatta il sorgente in una sotto-directory inferiore alla directory di build %_builddir (di solito ~/rpmbuild/BUILD/) e applica le patch. |
2 | %prep | %_sourcedir | %_builddir | Compila i file nella directory sotto quella di build %_builddir. Di solito si possono realizzare qui alcune variazioni di "./configure && make". |
3 | %check | %_builddir | %_builddir | Verifica che il software funziona propriamente. Fase spesso realizzata per eseguire alcune variazioni di "make test". Molti pacchetti non realizzano questa fase. |
4 | %install | %_builddir | %_buildrootdir | Questa fase legge i file nella directory sotto quella di build %_builddir e scrive in una directory sotto la root build directory %_buildrootdir. I file che sono scritti si suppone che saranno installati quando il pacchetto dei binari viene installato dall'utente finale. Attenzione alla strana terminologia: La directory build root non è la stessa della build directory. Questa fase è realizzata da "make install". |
5 | bin | %_buildrootdir | %_rpmdir | Legge la directory sotto la build root directory %_buildrootdir per creare un pacchetto RPM binario sotto la directory RPM %_rpmdir. All'interno della directory RPM vi è una directory per ogni architettura ed una denominata "noarch" per pacchetti che si possono applicare a molte architetture. Questi file RPM sono i pacchetti che gli utenti andranno ad installare. |
6 | src | %_sourcedir | %_srcrpmdir | Questa crea un pacchetto sorgente RPM (.src.rpm) all'interno della directory RPM sorgente %_srcrpmdir. Questi file sono necessari per una revisione e un aggiornamento del pacchetto. |
Se una fase si interrompe prematuramente, è necessario guardare l'output per capire perché è fallita, (di solito) cambiare il file .spec (o altri file di input) a seconda delle necessità.
-Condizionali
E' possibile inserire stati di condizione, ad esempio per verificare se si sta creando un binario per una certa architettura:
%ifarch ARCHITECTURE_NAME
versione negata con:
%ifnarch ARCHITECTURE_NAME
o più condizioni generiche:
%if TRUE_OR_FALSE
C'é una sezione opzionale " %else "; tutte queste vengono chiuse con " %endif ".
Esempio di /etc/rpmrc.
Qui si scrive le informazioni generali
Vediamo come puo essere settato il file di configurazione di RPM:
require_vendor: 1
distribution: OpenSUSE
require_distribution: 1
topdir: /usr/src/packs
vendor: ImperatoriDelMondo
packager: ImperatoriDelMondo Gestione Software <bo@softsoftma.it>
optflags: i386 -O2 -m486
optflags: alpha -O2
optflags: sparc -O2
signature: pgp
pgp_name:
pgp_path: /home/packages/.pgp
tmppath: /tmp
optflags : Definisce per quale microprocessore deve essere compilato
signature: pgp
pgp_name:
pgp_path: /home/packages/.pgp
Qui se avete una signature per rendere il pacchetto protetto da eventuali manomissioni.
tmppath: /tmp
Qui invece la directory temporanea da usare.
Comandi base RPM utili
Disporre di un tool di questo tipo significa innanzitutto poter installare (rpm -i), disinstallare (rpm -e) e aggiornare (rpm -U) il software in maniera immediata, ma anche rispondere a domande più specifiche, quali:
quanti pacchetti ho installato fin'ora?
(rpm -qa | wc -l )tra quanto 111111111111ho installato, quali sono i pacchetti attinenti in qualche modo al mondo TeX?
(rpm -qia | grep -i tex )quali file costituiscono esattamente questo pacchetto?
(rpm -ql)chi ha lasciato qui questo file?
(rpm -f)l'insieme di file del pacchetto è ancora integro?
(rpm -V)quali sono i file di documentazione e quali quelli di configurazione?
(rpm -qld o rpm -qlc)di quali prerequisiti ha bisogno questo pacchetto per funzionare correttamente?
(rpm --requires -q)
Per SUSE e guide
Meglio seguire le linee guida definite qui:
https://it.opensuse.org/openSUSE:Linee_guida_per_la_creazione_dei_pacchetti
https://it.opensuse.org/openSUSE:Linee_guida_per_la_creazione_dei_pacchetti#Linee_guida_generali
Altre utili guide:
La Guida RPM descrive nei dettagli come riempire uno spec file.
La serie IBM "Packaging software with RPM" Parte 1, Parte 2 e Parte 3 è altrettanto utile.
Maximum RPM ha informazioni più complete ma è datata.
Seguire la linee guida Package Naming Guidelines, Packaging Guidelines e Package review guidelines.
Conclusioni
Non cercare di interagire con l'utente; RPM è designato per supportare tante installazioni. Se un'applicazione necessita di mostrare esempio un EULA (End User License Agreement), quest'ultima dev'essere parte dell'esecuzione iniziale e non dell'installazione.
Non si dovrebbero avviare servizi poiché potrebbero rallentare il tutto o bloccare il tutto.
Se si installa uno script init e systemd, considerare l'uso di chkconfig o meglio di systemctl per far sì che gli stessi vengano avviati o arrestati al successivo riavvìo. Prima di disinstallare, si dovrebbe normalmente tentare di fermare i suoi servizi se in esecuzione in quel momento.
La disinstallazione dovrebbe togliere tutte le modifiche fatte nell'installazione, ma non i file creati dall'utente.
Normalmente, se ci sono binari eseguibili, i simboli di debugging sono tolti dall'rpm binario normale e piazzati in un sottopacchetto name-debug. Se non dovesse succedere, si può disabilitare la creazione dell'rpm-debug aggiungendo in cima allo .spec file:
Non è tanto difficile creare un pacchetto, ma vi accorgerete che ci sono situazioni paradossali.
Tenete conto che esiste sempre uno specializzato in pacchettizzazione anche in Windows, quindi non perdetevi d’animo.