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:

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:

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

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:

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:

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:

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

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:

Il file my.spec minimale sarebbe:

Si può però fare di più, identificando anche il tipo di file, separando quelli di tipo documentativi e quelli di configurazione, in questo modo:

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

-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:

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 : 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.

NON usare questi tag, in quanto sono parole riservate: Packager Vendor Copyright

-Macro

Le macro sono consigliate al posto di percorsi e valori!

La macro è un testo nel formato %{string}. Tipiche macro:

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:

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:

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.

Ciaoooooooooooooooooooooo