| Line 85: | Line 85: | ||
Il <code> %changelog</code> 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 <code>rpm --changelog -q <packagename></code>, comando molto utile per esempio per scoprire se presenti patch specifiche; questo grazie alla diligenza dei Fedora packager che includono queste informazioni [[http://cve.mitre.org/|CVE]]. | Il <code> %changelog</code> 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 <code>rpm --changelog -q <packagename></code>, comando molto utile per esempio per scoprire se presenti patch specifiche; questo grazie alla diligenza dei Fedora packager che includono queste informazioni [[http://cve.mitre.org/|CVE]]. | ||
Il changelog dovrebbe includere la versione per escludere complicanze con rpmlint. | |||
Sezioni a linea multipla come <code> %changelog</code> o <code> %description</code> iniziano nella linea inferiore e terminano con una linea vuota. | |||
Linee non necessarie (ad esempio <code>BuildRequires</code> e <code>Requires</code>) possono essere commentate con il cancelletto ('#') per adesso. | |||
Molte linee del modello non è necessario modificarle in molti casi, almeno nel primo tentativo. | |||
=== Building the package === | === Building the package === | ||
Revision as of 12:17, 19 July 2012
.png){kind=small}
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):
# yum install @development-tools # yum 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 [[1]].
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 non è necessario modificarle in molti casi, almeno nel primo tentativo.
Building the package
We are ready for the first run to build source, binary and debugging packages:
$ rpmbuild -ba hello.spec
It will complain and list the unpackaged files, i.e. the files that would be installed in the system that weren't declared as belonging to the package. We need to declare them in the %files section. Do not hardcode names like /usr/bin/, but use macros, like %{_bindir}/hello instead. The manual pages should be declared in the %doc subsection: %doc %{_mandir}/man1/hello.1.gz.
This is an iterative process: after editing the .spec file, rerun rpmbuild.
Since our program uses translations and internationalization, we are seeing a lot of undeclared i18 files. The recommended method to declare them is:
- find the filenames in the
%installstep:%find_lang %{name} - add the required build dependencies:
BuildRequires: gettext - use the found filenames
%files -f %{name}.lang
If the program uses GNU info files, you need to make sure the installation and uninstallation of the package does not interfere with other software on the system, by using this boilerplate:
- delete the 'dir' file in %install:
rm -f %{buildroot}/%{_infodir}/dir Requires(post): infoandRequires(preun): info- add those steps:
%post
/sbin/install-info %{_infodir}/%{name}.info %{_infodir}/dir || :
%preun
if [ $1 = 0 ] ; then
/sbin/install-info --delete %{_infodir}/%{name}.info %{_infodir}/dir || :
fi
A complete hello.spec file
Here's the initial version of 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
With this spec file, you should be able to successfully complete the build process, and create the source and binary RPM packages.
Next you should check them for conformance with RPM design rules, by running rpmlint on the spec file and all RPMs:
$ rpmlint hello.spec ../SRPMS/hello* ../RPMS/*/hello*
If there are no warnings or errors, we've succeeded. Otherwise, append the error messages to the rpmlint -i command to see a more verbose description of the rpmlint diagnostics.
The mock builds
To check that the package build will succeed in the Fedora restricted build environment, check it with mock.
$ mock -r fedora-15-i386 --rebuild ../SRPMS/hello-2.7-1.fc15.src.rpm
References
- https://fedoraproject.org/wiki/How_to_create_an_RPM_package
- https://fedoraproject.org/wiki/Building_RPM_packages_%2820090405%29
- https://fedoraproject.org/wiki/Using_Mock_to_test_package_builds
- https://fedoraproject.org/wiki/Using_the_Koji_build_system
History
Przemek Klosowski wrote this tutorial when he worked through Christoph Wickert's IRC session on building RPMs using Rahul Sundaram suggestion of GNU "Hello World" as a test case. After he wrote up his experience, he found out about the excellent and extensive How to create an RPM package page on this wiki, as well as the Christian Lyder Jacobsen's website. However, Christian isn't planning to update his site, and it seemed that a 5-minute 'fast food' alternative to the more extensive article might suit some people. More in-depth information on using and building RPM packages is available from other sources.