How to create a GNU Hello RPM package/it

In other languages: Deutsch (de) English (en) italiano (it) português do Brasil (pt-br) русский (ru) 中文（中国大陆） (zh-cn) 中文（臺灣） (zh-tw) 日本語 (ja) [edit]

Questa è una guida pratica sulla costruzione dei pacchetti RPM, mostra rapidamente come creare dei semplici pacchetti software sorgente e binari. Si presume di possedere una certa disinvoltura nell'uso dei pacchetti precompilati e con il processo d costruzione di software FOSS.

Per informazioni complete su come creare file RPM inclusi suggirimenti dettagliati, fare riferimento alla pagina How to create an RPM package/it. Se si intende creare un pacchetto RPM per i repository Fedora, seguire il processo su come far parte dei manutentori del Fedora Package Collection seguendone le varie indicazioni.

Questo tutorial mostra la pacchettizzazione del progetto GNU "Hello World". Sebbene sia banale ottenere un printing della dicitura "Hello World", la versione GNU contiene contiene la maggior parte dei componenti usuali associati ad un tipico progetto di software FOSS, includendo configuration/build/install, documentazione, internazionalizzazione, etc. Lo stesso comunque consiste tradizionalmente in un file .tar contenente il codice sorgente e gli script configure/make, ma non include informazioni sulla pacchettizzazione. E' utile per far pratica con la costruzione degli RPM.

Ambiente di sviluppo

Per costruire gli RPM servono degli strumenti di sviluppo. Si tratta di una configurazione da fare una sola volta e consiste in un'installazione attraverso i seguenti comandi dati come amministratore di sistema (root):

# dnf install @development-tools
# dnf install fedora-packager

Se si preferisce testare la procedura di costruzione in una root dedicata, bisogna configurare il proprio utente come membro del guppo mock:

# usermod -a -G mock <your username>

Questi sono i soli comandi che richiedono i privilegi di root. Tutto il restante lavoro dovrebbe essere fatto dal normale utente o da un accout creato appositamente per lo sviluppo. I moderni sistemi basati su RPM, inclusa Fedora, sono configurati per costruire e testare i pacchetti RPM puramente all'interno di un account senza privilegi. Il comando

$ rpmdev-setuptree

imposta un'area di lavoro all'interno di ~/rpmbuild. Questa cartella conterrà diverse sottocartelle per il codice sorgente, i file di configurazione e per i risultanti pacchetti sorgente e binari.

Costruire un rpm "Hello World"

Innanzitutto serve il codice sorgente del progetto software da pacchettizzare, solitamente proveniente dall'upstream (progetto madre). Una volta scaricato dal sito web del progetto, sarà salvato nella cartella ~/rpmbuild/SOURCE, ottenendo un archivio compresso di tipo tarball che sembra essere il preferito da tanti.

$ cd ~/rpmbuild/SOURCES
$ wget http://ftp.gnu.org/gnu/hello/hello-2.8.tar.gz

L'RPM è configurato attraverso i file .spec. Si crea un file hello.spec campione nella cartella appropriata:

$ cd ~/rpmbuild/SPECS
$ rpmdev-newspec hello

Recenti versioni di Emacs e vi hanno modalità di editing del file .spec che ripropongono modelli simili durante la creazione di un nuovo file. Quindi basterebbe usare il seguente comando per esempio per modifcare un file modello (template) automaticamente.

vi hello.spec

All'interno di un file .spec

I campi del fiel .spec necessitano di poche modifiche. Seguire le regole Fedora per questi campi. In questo caso, il file potrebbe iniziare così:

Name:     hello
Version:  2.8
Release:  1
Summary:  The "Hello World" program from GNU
License:  GPLv3+
URL:      http://ftp.gnu.org/gnu/hello    
Source0:  http://ftp.gnu.org/gnu/hello/hello-2.8.tar.gz

%description
The "Hello World" program, done with all bells and whistles of a proper FOSS 
project, including configuration, build, internationalization, help files, etc.

%changelog
* Thu Jul 07 2011 The Coon of Ty <Ty@coon.org> - 2.8-1
- Initial version of the package

Il campo Version dovrebbe corrispondere a quello dell'upstream mentre quello Release indica numericamente il lavoro al'interno di Fedora.

La prima lettera di Summary dovrebbe essere maiuscola per evitare complicanze con rpmlint.

E' responsabilità del packager controllare lo stato della License (Licenza) del software, ispezionando i file sorgente e/o i loro file LICENSE, parlandone con gli autori.

Il tag Group storicamente era usato per classificare il pacchetto secondo la lista /usr/share/doc/rpm-<version>/GROUPS. Gradualmente verrà escluso ma per adesso è bene mantenerlo.

Il %changelog dovrebbe documentare il lavoro di preparazione dell'RPM, specialmente se si tratta di includere patch sulla sicurezza e la correzione di bug ai sorgenti base provenienti dall'upstream. Il Changelog può essere visualizzato con rpm --changelog -q <packagename>, comando molto utile per esempio per scoprire se presenti patch specifiche; questo grazie alla diligenza dei Fedora packager che includono queste informazioni CVE .

