From Fedora Project Wiki
 
(24 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{autolang}}
{{autolang}}
{{admon/caution|La traduzione di questa pagina è incompleta}}


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.  
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.  
Line 14: Line 12:


<pre>
<pre>
# yum install @development-tools
# dnf install @development-tools
# yum install fedora-packager
# dnf install fedora-packager
</pre>
</pre>


Line 32: Line 30:
== Costruire un rpm "Hello World" ==
== Costruire un rpm "Hello World" ==


We need the source code of the project we are packaging, often referred
Innanzitutto serve il codice sorgente del progetto software da pacchettizzare, solitamente proveniente dall'upstream (progetto madre).  
to as the 'upstream' source. We will download it from the project's website  into the <code>~/rpmbuild/SOURCE</code>
Una volta scaricato dal sito web del progetto, sarà salvato nella cartella <code>~/rpmbuild/SOURCE</code>, ottenendo un archivio compresso di tipo ''tarball'' che sembra essere il preferito da tanti.
directory. We are getting the compressed tarball archive, which happens to be a preferred distribution form for
most FOSS projects.


<pre>
<pre>
Line 42: Line 38:
</pre>
</pre>


The RPM package is configured by <code>.spec</code> files. We will create a template
L'RPM è configurato attraverso i file <code>.spec</code>. Si crea un file <code> hello.spec</code> campione nella cartella appropriata:
file <code> hello.spec</code> in the appropriate directory:


<pre>
<pre>
Line 50: Line 45:
</pre>
</pre>


Recent versions of <code>Emacs</code> and <code>vi</code> have .spec file editing modes which will also bring up a similar template upon creating a new file. So you can just use the following command for example to use the template automatically.
Recenti versioni di <code>Emacs</code> e <code>vi</code> 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.


<pre>
<pre>
Line 56: Line 51:
</pre>
</pre>


=== Inside a <code>.spec</code> file ===
=== All'interno di un file <code>.spec</code> ===