Il changelog dovrebbe includere la versione per escludere complicanze con rpmlint.

Sezioni a linea multipla come %changelog o %description iniziano nella linea inferiore e terminano con una linea vuota.

Linee non necessarie (ad esempio BuildRequires e Requires) possono essere commentate con il cancelletto ('#') per adesso.

Molte linee del modello in molti casi non è necessario modificarle, almeno nel primo tentativo.

Costruire il pacchetto

Si inizia con la costruzione dei pacchetti sorgente, binario e di debugging:

$ rpmbuild -ba hello.spec

Verranno elencati i file non impacchettati, cioé quelli installati nel sistema ma che non fanno parte del pacchetto. Bisogna dichiararli nella sezione %files. Nomi come /usr/bin/ non devono essere trattati come hardcode, ma si usano le macro come %{_bindir}/hello. Le pagine del mauale vanno dichiarate nella sottosezione %doc: %doc %{_mandir}/man1/hello.1.gz.

Questo è un processo iterativo: dopo la modifica del file .spec, riavviare rpmbuild.

Siccome i programmi usano traduzioni ed internazionalizazioni, si vedranno molti file i18 non dichiarati. Il metodo raccomandato per dichiararli è:

• trovare i nomi dei file in %install: %find_lang %{name}
• aggiungere le dipendenze richieste per la compilazione: BuildRequires: gettext
• usare i nomi file trovati%files -f %{name}.lang

Se il programma usa file info GNU, bisogna assicurarsi che l'installazione/disinstallazione del pacchetto non interferisca con altri software usando questa espressione standard:

• cancellare il file 'dir' in %install: rm -f %{buildroot}/%{_infodir}/dir
• Requires(post): info and Requires(preun): info
• aggiungere questi passaggi:

%post
/sbin/install-info %{_infodir}/%{name}.info %{_infodir}/dir || :

%preun
if [ $1 = 0 ] ; then
/sbin/install-info --delete %{_infodir}/%{name}.info %{_infodir}/dir || :
fi

Un file hello.spec completo

Ecco la versione originale di hello.spec:

Name:           hello
Version:        2.8
Release:        1%{?dist}
Summary:        The "Hello World" program from GNU

License:        GPLv3+
URL:            http://ftp.gnu.org/gnu/%{name}
Source0:        http://ftp.gnu.org/gnu/%{name}/%{name}-%{version}.tar.gz

BuildRequires: gettext
      
Requires(post): info
Requires(preun): info

%description 
The "Hello World" program, done with all bells and whistles of a proper FOSS 
project, including configuration, build, internationalization, help files, etc.

%prep
%setup -q

%build
%configure
make %{?_smp_mflags}

%install
%make_install
%find_lang %{name}
rm -f %{buildroot}/%{_infodir}/dir

%post
/sbin/install-info %{_infodir}/%{name}.info %{_infodir}/dir || :

%preun
if [ $1 = 0 ] ; then
/sbin/install-info --delete %{_infodir}/%{name}.info %{_infodir}/dir || :
fi

%files -f %{name}.lang
%doc AUTHORS ChangeLog COPYING NEWS README THANKS TODO
%{_mandir}/man1/hello.1.gz
%{_infodir}/%{name}.info.gz
%{_bindir}/hello

%changelog
* Tue Sep 06 2011 The Coon of Ty <Ty@coon.org> 2.8-1
- Initial version of the package

Con esso si dovrebbe essere in grado di completare il processo di costruzione e creare i pacchetti sorgente e binario.

Poi si dovrebbero controllare le conformità con le regole di progettazione usando rpmlint sul file spec e tutti gli RPM:

$ rpmlint hello.spec ../SRPMS/hello* ../RPMS/*/hello*

Se non ci sono errori o avvisi, è andato tutto bene. In caso contrario, usare il comando rpmlint -i o rpmlint -I error_code per avere una descrizione approfondita.

Le compilazioni con mock

Per verificare se il pacchetto verrà compilato bene in un ambiente Fedora limitato, usare mock. Con la configurazione predefinita, mock costruisce il pacchetto nella versione Rawhide - il ramo di sviluppo di Fedora.

$ mock --verbose ../SRPMS/hello-2.7-1.fc19.src.rpm

Riferimenti

• How_to_create_an_RPM_package/it
• Building RPM packages (20090405)
• Using Mock to test package builds
• Using the Koji build system

Storia

Przemek Klosowski scrisse questo tutorial quando fa lavorato con la Sessione IRC sulla costruzione degli RPM di Christoph Wickert usando il suggerimento di Rahul Sundaram di usare GNU "Hello World" come banco di prova. Dopo aver scritto la sua esperienza, scoprì l'eccellente ed estesa pagina wiki How to create an RPM package/it, nonché il sito web di Christian Lyder Jacobsen. Informazioni più approfondite sull'utilizzo e la creazione di pacchetti RPM sono disponibili da altre fonti.