The fields in our <code>.spec</code> file need slight editing. Please follow the [[How_to_create_an_RPM_package#Spec_file_pieces_explained|Fedora rules]] for these fields. In our case, the file might start as follows:
I campi del fiel <code>.spec</code> necessitano di poche modifiche. Seguire le [https://fedoraproject.org/wiki/How_to_create_an_RPM_package/it#Panoramica_SPEC_file regole Fedora] per questi campi. In questo caso, il file potrebbe iniziare così:


<pre>
<pre>
Line 78: Line 73:
</pre>
</pre>


The <code>Version</code> should mirror upstream while <code> Release</code> numbers our work within Fedora.  
Il campo <code>Version</code> dovrebbe corrispondere a quello dell'upstream mentre quello <code>Release</code> indica numericamente il lavoro al'interno di Fedora.  


The first letter of the <code> Summary</code> should be uppercase to avoid rpmlint complaints.  
La prima lettera di <code>Summary</code> dovrebbe essere maiuscola per evitare complicanze con <code>rpmlint</code>.  


It is your responsibility to check the <code>License</code> status of the software, by inspecting the source files and/or their LICENSE files, and/or by talking to the authors.
E' responsabilità  del packager controllare lo stato della <code>License</code> (Licenza) del software, ispezionando i file sorgente e/o i loro file LICENSE, parlandone con gli autori.


The <code> Group </code> tag was historically used to classify the package in accordance to the list in <code>/usr/share/doc/rpm-<version>/GROUPS</code>. It is being phased out so you will not see it added by default. However, it doesn't hurt to add it anyway.
Il tag <code> Group </code> storicamente era usato per classificare il pacchetto secondo la lista <code>/usr/share/doc/rpm-<version>/GROUPS</code>. Gradualmente verrà escluso ma per adesso è bene mantenerlo.


The <code> %changelog</code> should document the work on preparing the RPM, especially if there are security and bug patches included on top of the base upstream source. Changelog data can be displayed by <code>rpm --changelog -q <packagename></code>, which is very useful for instance to find out if specific bug and security patches were included in the installed software, thanks to diligent Fedora packagers who include this info with the relevant [[http://cve.mitre.org/|CVE]] numbers.
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] .


The changelog entry should include the version string to avoid rpmlint complaints.  
Il changelog dovrebbe includere la versione per escludere complicanze con rpmlint.  


Multi-line sections like <code> %changelog</code> or <code> %description</code> start on a line under the directive, and end with an empty line.  
Sezioni a linea multipla come <code> %changelog</code> o <code> %description</code> iniziano nella linea inferiore e terminano con una linea vuota.  


Lines which aren't needed (e.g. <code>BuildRequires</code> and <code>Requires</code>) can be commented out with a hash ('#') for now.
Linee non necessarie (ad esempio <code>BuildRequires</code> e <code>Requires</code>) possono essere commentate con il cancelletto ('#') per adesso.


Many lines in the template don't need to be changed at all in many cases, at least for the initial attempt.
Molte linee del modello in molti casi non è necessario modificarle, almeno nel primo tentativo.


=== Building the package ===
=== Costruire il pacchetto ===


We are ready for the first  run to build source, binary and debugging packages:
Si inizia con la costruzione dei pacchetti sorgente, binario e di debugging:


<pre>
<pre>
Line 104: Line 99:
</pre>
</pre>


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 <code>%files</code> section. Do not hardcode names like <code>/usr/bin/</code>, but use macros, like <code>%{_bindir}/hello</code> instead. The manual pages should be declared in the <code>%doc</code> subsection: <code>%doc %{_mandir}/man1/hello.1.gz</code>.
Verranno elencati i file non impacchettati, cioé quelli installati nel sistema ma che non fanno parte del pacchetto. Bisogna dichiararli nella sezione <code>%files</code>. Nomi come <code>/usr/bin/</code> non devono essere trattati come hardcode, ma si usano le macro come <code>%{_bindir}/hello</code>. Le pagine del mauale vanno dichiarate nella sottosezione <code>%doc</code>: <code>%doc %{_mandir}/man1/hello.1.gz</code>.


This is an iterative process: after editing the <code>.spec</code> file, rerun <code>rpmbuild</code>.
Questo è un processo iterativo: dopo la modifica del file <code>.spec</code>, riavviare <code>rpmbuild</code>.


Since our program uses translations and internationalization, we are seeing a lot of undeclared i18 files. The [[Packaging:Guidelines#Handling_Locale_Files|recommended method]] to declare them is:
Siccome i programmi usano traduzioni ed internazionalizazioni, si vedranno molti file i18 non dichiarati. Il [[Packaging:Guidelines#Handling_Locale_Files|metodo raccomandato]] per dichiararli è:


* find the filenames in the <code>%install</code> step: <code> %find_lang %{name}</code>
* trovare i nomi dei file in <code>%install</code>: <code> %find_lang %{name}</code>
* add the required build dependencies: <code>BuildRequires: gettext</code>
* aggiungere le dipendenze richieste per la compilazione: <code>BuildRequires: gettext</code>
* use the found filenames <code>%files -f %{name}.lang</code>
* usare i nomi file trovati<code>%files -f %{name}.lang</code>


If the program uses GNU info files, you need to make sure the installation and uninstallation
Se il programma usa file info GNU, bisogna assicurarsi che l'installazione/disinstallazione del pacchetto non interferisca con altri software usando questa espressione standard:
of the package does not interfere with other software on the system, by using this boilerplate:


* delete the 'dir' file in %install:  <code>rm -f %{buildroot}/%{_infodir}/dir</code>
* cancellare il file 'dir' in %install:  <code>rm -f %{buildroot}/%{_infodir}/dir</code>
* <code>Requires(post): info</code> and <code>Requires(preun): info</code>
* <code>Requires(post): info</code> and <code>Requires(preun): info</code>
* add those steps:
* aggiungere questi passaggi:
<pre>
<pre>
%post
%post
Line 130: Line 124:
</pre>
</pre>


=== A complete <code>hello.spec</code> file ===
=== Un file <code>hello.spec</code> completo ===


Here's the initial version of <code>hello.spec</code>:
Ecco la versione originale di <code>hello.spec</code>:


<pre>
<pre>
Line 184: Line 178:
</pre>
</pre>


With this spec file, you should be able to successfully complete the build process, and create the source and binary RPM packages.  
Con esso si dovrebbe essere in grado di completare il processo di costruzione e creare i pacchetti sorgente e binario.  


Next you should check them for conformance with RPM design rules, by running <code>rpmlint</code> on the spec file and all RPMs:  
Poi si dovrebbero controllare le conformità con le regole di progettazione usando <code>rpmlint</code> sul file spec e tutti gli RPM:  


<pre>
<pre>
Line 192: Line 186:
</pre>
</pre>


If there are no warnings or errors, we've succeeded. Otherwise, append the error messages to the <code>rpmlint -i</code>  command to see a more verbose description of the <code>rpmlint</code> diagnostics.
Se non ci sono errori o avvisi, è andato tutto bene. In caso contrario, usare il comando <code>rpmlint -i</code>  o <code>rpmlint -I error_code</code> per avere una descrizione approfondita.


=== The <code>mock</code> builds ===
=== Le compilazioni con <code>mock</code> ===


To check that the package build will succeed in the Fedora restricted build environment, check it with 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.


<pre>
<pre>
$ mock -r fedora-15-i386 --rebuild ../SRPMS/hello-2.7-1.fc15.src.rpm
$ mock --verbose ../SRPMS/hello-2.7-1.fc19.src.rpm
</pre>
</pre>


== References ==
== Riferimenti ==


* https://fedoraproject.org/wiki/How_to_create_an_RPM_package
* [[How_to_create_an_RPM_package/it]]
* https://fedoraproject.org/wiki/Building_RPM_packages_%2820090405%29
* [[Building RPM packages (20090405)]]
* https://fedoraproject.org/wiki/Using_Mock_to_test_package_builds
* [[Using Mock to test package builds]]
* https://fedoraproject.org/wiki/Using_the_Koji_build_system
* [[Using the Koji build system]]


== History ==
== Storia ==


Przemek Klosowski wrote this tutorial when he worked through [[Building_RPM_packages_%2820090405%29|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 [http://www.absolutepanic.org/blog/2009/07/building-a-gnu-hello-world-rpm 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 [[Yum|other sources]].
Przemek Klosowski scrisse questo tutorial quando fa lavorato con [[Building_RPM_packages_%2820090405%29|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 [http://www.absolutepanic.org/blog/2009/07/building-a-gnu-hello-world-rpm sito web di Christian Lyder Jacobsen]. Informazioni più approfondite sull'utilizzo e la creazione di pacchetti RPM sono disponibili da [[Yum|altre fonti]].


[[Category:Package Maintainers]][[Category:How to]][[Category:Da revisionare]][[Category:Italiano]]
[[Category:Package Maintainers]][[Category:How to]][[Category:Da revisionare]][[Category:Italiano]]

Latest revision as of 15:52, 27 January 2016

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

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.

Retrieved from "https://fedoraproject.org/w/index.php?title=How_to_create_a_GNU_Hello_RPM_package/it&oldid=433143"