m (internal link cleaning) |
|||
(107 intermediate revisions by 4 users not shown) | |||
Line 1: | Line 1: | ||
{{autolang | {{autolang}} | ||
{{admon/warning|Questa pagina è parzialmente conforme a quella in lingua inglese; verrà aggiornata al completamento delle correzioni sull'originale.}} | |||
== Introduzione == | |||
Questa pagina | Questa pagina descrive in dettaglio i meccanismi di base su come creare un pacchetto RPM ed in particolare come creare uno SPEC file. A differenza di altre guide su RPM, questa pagina spiega le specifiche per Fedora legate alle linee guida ufficiali. Da quando è mantenuta su Fedora wiki, è probabile che sia più aggornata rispetto ad altre guide. Nonostante tutto, non tutto l'intero documento è applicabile anche ad altre distro basate su RPM. Se "si vogliono stringere i tempi" leggere [[How to create a GNU Hello RPM package]]. | ||
'''Attualmente la Documentazione Fedora ha rilasciato una bozza di guida per i packager: [http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/Packagers_Guide Packagers Guide]''' | |||
Da notare che questa pagina ''NON'' mostra le '''linee guida''' ufficiali sulla creazione dei pacchetti per Fedora; a questo proposito, il [[Packaging:Committee| Packaging Committee]] gestisce le regole e le linee guida stesse per il packaging in Fedora. Quelle più importanti: | |||
Se si prevede di creare un pacchetto RPM per il repository di Fedora, | * [[Packaging:Guidelines| Packaging Guidelines]] | ||
* [[Packaging:LicensingGuidelines |Licensing Guidelines]] | |||
* [[Packaging:NamingGuidelines| Package Naming Guidelines]] | |||
* [[Packaging:DistTag| Dist Tag Guidelines]] | |||
* [[Packaging:ReviewGuidelines| Package Review Guidelines]] | |||
* [[Packaging:ScriptletSnippets| Recipes for RPM post scripts]] | |||
'''[[Packaging:Guidelines|Packaging Guidelines]] e [[Packaging:NamingGuidelines|Package Naming Guidelines]] sono le principali. Detto ciò, questa pagina dovrebbe essere compatibile con loro. | |||
Se si prevede di creare un pacchetto RPM per il repository di Fedora, seguire la procedura [[Join the package collection maintainers|Come diventare manutentori dei pacchetti Fedora Collection]]. | |||
== Impostazione sistema | == Impostazione del sistema == | ||
Prima di creare pacchetti RPM in Fedora, bisogna installare alcuni strumenti di sviluppo e settare l'account (o gli account) che si userà. Come root (non digitare il '#' !) | Prima di creare pacchetti RPM in Fedora, bisogna installare alcuni strumenti di sviluppo e settare l'account (o gli account) che si userà. Come root (non digitare il '#' !) | ||
# | # dnf install @development-tools | ||
# | # dnf install fedora-packager | ||
# dnf install rpmdevtools | |||
E' possibile creare un "utente dedicato" appositamente per costruire pacchetti rpm. In questo modo, se qualcosa dovesse andare male, il programma o il processo di costruzione non cancellerà dati personali | E' possibile creare un "utente dedicato" appositamente per costruire pacchetti rpm. In questo modo, se qualcosa dovesse andare male, il programma o il processo di costruzione non cancellerà dati personali e non invierà file o chiavi private al mondo esterno. | ||
{{admon/caution| | {{admon/caution|Non si dovrebbe MAI creare un pacchetto usando l'utente <code>root</code>. 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 un nuovo utente chiamato semplicemente "makerpm", aggiungerlo al gruppo 'mock', impostarne la password eseguendo: | |||
# /usr/sbin/useradd makerpm | # /usr/sbin/useradd makerpm | ||
# usermod -a -G mock makerpm | |||
# passwd makerpm | |||
Poi loggarsi come utente speciale (makerpm). | Poi loggarsi come utente speciale (makerpm). | ||
Line 31: | Line 50: | ||
$ rpmdev-setuptree | $ rpmdev-setuptree | ||
Il programma "rpm-setuptree" creerà una cartella ~/rpmbuild. All'interno di "rpmbuild" ci sono una serie di sottocartelle (come SPECS e BUILD) che si useranno per creare i propri pacchetti.< | Il programma "rpm-setuptree" creerà una cartella ~/rpmbuild. All'interno di "rpmbuild" ci sono una serie di sottocartelle (come SPECS e BUILD) che si useranno per creare i propri pacchetti. Sarà inoltre creato il file <code>~/.rpmmacros</code>, usato per impostare opzioni aggiuntive. | ||
[[Packaging:Guidelines#Timestamps|Le linee guida per il packaging raccomandano l'uso di comandi che preservano il timestamps dei file]]; è possibile farlo automaticamente usando wget o curl per procurarsi i file sorgente. | [[Packaging:Guidelines#Timestamps|Le linee guida per il packaging raccomandano l'uso di comandi che preservano il timestamps dei file]]; è possibile farlo automaticamente usando wget o curl per procurarsi i file sorgente. | ||
Se si usa wget assicurarsi | Se si usa wget assicurarsi di aggiungere il comando "<code>timestamping = on</code>" al file <code>~/.wgetrc</code>. allo stesso modo se si usa curl, nel file <code>~/.curlrc</code> dev'essere presente il testo <code>"-R"</code>. | ||
Una volta fatto questi passaggi per la creazione dell'account, normalmente non sarà necessario rifarli ancora. | Una volta fatto questi passaggi per la creazione dell'account, normalmente non sarà necessario rifarli ancora. | ||
== | == Le basi della creazione di pacchetti RPM == | ||
Per creare un pacchetto RPM, è necessario creare un file di testo ".spec" che fornisce informazioni sul software che viene pacchettizzato. | |||
Quindi si esegue il comando "rpmbuild" sul file spec, che completa una serie di passi per produrre il pacchetto. | |||
Normalmente si opera collocando il sorgente originale (incontaminato), ad esempio un file tar.gz degli sviluppatori originali, in "~ /rpmbuild/SOURCES". Si consiglia di inserire il file .spec in "~/rpmbuild/SPECS" chiamandolo "''NAME''.spec" , dove ''NAME'' è il nome base del pacchetto. Per creare tutti i pacchetti (sia binari che pacchetti sorgenti), si deve passare alla directory "~/rpmbuild/SPECS" ed eseguire: | |||
rpmbuild -ba ''NAME''.spec | $ rpmbuild -ba ''NAME''.spec | ||
Quando viene richiamato in questo modo rpmbuild legge il file .spec e tenta di passare attraverso le seguenti fasi in questo ordine (i nomi che iniziano con <code>%</code> sono macro predefinite come descritto di seguito): | |||
{| | |||
! | Alcune directory hanno determinati funzioni per <code>rpmbuild</code> che possono essere sostituiti nel file <code>.spec</code> in base alle macro predefinite (iniziano per <code>%</code>): | ||
Come si può vedere, alcune directory hanno scopi particolari per <code>rpmbuild</code>. Queste sono: | |||
{|border="1" cellspacing="0" | |||
! Nome della Macro !! Nome !! Predefinito !! Funzione | |||
|- | |- | ||
|% | |<code>%_specdir</code>||Specification directory||<code>~/rpmbuild/SPECS</code>||File SPEC degli RPM (.spec) | ||
|- | |- | ||
|% | |<code>%_sourcedir</code>||Source directory||<code>~/rpmbuild/SOURCES</code>||Pacchetto dei sorgenti incontaminati (es: tarballs) e patch | ||
|- | |- | ||
|% | |<code>%_builddir</code>||Build directory||<code>~/rpmbuild/BUILD</code>||I file sorgente vengono spacchettati e compilati nella sua subdirectory. | ||
|- | |- | ||
|% | |<code>%_buildrootdir</code>||Build root directory||<code>~/rpmbuild/BUILDROOT</code>||I file vengono installati qui durante la fase <code>%install</code>. | ||
|- | |- | ||
| | |<code>%_rpmdir</code>||Binary RPM directory||<code>~/rpmbuild/RPMS</code>||Binari RPM sono creati e immagazzinati qui sotto. | ||
|- | |- | ||
| | |<code>%_srcrpmdir</code>||Source RPM directory||<code>~/rpmbuild/SRPMS</code>||Gli RPM sorgente sono creati e immagazzinati qui sotto. | ||
|} | |} | ||
< | Per creare i pacchetti binario e sorgente, dalla directory <code>~/rpmbuild/SPECS</code> avviare: | ||
$ rpmbuild -ba ''NAME''.spec | |||
Quando invocato in questo modo <code>rpmbuild</code> legge il file <code>.spec</code> e segue le seguenti fasi di lavoro: | |||
{|border="1" cellspacing="0" | |||
{| | ! Nome dela Macro !! Nome !! Predefinito !! Funzione | ||
! Macro | |||
|- | |- | ||
|% | |<code>%prep</code>||<code>%_sourcedir</code>||<code>%_builddir</code>||Legge i sorgenti e le patch nella directory <code>%_sourcedir</code>. Questa fase scompatta il sorgente in una sotto-directory inferiore alla directory di build <code>%_builddir</code> (di solito ~/rpmbuild/BUILD/) e applica le patch. | ||
|- | |- | ||
|% | |<code>%prep</code>||<code>%_sourcedir</code>||<code>%_builddir</code>||Compila i file nella directory sotto quella di build <code>%_builddir</code>. Di solito si possono realizzare qui alcune variazioni di "<code>./configure && make</code>". | ||
|- | |- | ||
|% | |<code>%check</code>||<code>%_builddir</code>||<code>%_builddir</code>||Verifica che il software funziona propriamente. Fase spesso realizzata per eseguire alcune variazioni di "<code>make test</code>". Molti pacchetti non realizzano questa fase. | ||
|- | |- | ||
|% | |<code>%install</code>||<code>%_builddir</code>||<code>%_buildrootdir</code>||Questa fase legge i file nella directory sotto quella di build <code>%_builddir</code> e scrive in una directory sotto la root build directory <code>%_buildrootdir</code>. 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 "<code>make install</code>". | ||
|- | |- | ||
|%_rpmdir|| | |<code>bin</code>||<code>%_buildrootdir</code>||<code>%_rpmdir</code>||Legge la directory sotto la build root directory <code>%_buildrootdir</code> per creare un pacchetto RPM binario sotto la directory RPM <code>%_rpmdir</code>. All'interno della directory RPM vi è una directory per ogni architettura ed una denominata "<code>noarch</code>" per pacchetti che si possono applicare a molte architetture. Questi file RPM sono i pacchetti che gli utenti andranno ad installare. | ||
|- | |- | ||
|%_srcrpmdir|| | |<code>src</code>||<code>%_sourcedir</code>||<code>%_srcrpmdir</code>||Questa crea un pacchetto sorgente RPM (<code>.src.rpm</code>) all'interno della directory RPM sorgente <code>%_srcrpmdir</code>. Questi file sono necessari per una revisione e un aggiornamento del pacchetto. | ||
|} | |} | ||
<!-- Note: The words "in" and "underneath" in the table above have different meanings. Given file /a/b/c, c is "underneath" but not "in" a. --> | |||
Se una fase si interrompe prematuramente, è necessario guardare l'output per capire ''perché'' è fallita, cambiare il file <code>.spec</code> (o altri file di input) a seconda delle necessità. | |||
== Prepararsi per pacchettizzare un programma particolare == | == Prepararsi per pacchettizzare un programma in particolare == | ||
Se ci sono programmi speciali richiesti per costruire o avviare il programma da pacchettizzare, installarli | Se ci sono programmi speciali richiesti per costruire o avviare il programma da pacchettizzare, installarli | ||
e prendere nota di cosa sono (queste informazioni serviranno). | e prendere nota di cosa sono (queste informazioni serviranno). | ||
Per pacchettizzare un programma per i repository Fedora, si | Per pacchettizzare un programma per i repository Fedora, si devono pacchettizzare i sorgenti incontaminati (originali), insieme a patch e istruzioni di costruzione; ''non'' va bene cominciare con codice precompilato. | ||
patch e istruzioni di costruzione; ''non'' va bene cominciare con codice precompilato. | Salvare il file con il sorgente originale (solitamente un file <code>.tar.gz</code>) nella cartella "<code>~/rpmbuild/SOURCES</code>" (dell'utente costruttore di rpm). | ||
Salvare il file con il sorgente originale (solitamente un file .tar.gz) nella cartella "~/rpmbuild/SOURCES" (dell'utente costruttore di rpm). | |||
Leggere dal manuale le istruzioni d'installazione del programma; si deve rendere automatizzato il tutto editando uno ".spec" file, | Leggere dal manuale le istruzioni d'installazione del programma; si deve rendere automatizzato il tutto editando uno ".spec" file, | ||
quindi capire cosa si deve fare prima. | quindi capire cosa si deve fare prima. | ||
Probabilmente è meglio fare una prova di compilazione attraverso la procedura di costruzione/installazione senza usare l'RPM per prima | Probabilmente è meglio fare una prova di compilazione attraverso la procedura di costruzione/installazione senza usare l'RPM per prima (è consigliato specialmente se non si ha dimistichezza con gli rpm). | ||
(è consigliato specialmente se non si ha dimistichezza con gli rpm). | |||
Con qualche eccezione, tutti i programmi binari e le librerie incluse nei pacchetti Fedora devono essere costruiti dal codice sorgente contenuto nei pacchetti sorgente. | Con qualche eccezione, tutti i programmi binari e le librerie incluse nei pacchetti Fedora devono essere costruiti dal codice sorgente contenuto nei pacchetti sorgente. | ||
Line 106: | Line 132: | ||
=== Licenza === | === Licenza === | ||
Usare solo software che può essere pacchettizzato legalmente. | |||
Leggere [[Packaging:Guidelines#Legal]], [[Licensing:Main]] and [[Packaging:LicensingGuidelines]]. | |||
In generale, serve ai soli pacchetti software rilasciati come open source software (OSS) con una licenza approvata (così come le GNU GPL, GNU LGPL, BSD-new, MIT/X o Apache 2.0). | In generale, serve ai soli pacchetti software rilasciati come open source software (OSS) con una licenza approvata (così come le GNU GPL, GNU LGPL, BSD-new, MIT/X o Apache 2.0). | ||
Assicurarsi che il software sia realmente licenziato in questo modo (ad esempio controlli casuali del codice sorgente degli header, README file e così via). | Assicurarsi che il software sia realmente licenziato in questo modo (ad esempio controlli casuali del codice sorgente degli header, README file e così via). | ||
Line 121: | Line 146: | ||
Inoltre controllare la [[PackageMaintainers/InProgressReviewRequests | In Progress Review Requests]] (per pacchetti in fase di revisione) | Inoltre controllare la [[PackageMaintainers/InProgressReviewRequests | In Progress Review Requests]] (per pacchetti in fase di revisione) | ||
e la lista [[PackageMaintainers/RetiredPackages | Retired Packages]]. | e la lista [[PackageMaintainers/RetiredPackages | Retired Packages]]. | ||
E' possibile usare | E' possibile usare | ||
http://pkgs.fedoraproject.org/ | [http://pkgs.fedoraproject.org/cgit Fedora Packages Git Repositories] | ||
per vedere direttamente gli .spec file (e patch) di qualsiasi pacchetto esistente in Fedora. | per vedere direttamente gli .spec file (e patch) di qualsiasi pacchetto esistente in Fedora. | ||
E' possibile scaricare gli RPM sorgenti usando | E' possibile scaricare gli RPM sorgenti usando il DNF download Plugin:<br> | ||
$ dnf download --source sourcepackage-name | |||
$ | |||
In alternativa, un rpm sorgente può essere recuperato manualmente visitando la pagina web [http://mirrors.fedoraproject.org/publiclist Fedora mirror] http o ftp, | In alternativa, un rpm sorgente può essere recuperato manualmente visitando la pagina web [http://mirrors.fedoraproject.org/publiclist Fedora mirror] http o ftp, | ||
selezionando releases/ | selezionando la cartella <code>releases/{{FedoraVersion}}/Everything/source/SRPMS</code>. | ||
(rimpiazzare | (rimpiazzare "<code>{{FedoraVersion}}</code>" con la versione di Fedora desiderata), | ||
e scaricare l'rpm sorgente voluto (il nome termina con .src.rpm). | e scaricare l'rpm sorgente voluto (il nome termina con .src.rpm). | ||
Ottenuto l'rpm sorgente, | Ottenuto l'rpm sorgente, installarlo in <code>~/rpmbuild</code>: | ||
$ rpm -ivh sourcepackage-name*.src.rpm | $ rpm -ivh sourcepackage-name*.src.rpm | ||
E' possibile inoltre depacchettizzare il .src.rpm in una directory con rpm2cpio: | E' possibile inoltre depacchettizzare il .src.rpm in una directory con <code>rpm2cpio</code>: | ||
$ mkdir PROGRAMNAME_src_rpm | $ mkdir PROGRAMNAME_src_rpm | ||
$ cd PROGRAMNAME_src_rpm | $ cd PROGRAMNAME_src_rpm | ||
Line 147: | Line 166: | ||
''Qualche volta'' è più facile iniziare con un pacchetto esistente, per poi ripulirlo per Fedora; | ''Qualche volta'' è più facile iniziare con un pacchetto esistente, per poi ripulirlo per Fedora; | ||
[http://rpmfind.net/ RPM Find] | [http://rpmfind.net/ RPM Find] e [http://pkgs.org PKGS.org] potrebbero aiutare a trovare RPM per sistemi non-Fedora | ||
(si possono installare rpm sorgenti di altri sistemi come in Fedora). | (si possono installare rpm sorgenti di altri sistemi come in Fedora). | ||
In caso, si potrebbe vedere per pacchetti sorgente (non pacchetti .deb binari) per [http://packages.ubuntu.com/ Ubuntu] | In caso, si potrebbe vedere per pacchetti sorgente (non pacchetti <code>.deb</code> binari) per [http://packages.ubuntu.com/ Ubuntu] | ||
o [http://www.debian.org/distrib/packages Debian] (pacchetti sorgente sono degli standard tarball con una | o [http://www.debian.org/distrib/packages Debian] (pacchetti sorgente sono degli standard tarball con una | ||
sottocartella ''debian/'', possibilmente associata con delle patch). | sottocartella ''<code>debian/</code>'', possibilmente associata con delle patch). | ||
Se [http://www.freebsd.org/ports/installing.html FreeBSD ports collection] dovesse averlo, | Se [http://www.freebsd.org/ports/installing.html FreeBSD ports collection] dovesse averlo, | ||
si potrebbe [ftp://ftp.freebsd.org/pub/FreeBSD/ports/ports/ports.tar.gz scaricare il FreeBSD ports tarball] | si potrebbe [ftp://ftp.freebsd.org/pub/FreeBSD/ports/ports/ports.tar.gz scaricare il FreeBSD ports tarball] | ||
Line 158: | Line 177: | ||
Differenti distribuzioni hanno differenti regole e quello che fanno potrebbe essere inappropriato per Fedora. | Differenti distribuzioni hanno differenti regole e quello che fanno potrebbe essere inappropriato per Fedora. | ||
== | == Creare un file spec == | ||
E' necessario creare ora il file ".spec" nella directory "<code>~/rpmbuild/SPECS</code>". | |||
E' consigliato dare al file il nome del programma (es: "<code>program.spec</code>"). Usare il nome dell'archivio oppure il nome sostenuto dall'autore del programma dove possibile, ma assicurarsi di rispettare le | |||
[[Packaging/NamingGuidelines| | [[Packaging/NamingGuidelines| Linee guida per il Naming dei pacchetti]]. | ||
=== | === Modelli ed esempi di SPEC === | ||
==== Modelli ==== | |||
Quando si crea uno .spec file per la prima volta, è possibile usare editor come ''vim'' o ''emacs'' che creeranno automaticamente uno .spec iniziale: | |||
$ cd ~/rpmbuild/SPECS | $ cd ~/rpmbuild/SPECS | ||
$ vi program.spec | $ vi program.spec | ||
Di seguito un esempio di questo template ('''Nota:''' il modello fornito sotto non necessariamente è conforme con le linee guida del Fedora Packaging): | |||
Name: | Name: | ||
Version: | Version: | ||
Line 180: | Line 199: | ||
URL: | URL: | ||
Source0: | Source0: | ||
BuildRequires: | BuildRequires: | ||
Line 188: | Line 206: | ||
%prep | %prep | ||
% | %autosetup | ||
%build | %build | ||
Line 195: | Line 213: | ||
%install | %install | ||
%make_install | |||
%files | %files | ||
%doc | %doc | ||
%license | |||
%changelog | %changelog | ||
E' possibile usare <code>$RPM_BUILD_ROOT</code> al posto di <code>%{buildroot}</code>; basta che siano coerenti. | |||
E' possibile usare il comando <code>rpmdev-newspec</code> per creare un file di .spec . <code>rpmdev-newspec NOME-DEL-NUOVO-PACCHETTO</code> crea un file spec iniziale per un nuovo pacchetto, su misura per vari tipi di pacchetti. Il programma individuerà il tipo di modello da usare dal nome del pacchetto, oppure specificare un particolare tipo di modello. Controllare <code>/etc/rpmdevtools/spectemplate-*.spec</code> per consultare i modelli disponibili e <code>rpmdev-newspec --help</code> per maggiori informazioni. Per esempio, per creare un nuovo file di spec per un modulo python: | |||
cd ~/rpmbuild/SPECS | cd ~/rpmbuild/SPECS | ||
Line 216: | Line 230: | ||
vi python-antigravity.spec | vi python-antigravity.spec | ||
=== | ==== Esempi ==== | ||
===== eject ===== | |||
L'esempio di seguito mostra uno .spec per Fedora 16 per il programma <code>eject</code>: | |||
<pre> | |||
Summary: A program that ejects removable media using software control | |||
Name: eject | |||
Version: 2.1.5 | |||
Release: 21%{?dist} | |||
License: GPLv2+ | |||
Group: System Environment/Base | |||
Source: %{name}-%{version}.tar.gz | |||
Patch1: eject-2.1.1-verbose.patch | |||
Patch2: eject-timeout.patch | |||
Patch3: eject-2.1.5-opendevice.patch | |||
Patch4: eject-2.1.5-spaces.patch | |||
Patch5: eject-2.1.5-lock.patch | |||
Patch6: eject-2.1.5-umount.patch | |||
URL: http://www.pobox.com/~tranter | |||
ExcludeArch: s390 s390x | |||
BuildRequires: gettext | |||
BuildRequires: libtool | |||
%description | |||
The eject program allows the user to eject removable media (typically | |||
CD-ROMs, floppy disks or Iomega Jaz or Zip disks) using software | |||
control. Eject can also control some multi-disk CD changers and even | |||
some devices' auto-eject features. | |||
Install eject if you'd like to eject removable media using software | |||
control. | |||
%prep | |||
%autosetup -n %{name} | |||
%build | |||
%configure | |||
make %{?_smp_mflags} | |||
%install | |||
%make_install | |||
install -m 755 -d %{buildroot}/%{_sbindir} | |||
ln -s ../bin/eject %{buildroot}/%{_sbindir} | |||
%find_lang %{name} | |||
%files -f %{name}.lang | |||
%doc README TODO ChangeLog | |||
%license COPYING | |||
%{_bindir}/* | |||
%{_sbindir}/* | |||
%{_mandir}/man1/* | |||
%changelog | |||
* Tue Feb 08 2011 Fedora Release Engineering <rel-eng@lists.fedoraproject.org> - 2.1.5-21 | |||
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild | |||
* Fri Jul 02 2010 Kamil Dudka <kdudka@redhat.com> 2.1.5-20 | |||
- handle multi-partition devices with spaces in mount points properly (#608502) | |||
</pre> | |||
{{Anchor|Spec_file_pieces_explained}} | |||
== Panoramica del file SPEC == | |||
Altre utili guide: | |||
* La [http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch-creating-rpms.html Guida RPM] descrive nei dettagli come riempire uno spec file. | |||
* La serie IBM "Packaging software with RPM" [http://www.ibm.com/developerworks/library/l-rpm1/ Parte 1], [http://www.ibm.com/developerworks/library/l-rpm2/ Parte 2] e [http://www.ibm.com/developerworks/library/l-rpm3 Parte 3] è altrettanto utile. | |||
* [http://rpm.org/max-rpm-snapshot/ Maximum RPM] ha informazioni più complete ma è datata. | |||
[http://rpm.org/max-rpm-snapshot/ Maximum RPM] | |||
Seguire la linee guida [[Packaging/NamingGuidelines| Package Naming Guidelines]], [[Packaging/Guidelines| Packaging Guidelines]] e [[Packaging/ReviewGuidelines|Package review guidelines]]. | |||
[[Packaging/NamingGuidelines| Package Naming Guidelines]], | |||
[[Packaging/Guidelines| Packaging Guidelines]] | |||
[[Packaging/ReviewGuidelines|Package review guidelines]]. | |||
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 <code>%{name}</code>, <code>%{version}</code> and <code>%{release}</code> possono essere usate come riferimanto a Nome, Versione e Release rispettivamente. Quando si cambia un tag, la macro automaticamente aggiorna al nuovo valore. | |||
* Name: | * '''Name''': Il nome del pacchetto, che dovrebbe coincidere con quello dello SPEC file. Deve seguire le [[Packaging/NamingGuidelines|Linee Guida]] e generalmente usa caratteri minuscoli. | ||
* Version: | * '''Version''': Il numero di versione dall'upstream. Vedere la [[Packaging/NamingGuidelines#Version_Tag|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 <code>yy.mm[dd]</code> (ad esempio <code>2008-05-01</code> diventa <code>8.05</code>). | ||
* Release: | * '''Release''': Il valore iniziale dovrebbe essere <code>1%{?dist}</code>. 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 <code>1</code>. Controllare la [[Packaging/NamingGuidelines#Release_Tag|sezione Release]] delle linee guida. L'opzionale [[Packaging/DistTag|Dist tag]] potrebbe essere utile. | ||
* Summary: | * '''Summary''': Un breve sommario one-line del pacchetto. Usare l'inglese americano. '''NON finisce con una sola frase'''. | ||
* Group: | * '''Group''': Necessita di un gruppo preesistente, come "Applications/Engineering"; avviare "<code>less /usr/share/doc/rpm/GROUPS</code>" per conoscere la lista completa. Usare il gruppo "Documentation" per qualsiasi sotto pacchetto (ad esempio <code>kernel-doc</code>) contenente documentazione. '''''Nota: Questo tag è disapprovato a partire da Fedora 17. Vedere [[http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/Packagers_Guide/chap-Packagers_Guide-Spec_File_Reference-Preamble.html| Introduzione di riferimento Spec File]] ''''' | ||
* License: | * '''License''': La licenza che deve essere open source. ''Non'' usare vecchi tag Copyright. Usare abbreviazioni standard ("<code>GPLv2+</code>") e specifiche (usare "<code>GPLv2+</code>" per la GPL versione 2 o successive invece del solo "<code>GPL</code>" oppure "<code>GPLv2</code>"). Vedere [[Licensing]] e le [[Packaging/LicensingGuidelines|Licensing Guidelines]]. E' possibile listare più licenze combinandole con "<code>and</code>" e "<code>or</code>" (ad esempio "<code>GPLv2 and BSD</code>"). | ||
* URL: | * '''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: | * '''Source0''': L'intero URL all'archivio compresso contenente il codice sorgente originale, come rilasciato dall'upstream. "<code>Source</code>" è sinonimo di "<code>Source0</code>". Se si fornisce l'URL completo (come dovrebbe essere), il suo nome verrà utilizzato nella cartella <code>SOURCES</code>. Se possibile, incorporare <code>%{name}</code> e <code>%{version}</code>, così che le modifiche possano andare al posto giusto. [[Packaging:Guidelines#Timestamps|Preservare il timestamps]] quando si scaricano i file sorgente. Se esistono più sorgenti, nominarli <code>Source1</code>, <code>Source2</code> 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 [[Packaging/SourceURL|Source URL]] per maggiori informazioni su casi speciali (ad esempio sulla revisione). | ||
* Patch0: | * '''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 <code>~/rpmbuild/SOURCES</code>. Le Patch dovrebbero fare una modifica alla volta, quindi è possibile avere più file .patch . | ||
* BuildArch: | * '''BuildArch''': Se i file da pacchettizzare sono indipendenti dall'architettura (ad esempio shell script, file data), allora aggiungere "<code>BuildArch: noarch</code>". L'architettura per gli RPM binari sarà "<code>noarch</code>". | ||
* BuildRoot: | * '''BuildRoot''': La cartella "d'installazione" durante il processo %install (dopo %build). E'aggiuntivo in Fedora mentre è necessario in EPEL5. Normalmente la root build è in "<code>%{_topdir}/BUILDROOT/</code>". | ||
* BuildRequires: | * '''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. [[HOWTOFindMissingBuildRequires#Exceptions|Alcuni pacchetti comuni possono essere omessi]], come <code>gcc</code>. E' possibile specificarle in minima parte se necessario (ad esempio "<code>ocaml >= 3.08</code>"). Se serve il file <code>/EGGS</code>, determinarne il pacchetto che lo possiede con "<code>rpm -qf /EGGS</code>". Se serve il programma <code>EGGS</code>, determinarne il pacchetto che lo possiede con "<code>rpm -qf `which EGGS`</code>". Mantenere le dipendenze ad un numero minimo (ad esempio usare <code>sed</code> invece di <code>perl</code> 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 {{package|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 <code>rpmbuild</code> recupera automaticamente le dipendenze quindi il Requires tag non è sempre utile. Tuttavia è possibile evidenziare pacchetti specifici richiesti. | ||
* %description | * '''%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 [http://docs.fedoraproject.org/drafts/rpm-guide-en/ch09s03.html Guida RPM]. | ||
* %prep | * '''%prep''': Comandi script per "preparare" il programma (ad esempio decomprimere) così che tutto sia pronto per la compilazione. Tipcamente "<code>%autosetup</code>"; una comune variante è "<code>%autosetup -n NAME</code>" se il file sorgente spacchetta in <code>NAME</code>. Vedere la sezione %prep. | ||
* %build | * '''%build''': Comandi script per "costruire" il programma (ad esempio compilare) ed ottenerlo pronto per l'installazione. Incluse le istruzion su come farlo. Vedere la sezione %build. | ||
* %check | * '''%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 "<code>make test</code>" oppure "<code>make check</code>". E' separato da %build così da poter essere saltato a discrezione dell'utente. | ||
* %install | * '''%install''': Comandi script per "installare" il programma. I comandi dovrebbero copiare file dalla cartella <code>BUILD</code> <code>%{_builddir}</code> nella buildroot <code>%{buildroot}</code>. Vedere la sezione %install. | ||
* %clean | * '''%clean''': Istruzioni su come ripulire la build root. Notare che questa sezione è ridondante in Fedora mentre è necessaria per EPEL. Tipicamente contiene solo: | ||
rm -rf %{buildroot} | rm -rf %{buildroot} # ridondante eccetto per RHEL 5 | ||
* %files | * '''%files''': Lista di file che saranno installati. Vedere la sezione %files. | ||
* %changelog | * '''%changelog''': Modifiche nel pacchetto. Usare l'esempio sopra. '''NON inserire il changelog storico del software. Questo riguarda solo quello dell'RPM stesso.''' | ||
* ExcludeArch: | * '''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 [[How_to_create_an_RPM_package#Subpackages|subpackage]]) da un singolo SPEC file, come <code>name-libs</code> e <code>name-devel</code>. | |||
{{admon/caution|'''NON''' usare questi tag: | |||
* Packager | |||
* Vendor | |||
* Copyright}} | |||
'''Non''' creare un pacchetto "ricollocabile"; non valgono in Fedora e sono complicati. | |||
== Approfondimento sezioni SPEC file == | |||
=== Sezione %prep === | |||
La sezione "%prep" descrive come spacchettare gli archivi compressi così da poter iniziare la compilazione. | |||
Di solito include i comandi "%autosetup"; in alternativa di usano i comandi "%setup" e/o "%patch" con riferimenti alle linee Source0:, Source1:, etc. | |||
Vedere la [http://rpm.org/max-rpm-snapshot/s1-rpm-inside-macros.html sezione su %setup e %patch in Maximum RPM] per maggiori dettagli. | |||
Le macro %{patches} e %{sources} sono disponibili da RPM 4.4.2; se si usa una lunga lista di patch o sorgenti ed %autosetup non è vi è utile, è possibile fare qualcosa del genere: | |||
for p in %{patches}; do | for p in %{patches}; do | ||
... | |||
done | done | ||
==== %prep | Tuttavia tener presente che usandole si otterranno .spec file incompatibli con RPM usati in RHEL ed altre distro basate su RPM. | ||
==== Sezione %prep: comando %autosetup ==== | |||
Il comando "<code>%autosetup</code>" spacchetta i sorgente. | |||
* '''<code>-n</code> ''name''''' : Se il tarball Source decomprime in una directory non nominata come l'RPM, questa opzione può essere usata per specificare il corretto nome. Per esempio, se il file .tar decomprime nella cartella FOO, allora usare "<code>%autosetup -n FOO</code>". | |||
* '''<code>-c</code> ''name''''' : Se il tarball Source in più cartelle invece di una singola, l'opzione può essere usata per crearne una chiamata ''name''. | |||
Se si usa il comando "<code>%setup</code>" invece, allora l'opzione ''<code>-q</code>'' è comunemente usata per sopprimere gli output non necessari. | |||
Ci sono [http://rpm.org/max-rpm-snapshot/s1-rpm-inside-macros.html più opzioni %setup], utili principalmente se si stanno creando sottopacchetti. | |||
[http://rpm.org/max-rpm-snapshot/s1-rpm-inside-macros.html | Quelle principali sono: | ||
{| | {| | ||
|- | |- | ||
| -a number || | | <code>-a number</code> || Decomprime il Source dato dal numero indicato dopo aver cambiato cartella (ad esempio "<code>–a 0</code>" per Source0). | ||
|- | |- | ||
| -b number || | | <code>-b number</code> || Decomprime il Source dato dal numero indicato prima aver cambiato cartella (ad esempio "<code>–a 0</code>" per Source0). | ||
|- | |- | ||
| -D || | | <code>-D</code> || Non cancella la cartella dopo la decompressione. | ||
|- | |- | ||
| -T || | | <code>-T</code> || Disabilita la decompressione automatica dell'archivio. | ||
|} | |} | ||
==== %prep | ==== Sezione %prep: comando %patch ==== | ||
Se è stato usato il comando "<code>%autosetup</code>", le nozioni sotto indicate non servono. | |||
Se si hanno necessità più complesse o di compatibilità con EPEL, allora possono servire. | |||
Il comando "<code>%patch0</code>" applica Patch0 (e %patch1 applica Patch1 etc.). Le patch sono normali metodi di modifica necessari per "aggiustare" il codice sorgente. Si applica la solita opzione "<code>-pNUMBER</code>" che passa l'argomento al programma <code>patch</code>. | |||
Patch | I file Patch sono nominati spesso come "<code>telnet-0.17-env.patch</code>", nel formato <code>%{name} - %{version} - REASON.patch</code>" (a volte la versione è omessa). I file Patch sono il risultato di "<code>diff -u</code>"; se si fa dalla subdirectory di <code>~/rpmbuild/BUILD</code> allora non è necessario specificare un livello <code>-p</code>. | ||
Questa è la tipica procedura per creare una patch da un singolo file: | |||
cp | cp foo/bar foo/bar.orig | ||
vim | vim foo/bar | ||
diff -u | diff -u foo/bar.orig foo/bar > ~/rpmbuild/SOURCES/PKGNAME.REASON.patch | ||
Se si editano molti file, un metodo facile è la copia dell'intera subdirectory sotto <code>BUILD</code> per poi avviare il <code>diff</code>. Dopo aver cambiato cartella a "<code>~rpmbuild/BUILD/NAME</code>", allora: | |||
cp -pr ./ ../PACKAGENAME.orig/ | cp -pr ./ ../PACKAGENAME.orig/ | ||
... | ... modifiche ... | ||
diff -u ../PACKAGENAME.orig . > ~/rpmbuild/SOURCES/''NAME''.''REASON''.patch | diff -u ../PACKAGENAME.orig . > ~/rpmbuild/SOURCES/''NAME''.''REASON''.patch | ||
Se si modificano più file in una sola patch, è possibile anche copiare quelli originali usando alcune desinenze come "<code>.orig</code>" prima di modificarle. Per poi usare "<code>gendiff</code>" (nel pacchetto <code>rpm-build</code>) per creare una patch con le modifiche. | |||
Assicurarsi che le patch corrispondano correttamente al contesto. Il valore predefinito "fuzz" è "<code>0</code>". Ci si può lavorare aggiungendo "<code>%global _default_patch_fuzz 2</code>" per ripristinare il valore trovato nelle vecchie versioni dell'RPM in Fedora, ma generalmente è raccomandato evitarlo. | |||
Come spiegato in [[Packaging/PatchUpstreamStatus]], tutte le patch dovrebbero avere un commento nello .spec file sul loro stato nell'upstream, includendo il bug, la data e la mail. Se è unico si dovrebbe menzionarne il motivo. Il Fedora Project non vuole allontanarsi dagli sviluppi dell'upstream; vedere [[PackageMaintainers/WhyUpstream]]. | |||
==== %prep | ==== Sezione %prep: file non modificati ==== | ||
A volte uno o più file del Source non necessitano d'essere decompressi. Si possono "prep" (prepararli) nella cartella build come (dove <code>SOURCE1</code> si riferisce al corrispondente file Source): | |||
cp -p %SOURCE1 . | |||
=== %build | === Sezione %build === | ||
La sezione "%build" è qualche volta complicata; in essa si può configurare e compilare/costruire i file che saranno installati. | |||
Molti programmi seguono la GNU <code>configure</code> (o alcune varianti). Come predefinito, installeranno in un prefix "<code>/usr/local</code>", ragionevolmente per dei file spacchettati. Tuttavia una volta impacchettati, cambia in "<code>/usr</code>". Le librerie dovrebbero essere installate o in <code>/usr/lib</code> oppure in <code>/usr/lib64</code> in base all'architettura. | |||
Dal momento che GNU <code>configure</code> è così comune, la macro "<code>%configure</code>" può essere usata per invocare automaticamente le corrette opzioni (ad esempio cambiare il prefix a <code>/usr</code>). Alcune sue varianti funzionano spesso: | |||
%configure | %configure | ||
make %{?_smp_mflags} | make %{?_smp_mflags} | ||
Per sostituire le variabili del makefile, passarle come parametro a <code>make</code>: | |||
make %{?_smp_mflags} CFLAGS="%{optflags}" BINDIR=%{_bindir} | make %{?_smp_mflags} CFLAGS="%{optflags}" BINDIR=%{_bindir} | ||
Per maggiori informazioni vedere [http://sourceware.org/autobook/ "GNU autoconf, automake, and libtool"]. | |||
Alcuni programmi usano <code>cmake</code>. Vedi [[Packaging/cmake]]. | |||
=== Sezione %check === | |||
Se disponibili dei self-test, è buona idea includerli. Dovrebbero essere piazzati nella sezione %check (che segue la sezione %build) invece che all'interno della %build stessa, così da poter essere facilmente saltati se necessario. | |||
Spesso questa sezione contiene: | |||
make test | |||
A volte può essere: | |||
make check | |||
Osservare il file Makefile per sapere il modo più appropriato. | |||
=== %install | === Sezione %install === | ||
Questa sezione coinvolge degli script per "install" (installare) il programma, copiando i file rilevanti da <code>%{_builddir}</code> a <code>%{buildroot}</code> (che solitamente significa da <code>~/rpmbuild/BUILD</code> a <code>~/rpmbuild/BUILDROOT</code>) e creando e cartelle all'interno di <code>%{buildroot}</code>. | |||
Parte della terminologìa può essere fuorviante: | |||
* | * La "build directory", anche conosciuta come <code>%{_builddir}</code>, non è la stessa della "build root", conosciuta anche come <code>%{buildroot}</code>. La compilazione avviene nella prima, mentre i file da impacchettare sono copiati dalla prima alla seconda. | ||
* Durante la sezione %build, la cartella di partenza è <code>%{buildsubdir}</code>, sottocartella all'interno di <code>%{_builddir}</code>, creata precedentemente durante il %prep. Di solito è qualcosa del genere <code>~/rpmbuild/BUILD/%{name}-%{version}</code>. | |||
* | * La sezione %install '''non''' parte quando l'RPM binario è installato dall'utente finale, ma è avviata solo nella creazione del pacchetto. | ||
Alcune varianti di "<code>make install</code>": | |||
%install | %install | ||
rm -rf %{buildroot} # ridondante ad eccezione di RHEL5 | |||
%make_install | |||
Idealmente si dovrebbe usare [http://www.gnu.org/prep/standards/html_node/DESTDIR.html <code>DESTDIR=%{buildroot}</code>] se il programma lo supporta, dato che redirige i file d'installazione alla specifica cartella ed è esattamente ciò che ci si aspetta che faccia durante la sezione %install. | |||
Se il programma non supporta <code>DESTDIR</code> (e solo se), è possibile in alternativa una delle seguenti strade: | |||
* | * ''Patchare'' il makefile così che possa supportare <code>DESTDIR</code>. Creare cartelle all'interno di <code>DESTDIR</code> dove necessario e includerne la patch dall' upstream. | ||
* | * Usare la macro "<code>%makeinstall</code>". Questo metodo potrebbe funzionare, ma può portare a fallimenti. Tramite la macro si arriva a qualcosa del genere "<code>make prefix=%{buildroot}%{_prefix} bindir=%{buildroot}%{_bindir} ... install</code>", che in alcuni programmi pu non funzionare. Creare cartelle all'interno di <code>%{buildroot}</code> dove serve. | ||
* | * Considerare l'uso del pacchetto <code>auto-destdir</code>. Richiede "<code>BuildRequires: auto-destdir</code>" and di cambiare "<code>make install</code>" in "<code>make-redir DESTDIR=%{buildroot} install</code>". Funziona bene se l'installazione usa solo certi comandi comuni per installare i file, come <code>cp</code> e <code>install</code>. | ||
* | * Installare manualmente. Dovrbbe includere la creazione delle necessarie cartelle sotto <code>%{buildroot}</code> e la copia dei file da <code>%{_builddir}</code> a <code>%{buildroot}</code>. Bisogna essere cauti con gli aggiornamenti, contengono spesso nuovi filename. Un esempio di questa procedura: | ||
%install | %install | ||
rm -rf %{buildroot} | rm -rf %{buildroot} | ||
Line 470: | Line 465: | ||
cp -p mycommand %{buildroot}%{_bindir}/ | cp -p mycommand %{buildroot}%{_bindir}/ | ||
=== Sezione %files === | |||
Questa sezione dichiara i file e le cartelle proprietà del pacchetto quindi incorporati nell'RPM binario. | |||
=== %files | ==== Nozioni sulla sezione %files ==== | ||
Il <code>%defattr</code> imposta i permessi predefiniti del file e spesso appare all'inizio della sezione <code>%files</code>. Da notare che non è più necessario a meno che non bisogna i permessi. Il formato è: | |||
%defattr(<file permissions>, <user>, <group>, <directory permissions>) | |||
Il quarto parametro è solitamente omesso. Si usa <code>%defattr(-,root,root,-)</code>, dove "<code>-</code>" usa i permessi predefiniti. | |||
Si dovrebbero poi elencare i file e le cartelle che saranno di proprietà del pacchetto. A tal proposito usare le macro per i nomi delle cartelle, mostrate in [[Packaging:RPMMacros]] (ad esempio usare <code>%{_bindir}/mycommand</code> invece di <code>/usr/bin/mycommand</code>). Se la stringa inizia con "<code>/</code>" (o quando esteso da una macro) allora viene prelevato dalla cartella <code>%{buildroot}</code>. Oppure, si presume che il file sia nella cartella corrente (ad esempio dentro <code>%{_builddir}</code> come per i file di documentazione da includere). Se il pacchetto installa un solo file <code>/usr/sbin/mycommand</code>, la sezione <code>%files</code> può semplicemente essere: | |||
%files | %files | ||
%{_sbindir}/mycommand | %{_sbindir}/mycommand | ||
Per ottenere un rpm meno soggetto ai cambiamenti dell'upstream, dichiarare tutti i file all'interno di una cartella di proprietà del pacchetto con la stringa: | |||
%{_bindir}/* | %{_bindir}/* | ||
Per includere una singola cartella: | |||
%{_datadir}/%{name}/ | %{_datadir}/%{name}/ | ||
Notare che <code>%{_bindir}/*</code> non dice che il pacchetto in oggetto sia proprietario della cartella <code>/usr/bin</code>, ma solo dei file contenuti all'interno. Se si elenca una cartella, allora si richiede la proprietà di quella cartella e dei file e sottocartelle contenute. Quindi '''non''' si elenca <code>%{_bindir}</code> assicurardosi anche delle cartelle condivise con altri rpm. | |||
Si verificheranno errori se: | |||
* una stringa non incontra alcun file o cartella | |||
* file o cartelle sono elencate più volte | |||
* file o cartelle in <code>%{buildroot}</code> non listate | |||
E' inoltre possibile escludere file usando <code>%exclude</code>. Può aiutare per includere quasi tutti i file da differenti stringhe ma fallirà se non incontra nulla. | |||
==== %files | ==== %files prefix ==== | ||
Potrebbe essere necessario aggiungere uno o più prefissi alle linee della sezione <code>%files</code>; separate da uno spazio. Vedi [http://www.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html Max RPM section on %files directives]. | |||
Solitamente "<code>%doc</code>" è usato per elencare file di documentazione dentro <code>%{_builddir}</code> che non sono stati copiati in <code>%{buildroot}</code>. I file <code>README</code> e <code>INSTALL</code> sono di solito inclusi. Saranno piazzati nella cartella <code>/usr/share/doc</code>, la cui proprietà non ha bisogna d'essere dichiarata. | |||
'''Nota:''' Se si specifica una voce <code>%doc</code>, rpmbuild < 4.9.1 rimuove la cartella doc, nella quale piazza i file prima di installarli. Ciò significa che i file già all'interno, ad esempio installati nella sezione <code>%install</code>, sono rimossi e non finiranno nel pacchetto. Se si vuole installare alcuni file in nella sezione <code>%install</code>, farlo in una cartella temporanea all'interno della build dir (non in build root), ad esempio <code>_docs_staging</code>, ed includerli nella sezione <code>%files</code> come <code>%doc _docs_staging/*</code>. | |||
I file di configurazione dovrebbero essere posti in <code>/etc</code> e sono normalmente specificati così (che preserva le modifiche durante gli aggiornamenti): | |||
%config(noreplace) %{_sysconfdir}/foo.conf | |||
Se l'aggiornamento usa un formato di configurazione non-retrocompatibile, specificarli così: | |||
%config %{_sysconfdir}/foo.conf | |||
"<code>%attr(mode, user, group)</code>" può essere usato per controlli più precisi sui permessi, dove "<code>-</code>" significa usare il predefinito: | |||
%attr(0644, root, root) FOO.BAR | |||
"<code>%caps(capabilities)</code>" può essere usato per dare certe [http://linux.die.net/man/7/capabilities capacità] POSIX ad un file. Ad esempio: | |||
%caps(cap_net_admin=pe) FOO.BAR | |||
Se un file è in lingua naturale, usare <code>%lang</code> per annotarlo: | |||
%lang(de) %{_datadir}/locale/de/LC_MESSAGES/tcsh* | %lang(de) %{_datadir}/locale/de/LC_MESSAGES/tcsh* | ||
I programmi che utilizzano file di localizzazione dovrebbero seguire i [[Packaging:Guidelines#Handling_Locale_Files|metodi raccomandati per gestire i file i18n]]: | |||
[[Packaging:Guidelines#Handling_Locale_Files| | |||
* | * trovare i filename nel passaggio <code>%install</code>: <code> %find_lang ${name}</code> | ||
* | * aggiungere le dipendenze per la costruzione richieste: <code>BuildRequires: gettext</code> | ||
* | * usare i filename trovati: <code>%files -f ${name}.lang</code> | ||
<code>%readme</code> '''non''' è valido in Fedora. | |||
==== %files | ==== %files e Filesystem Hierarchy Standard (FHS) ==== | ||
Riferimento a [http://www.pathname.com/fhs/ Filesystem Hierarchy Standard (FHS)]. | |||
Gli eseguibili vanno in <code>/usr/bin</code>, i file di configurazione globali vanno in <code>/etc</code>, le librerie in <code>/usr/lib</code> (o <code>/usr/lib64</code>) e così via. C'é un'eccezione: eseguibili non eseguiti normalmente direttamente dall'utente o dall'amministratore dovrebbero andare nella sottocartella di <code>/usr/libexec</code>, denominata con <code>%{_libexecdir}/%{name}</code>. | |||
'''Non''' installare file in <code>/opt</code> o in <code>/usr/local</code>. | |||
Sfortunatamente molt programmi non rispettano la FHS. In particolare, librerie indipendenti dall'architettura vengono inserite in <code>/usr/lib</code> invece di <code>/usr/share</code>. Il primo è per librerie diendenti dall'architettura, mentre il secondo è per quelle indipendenti; significa che i sistemi con differenti architetture di CPU possono condividere la <code>/usr/share</code>. Ci sono molte eccezioni in Fedora (Python e Perl), ma Fedora applica queste regole più rigidamente rispetto ad alcune altre distro. <code>rpmlint</code> generalmente segnala se si mette qualcosa di diverso dai file ELF in <code>/usr/lib</code>. | |||
In | |||
==== %files | ==== Esempio di %files ==== | ||
Di seguito un esempio di sezione %files: | |||
%files | %files | ||
% | %doc README | ||
% | %license LICENSE COPYING | ||
%{_bindir}/* | %{_bindir}/* | ||
%{_sbindir}/* | %{_sbindir}/* | ||
%{_datadir}/%{name}/ | %{_datadir}/%{name}/ | ||
%config(noreplace) %{_sysconfdir}/*.conf | |||
==== | ==== Trovare duplicati ==== | ||
Per listare qualsiasi duplicato di un rpm: | |||
cd ~/rpmbuild/RPMS/ARCH # Substitute "ARCH" for your architecture | cd ~/rpmbuild/RPMS/ARCH # Substitute "ARCH" for your architecture | ||
rpm -qlp PACKAGE1.*.rpm | sort > ,1 | rpm -qlp PACKAGE1.*.rpm | sort > ,1 | ||
Line 561: | Line 552: | ||
comm -12 ,1 ,2 | comm -12 ,1 ,2 | ||
=== | === Scriptlet === | ||
Quando un utente installa l'rpm, si consigliano alcuni comandi da eseguire. Questo si può ottenere con gli scriptlet. Vedi [[Packaging/ScriptletSnippets]]. | |||
Gli scriptlet si eseguono: | |||
* prima ('''<code>%pre</code>''') o dopo ('''<code>%post</code>''') l'installazione di un pacchetto | |||
* prima ('''<code>%preun</code>''') o dopo ('''<code>%postun</code>''') la disinstallazione di un pacchetto | |||
* all'avvìo ('''<code>%pretrans</code>''') o alla fine ('''<code>%posttrans</code>''') di una transazione | |||
Per esempio, ogni rpm binario che immagazzina file di librerie condivise in qualsiasi percorso di dynamic linker, deve richiamare <code>ldconfig</code> in <code>%post</code> e <code>%postun</code>. Se il pacchetto ha molti sottopacchetti con librerie, ognuno di essi dovrebbe fare la stessa cosa. | |||
%post -p /sbin/ldconfig | %post -p /sbin/ldconfig | ||
%postun -p /sbin/ldconfig | %postun -p /sbin/ldconfig | ||
' | Se si esegue un solo comando, l'opzione "<code>-p</code>" avvìa il comando adiacente senza invocare la shell. Tuttavia, per diversi comandi, ometterla e aggiungere tutti i comandi shell. | ||
Se si avvìa un programma negli scriptlet, qualsiasi richiesta va specificata nella forma "<code>Requires(CONTEXT)</code>" (ad esempio <code>Requires(post)</code>). | |||
<code>%pre</code>, <code>%post</code>, <code>%preun</code> e <code>%postun</code> forniscono l'argomento <code>$1</code>, che è il numero di pacchetti di questo nome che saranno lasciati nel sistema. Non confrontare per uguaglianza con <code>2</code>, controlla invece se sono meggiori o uguali a <code>2</code>. Per <code>%pretrans</code> e <code>%posttrans</code>, <code>$1</code> è sempre <code>0</code>. | |||
Per esempio se il pacchetto installa un manuale il quale indice deve essere aggiornato con <code>install-info</code> dal pacchetto <code>info</code>, innanzitutto non è garantita la presenza del pacchetto <code>info</code> senza una sua richiesta specifica e poi non si può fallire completamente se <code>install-info</code> non funziona: | |||
Requires(post): info | Requires(post): info | ||
Requires(preun): info | Requires(preun): info | ||
Line 600: | Line 582: | ||
fi | fi | ||
Esiste un altro problema tecnico relativo all'installazione dei manuali. Il comando <code>install-info</code> aggiornerà la certella delle informazioni, quindi si dovrebbero cancellare le cartelle vuote inutilizzate da %{buildroot} durante la sezione <code>%install</code>: | |||
rm -f | rm -f %{buildroot}%{_infodir}/dir | ||
Un'altra abilità simile agli scriptlet è "trigger", avviabile quando altri pacchetti sono installati o disinstallati. Vedi [http://rpm.org/api/4.4.2.2/triggers.html RPM Triggers]. | |||
=== Macro === | |||
La macro è un testo nel formato <code>%{string}</code>. Tipiche macro: | |||
{| | {| | ||
! Macro !! | ! Macro !! Estensione tipica !! Significato | ||
|- | |- | ||
| %{_bindir} || /usr/bin || | | <code>%{_bindir}</code> || <code>/usr/bin</code> || Cartella dei binari: dove gli eseguibili vengono solitamente localizzati. | ||
|- | |- | ||
| %{_builddir} || ~/rpmbuild/BUILD || | | <code>%{_builddir}</code> || <code>~/rpmbuild/BUILD</code> || Cartella per il build: i file sono compilati all'interno della sua sottocartella. Vedere <code>%buildsubdir</code>. | ||
|- | |- | ||
| %{buildroot} || | | <code>%{buildroot}</code> || <code>~/rpmbuild/BUILDROOT</code> || Build root: dove i file vengono "installati" durante <code>%install</code>, che li copia dalla sottocartella di <code>%{_builddir}</code> a quella di <code>%{buildroot}</code>. (Storicamente, <code>%{buildroot}</code> era in "/var/tmp/".) | ||
|- | |- | ||
| %{buildsubdir} || %{_builddir}/%{name} || | | <code>%{buildsubdir}</code> || <code>%{_builddir}/%{name}</code> || Sottocartella build: interna a <code>%{_builddir}</code> dove i file sono compilati durante <code>%build</code>. E' impostata dopo <code>%autosetup</code>. | ||
|- | |- | ||
| %{_datadir} || /usr/share || | | <code>%{_datadir}</code> || <code>/usr/share</code> || Cartella condivisa. | ||
|- | |- | ||
| %{_defaultdocdir} || /usr/share/doc || | | <code>%{_defaultdocdir}</code> || <code>/usr/share/doc</code> || Cartella predefinita della documentazione. | ||
|- | |- | ||
| %{dist} || .fc''NUMBER'' || | | <code>%{dist}</code> || <code>.fc''NUMBER''</code> || Versione della distro (ad esempio "<code>.fc{{FedoraVersion}}</code>") | ||
|- | |- | ||
| %{fedora} || ''NUMBER'' || | | <code>%{fedora}</code> || <code>''NUMBER''</code> || Numero di rilascio di Fedora (e.g. "<code>{{FedoraVersion}}</code>") | ||
|- | |- | ||
| %{_includedir} || /usr/include | | <code>%{_includedir}</code> || <code>/usr/include</code> | ||
|- | |- | ||
| %{_infodir} || /usr/share/info | | <code>%{_infodir}</code> || <code>/usr/share/info</code> | ||
|- | |- | ||
| %{_initrddir} || /etc/rc.d/init.d | | <code>%{_initrddir}</code> || <code>/etc/rc.d/init.d</code> | ||
|- | |- | ||
| %{_libdir} || /usr/lib | | <code>%{_libdir}</code> || <code>/usr/lib</code> | ||
|- | |- | ||
| %{_libexecdir} || /usr/libexec | | <code>%{_libexecdir}</code> || <code>/usr/libexec</code> | ||
|- | |- | ||
| %{_localstatedir} || /var | | <code>%{_localstatedir}</code> || <code>/var</code> | ||
|- | |- | ||
| %{_mandir} || /usr/share/man | | <code>%{_mandir}</code> || <code>/usr/share/man</code> | ||
|- | |- | ||
| %{name} || || Name of package, set by Name: tag | | <code>%{name}</code> || || Name of package, set by Name: tag | ||
|- | |- | ||
| %{_sbindir} || /usr/sbin | | <code>%{_sbindir}</code> || <code>/usr/sbin</code> | ||
|- | |- | ||
| %{_sharedstatedir} || /var/lib | | <code>%{_sharedstatedir}</code> || <code>/var/lib</code> | ||
|- | |- | ||
| %{_sysconfdir} || /etc | | <code>%{_sysconfdir}</code> || <code>/etc</code> | ||
|- | |- | ||
| %{version} || || | | <code>%{version}</code> || || Versione del pacchetto, impostata tramite il tag Version: | ||
|} | |} | ||
Se ne può sapere di più sulle macro guardando in <code>/etc/rpm/*</code> e <code>/usr/lib/rpm</code>, specialmente <code>/usr/lib/rpm/macros</code>. Inoltre usare <code>rpm --showrc</code> per saperne i valori che RPM userà per le macro (alterate da <code>rpmrc</code> 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 | |||
%global | |||
Usare l'opzione "<code>-E</code>"di <code>rpmbuild</code> per trovare il valore della macro nello .spec file: | |||
rpmbuild -E '%{_bindir}' myfile.spec | rpmbuild -E '%{_bindir}' myfile.spec | ||
[[Packaging/RPMMacros]] | Vedere anche [[Packaging/RPMMacros]] e [https://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch09s07.html RPM Guide capitolo 9]. | ||
[ | |||
=== | === Altri tag === | ||
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 "<code>foo</code>" che esige una particolare funzionalità "bar" da un altro programma. Se esistono parecchi pacchetti che epossono soddisfarla, è possibile specificarli con "<code>Provides: bar</code>" e il pacchetto "<code>foo</code>" può specificare "<code>Requires: bar</code>". Si potrebbero anche usare [http://dailypackage.fedorabook.com/index.php?/archives/6-Wednesday-Why-The-Alternatives-System.html metodi "alternativi"], ma evitare se più utenti hanno necessità differenti, visto che queste impostazioni sono a livello di sistema. Usare "<code>rpm -q --provides PACKAGENAME</code>" 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 paccehtto. | ||
** | * '''Conflicts''': specifica quali altri pacchetti non possono essere installati simultaneamente a quello in oggetto. Evitarlo se possibile. Vedere [[Packaging/Conflicts]]. | ||
* | * '''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 | ExcludeArch: ppc | ||
* '''ExclusiveArch''': per includere solo quella specificata. Evitarlo se non assolutamente corretto. | |||
Architetture valide sono listate in [[Architectures]]. | |||
=== | === Subpackage === | ||
In | Uno SPEC file può definire diversi binari. In altre parole, un SRPM con uno SPEC file può risultare in più RPM. Notare che c'é ancora un solo processo di creazione (%prep, %build, %install etc.). Sottopacchetti <code>name-doc</code> e <code>name-devel</code> sono comuni per la documentazionee i file di sviluppo rispettivamente. | ||
Usare la direttiva <code>%package</code> per iniziare la definizione di un sottopacchetto: | |||
%package subpackage_name | |||
%package | |||
Dopo ogni direttiva <code>%package</code>, listarne i tag. Dovrebbe almeno includere i tag Summary e Group, oltre a <code>%description subpackage_name</code> e <code>%files subpackage_name</code>: | |||
Tutto quanto non specificato dal sottopacchetto sarà ereditato dal suo genitore. | |||
Come predefinito, se il nome del pacchetto è "<code>foo</code>" e quello del sottopacchetto è "<code>bar</code>", allora i nomi risultanti saranno <code>foo-bar</code>". E' possibile evitarlo con l'opzione "<code>-n</code>" (ma servirà usarlo in tutte le altre direttive una volta qui specificato): | |||
%package -n new_subpackage_name | |||
[http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch10s04.html Leggere la sezione sui sottopacchetti della Guida RPM] per maggiori informazioni. | |||
E | |||
=== Condizionali === | |||
E' possibile inserire stati di condizione, ad esempio per verificare se si sta creando un binario per una certa architettura: | |||
%ifarch ARCHITECTURE_NAME | %ifarch ARCHITECTURE_NAME | ||
versione negata con: | |||
%ifnarch ARCHITECTURE_NAME | %ifnarch ARCHITECTURE_NAME | ||
o più condizioni generiche: | |||
%if TRUE_OR_FALSE | %if TRUE_OR_FALSE | ||
C'é una sezione opzionale "<code>%else</code>"; tutte queste vengono chiuse con "<code>%endif</code>". | |||
=== | === Linee guida specifiche === | ||
Ci sono molte linee guida specifiche che sono di aiuto (ad esempio per i linguaggi di programmazione specifici, per applicazioni, librerie e sistemi di build). Molte di loro sono elencate come parte delle [[Packaging/Guidelines#Application_Specific_Guidelines|Application Specific Guidelines of Packaging/Guidelines]]. Esempi di linee guida: | |||
[[Packaging/Guidelines#Application_Specific_Guidelines|Application Specific Guidelines of Packaging/Guidelines]]. | |||
* [[Packaging:Cmake|Cmake]] | * [[Packaging:Cmake|Cmake]] | ||
* [[Packaging:Emacs|Emacs]] | * [[Packaging:Emacs|Emacs]] | ||
Altre sono: | |||
* | * Il comando 'SEARCH' di Fedoraproject.org. | ||
* [[PackagingDrafts]] | * [[PackagingDrafts]] | ||
* | * [[SIGs|Special Interest Group (SIG)]] | ||
* [ | * [[Special:PrefixIndex/Packaging|Pagine Wiki con prefisso 'Packaging']] | ||
=== | === Suggerimenti vari === | ||
[[Packaging/FrequentlyMadeMistakes]] contiene informazioni sugli errori più comuni commessi. Ci sono anche altre raccomandazioni e trucchi controversi in [[PackageMaintainers/Packaging Tricks]]. | |||
Provare a scrivere i propri .sepc files così da funzonare quando nuove versioni dall'upstream sono pronte, senza nessuna modifica a parte il numero di versione e l'aggiornamento dei sorgenti. Per esempio, se contiene file *.txt con istruzioni d'esecuzione, invece di fare | |||
chmod a-x Filename1.txt Filename2.txt Filename3.txt | chmod a-x Filename1.txt Filename2.txt Filename3.txt | ||
considerare comandi come il seguente: | |||
chmod a-x *.txt | chmod a-x *.txt | ||
Se si vogliono vedere un sacco di esempi di scriptlet, è possibile mostrarli tutti dai pacchetti installati con: | |||
rpm -qa --queryformat "\n\nPACKAGE: %{name}\n" --scripts | less | rpm -qa --queryformat "\n\nPACKAGE: %{name}\n" --scripts | less | ||
Non cercare di interagire con l'utente; RPM è designato per supportare tante installazioni. Se un'applicazione necessita di mostrare 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. Se si installa uno script init e systemd, considerare l'uso di <code>chkconfig</code> o di <code>systemctl</code> 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 <code>name-debug</code>. Se non dovesse succedere, si può disabilitare la creazione dell'rpm-debug aggiungendo in cima allo .spec file: | |||
%global _enable_debug_package 0 | %global _enable_debug_package 0 | ||
%global debug_package %{nil} | %global debug_package %{nil} | ||
%global __os_install_post /usr/lib/rpm/brp-compress %{nil} | %global __os_install_post /usr/lib/rpm/brp-compress %{nil} | ||
mentre nella sezione <code>%install</code>: | |||
export DONT_STRIP=1 | export DONT_STRIP=1 | ||
Un modo per controllare la versione di Fedora in uno .spec file per i build condizionali è: | |||
%if 0%{?fedora} <= <version> | %if 0%{?fedora} <= <version> | ||
Il <code>?</code> permette il riconoscimento della versione se <code>%fedora</code> non è definito. Fa sì che il risultato finale sia <code>0</code>, pur non interferendo sul risultato se presente un valore per <code>%fedora</code>. (Notare che questo metodo non funziona nelle build "scratch" in Koji, dove <code>%fedora</code> è impostato durante la creazione di un SRPM.) | |||
Le GUI devono avere una voce desktop così da permetterne l'uso dal menu grafico. Per i file <code>.desktop</code>, vedere [[Packaging/Guidelines#Desktop_files|Fedora packaging guidelines for desktop files]] e [http://standards.freedesktop.org/desktop-entry-spec/latest/ desktop entry spec]. Per le icone in <code>/usr/share/icons</code>, vedere [http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html icon theme spec]. | |||
== Costruzione del pacchetto binario == | |||
=== Test con rpmlint === | |||
Prima di provare a costruire qualsiasi cosa, si dovrebbe eseguire <code>rpmlint</code> sullo spec file: | |||
Prima di provare a costruire qualsiasi cosa | |||
$ rpmlint program.spec | $ rpmlint program.spec | ||
Troverà molti errori velocemente. Se l'errore riportato non ha molto senso, | Troverà molti errori velocemente. Se l'errore riportato non ha molto senso, | ||
ridare lo stesso comando aggiungendo l'opzione "-i" (questo darà maggiori informazioni). | ridare lo stesso comando aggiungendo l'opzione "-i" (questo darà maggiori informazioni). | ||
L'ideale sarebbe quello d'avere il minor numero di errori, ma talvolta rpmlint riporta dei falsi positivi. | |||
Le [ | Le [[Packaging/Guidelines#Use_rpmlint|linee guida Fedora packaging]] spiega quali sono da ignorare. | ||
== Creazione degli RPM dallo spec file == | === Creazione degli RPM dallo spec file === | ||
Una volta creato uno spec file, chiamato program.spec, è possibile creare | Una volta creato uno spec file, chiamato program.spec, è possibile creare | ||
Line 822: | Line 753: | ||
Quando qualcosa va male, è possibile entrare ("cd") nella directory appropriata e vedere cosa contiene. | Quando qualcosa va male, è possibile entrare ("cd") nella directory appropriata e vedere cosa contiene. | ||
Se si vogliono saltare i passaggi precedenti, usare l'opzione "--short-circuit"; è utile quando si è avuto un build con successo, ma si ha un errore nella sezione %install. Ad esempio, per reiniziare lo stage %install (saltando i passaggi precedenti): | Se si vogliono saltare i passaggi precedenti, usare l'opzione "--short-circuit"; è utile quando si è avuto un build con successo, ma si ha un errore nella sezione %install. Ad esempio, per reiniziare lo stage %install (saltando i passaggi precedenti): | ||
$ rpmbuild -bi --short-circuit program.spec | |||
Se si vuole creare l'rpm sorgente (.src.rpm), entrare nella cartella SPECS e: | Se si vuole creare l'rpm sorgente (.src.rpm), entrare nella cartella SPECS e: | ||
$ rpmbuild -bs program.spec | $ rpmbuild -bs program.spec | ||
Verrà creato l'rpm sorgente nella cartella ~/rpmbuild/SRPMS. Creare ''solo'' l'rpm sorgente è abbastanza veloce, poiché non fa altro che associare lo .spec file e i file SOURCES nel .src.rpm . Creare un rpm binario tipicamente prende più tempo perché richiede l'avvìo degli script %prep, %build e %install. | Verrà creato l'rpm sorgente nella cartella ~/rpmbuild/SRPMS. Creare ''solo'' l'rpm sorgente è abbastanza veloce, poiché non fa altro che associare lo .spec file e i file SOURCES nel .src.rpm . Creare un rpm binario tipicamente prende più tempo perché richiede l'avvìo degli script %prep, %build e %install. | ||
== Testare gli RPM creati | === Testare con rpmlint gli RPM creati === | ||
Avviato rpmlint sullo spec file, generato l'RPM ''binario'' e generato l'RPM sorgente. rpmlint lavora sugli spec, sugli rpm binari o sorgente, trovando cose differenti in ognuno. E' necessario eliminare o modificare degli "rpmlint warning" prima di rilasciare un pacchetto. Dalla cartella SPECS: | Avviato rpmlint sullo spec file, generato l'RPM ''binario'' e generato l'RPM sorgente. rpmlint lavora sugli spec, sugli rpm binari o sorgente, trovando cose differenti in ognuno. E' necessario eliminare o modificare degli "rpmlint warning" prima di rilasciare un pacchetto. [[Common_Rpmlint_issues|Questa pagina]] offre spiegazioni per alcuni dei problemi comuni che potrebbero saltare fuori. <br/> | ||
Dalla cartella SPECS: | |||
$ rpmlint ''NAME''.spec ../RPMS/*/''NAME''*.rpm ../SRPMS/''NAME''*.rpm | $ rpmlint ''NAME''.spec ../RPMS/*/''NAME''*.rpm ../SRPMS/''NAME''*.rpm | ||
Generalmente rpmbuild costruisce rpm binari con informazioni di debug, anche questi possono essere sottoposti al test. | Generalmente rpmbuild costruisce rpm binari con informazioni di debug, anche questi possono essere sottoposti al test. | ||
Line 839: | Line 771: | ||
Se corretti, provare ad installarli diventando root: | Se corretti, provare ad installarli diventando root: | ||
$ su | $ su | ||
# rpm -ivp | # rpm -ivp package1.rpm package2.rpm package3.rpm ... | ||
Per poi testarli, utilizzandoli in differenti modi. Se si decide di usare uno strumento ad interfaccia grafica (GUI), assicurarsi che venga mostrato nel menu (se non lo è, allora qualcosa è sbagliato alla voce .desktop). | Per poi testarli, utilizzandoli in differenti modi. Se si decide di usare uno strumento ad interfaccia grafica (GUI), assicurarsi che venga mostrato nel menu (se non lo è, allora qualcosa è sbagliato alla voce .desktop). | ||
Successivamente è possibile disinstallarli: | Successivamente è possibile disinstallarli: | ||
# rpm -e | # rpm -e package1 package2 package3 | ||
== Mock and Koji == | |||
[[Projects/Mock|Mock]] è un potente tool che usa gli SRPM creati per costruire pacchetti binari all'interno di un ambiente appositamente creato. Questo può essere d'aiuto per la rilevazione delle dipendenze tra pacchetti. Se fallisce, potrebbe mancare qualcosa alla voce BuildRequires. Vedere [[Using Mock to test package builds]] per ulteriori info sull'utilizzo di <code>mock</code>; una volta che il proprio account rientra nel gruppo "<code>mock</code>", è possibile avviare comandi come il seguente per eseguire test in locale: | |||
$ mock -r fedora-9-i386 rebuild path_to_source_RPM | $ mock -r fedora-9-i386 rebuild path_to_source_RPM | ||
Una volta che Mock ha funzionato correttamente, si può usare Koji (il quale usa Mock) per costruire in | Una volta che Mock ha funzionato correttamente, si può usare Koji (il quale usa Mock) per costruire in | ||
differenti sistemi | differenti sistemi. [[PackageMaintainers/Join]] e [[PackageMaintainers/UsingKoji]] hanno molte informazioni su Koji. | ||
Una volta settati, si possono eseguire test sul proprio rpm sorgente con differenti sistemi | Una volta settati, si possono eseguire test sul proprio rpm sorgente con differenti sistemi | ||
$ koji build --scratch dist-f9 path_to_source_RPM | $ koji build --scratch dist-f9 path_to_source_RPM | ||
Si può sostituire la voce " | Si può sostituire la voce "<code>%fc9</code>" con qualsiasi altra release successiva di Fedora, ma non usare <code>dist-rawhide</code>. Ricordarsi che i valori di <code>%fedora</code>, %fc9, ... non saranno giusti per una scratch build, quindi non funzioneranno se il proprio .spec file fa qualcosa di diverso basato su quei valori. | ||
I build koji possono solo dipendere dai pacchetti che sono attualmente disponibili nei repository TARGET. Quindi non si può usare Koji per costruire per distribuzioni rilasciate se il proprio pacchetto dipende da altri nuovi pacchetti che Bodhi non ha ancora rilasciato | I build koji possono solo dipendere dai pacchetti che sono attualmente disponibili nei repository TARGET. Quindi non si può usare Koji per costruire per distribuzioni rilasciate se il proprio pacchetto dipende da altri nuovi pacchetti che Bodhi non ha ancora rilasciato. | ||
Se si vuole costruire un pacchetto che non è ancora una versione aggiornata stabile, si | Se si vuole costruire un pacchetto che non è ancora una versione aggiornata stabile, presentare una richiesta "buildroot override" via Bodhi. Se il pacchetto non è a proprio carico, contattare il/i maintainer. [Prima dell'attuale metodo che prevede una richiesta "buildroot override", si poteva aprire un ticket con rel-eng a https://fedorahosted.org/rel-eng/newticket e chiedere che il pacchetto venisse aggiunto come buildroot override] | ||
== Strumenti utili == | == Strumenti utili == | ||
Il pacchetto | Il pacchetto <code>rpmdevtools</code> fornisce diversi strumenti utili; "<code>rpm -qil rpmdevtools</code>" mostra ciò che verrà installato. | ||
* <code>rpmdev-bumpspec : dal tag release dello spec file, aggiunge un commento al changelog con la data e la versione del software:</code> | |||
$ rpmdev-bumpspec --comment=COMMENT --userstring=NAME+EMAIL_STRING SPECFILES | $ rpmdev-bumpspec --comment=COMMENT --userstring=NAME+EMAIL_STRING SPECFILES | ||
DNF download plugin (dal core DNF plugins) contiene molti strumenti utili: | |||
* <code>dnf download</code>: scarica il pacchetto sorgente | |||
$ dnf download --source PACKAGENAME | |||
Il pacchetto auto-buildrequires ha un paio di buoni strumenti d'aiuto per configurare correttamente la voce BuildRequires. Dopo averlo installato, rimpiazzare "rpmbuild" con "auto-br-rpmbuild" e si vedrà automaticamente generata la lista buildrequires. | Il pacchetto <code>auto-buildrequires</code> ha un paio di buoni strumenti d'aiuto per configurare correttamente la voce BuildRequires. Dopo averlo installato, rimpiazzare "<code>rpmbuild</code>" con "<code>auto-br-rpmbuild</code>" e si vedrà automaticamente generata la lista buildrequires. | ||
Potrebbe essere utile [http://rust.sourceforge.net/ RUST] (GPL) | Potrebbe essere utile [http://rust.sourceforge.net/ RUST] (GPL), anche se non crea rpm di adeguata qualità per i repository Fedora. [http://kitenet.net/~joey/code/alien/ Alien] converte pacchetti di diverso formato. Non produce rpm sorgente puliti ma potrebbe essere utile per la conversione di pacchetti esistenti dai quali trarre informazioni preziose. | ||
[ | Se si ha intenzione di creare un pacchetto RPM per Fedora, assicurarsi di sottoporre il proprio file ad una [https://fedorahosted.org/FedoraReview/ Fedora Review], che aiuta a garantire che ci si attenga alle [[Packaging:Guidelines?rd=Packaging/Guidelines|Linee-guida sul Packaging]]. | ||
Finalmente, [https://github.com/alanfranz/docker-rpm-builder docker-rpm-builder] (APL 2.0) usa [http://www.docker.com Docker] per costruire i pacchetti RPM; mentre l'uso di 'rpmbuild' richiede di lavorare nella stessa distro del target, e 'mock' funziona bene su distribuzioni Fedora/Centos/RHEL per qualsiasi target, '''quest'ultimo strumento lavora con Docker'''. | |||
Se si preferisce costruire RPM per altre distribuzioni o architetture avendo accesso pubblico ai repository, è possibile usare [https://copr.fedoraproject.org Copr]. | |||
* [[Join the package collection maintainers| How to join the Fedora Package Collection Maintainers]] - | |||
Per firmare il pacchetto, usare <code>rpmsign</code>. | |||
== Linee guida e regole == | |||
Una volta creato il proprio pacchetto, bisogna seguire queste regole e linee guida: | |||
* [[Join the package collection maintainers| How to join the Fedora Package Collection Maintainers]] - Descrive il processo per diventare Fedora package maintainer | |||
* [[Packaging:Guidelines | Packaging Guidelines]] | * [[Packaging:Guidelines | Packaging Guidelines]] | ||
* [[Packaging:NamingGuidelines| Package Naming Guidelines]] | * [[Packaging:NamingGuidelines| Package Naming Guidelines]] | ||
Line 887: | Line 824: | ||
* [[Packaging:ReviewGuidelines| Package Review Guidelines]] | * [[Packaging:ReviewGuidelines| Package Review Guidelines]] | ||
Ci sono molte linee guida ufficiali che possono essere d'aiuto in circostanze particolari | |||
(Java programs, OCaml programs, GNOME programs, etc.) | (Java programs, OCaml programs, GNOME programs, etc.). | ||
Si può inoltre imparare molto dalle sezioni [[SIGs]] e | |||
[[:Category:Package Maintainers|Package Maintainers]]. | |||
[[:Category:Package Maintainers|Package Maintainers]] | [[Special:Prefixindex/Packaging|Lista delle pagine wiki sul Packaging]]. | ||
[ | |||
Inoltre, si potrebbero trovare utili quelle non ufficiali | |||
[[Special:Search?ns0=1&search=PackagingDrafts%2F&searchx=Search|Packaging Drafts]] e [[PackagingDrafts|Packaging Drafts To Do]]. | |||
Si potrebbero trovare spunti da [http://en.opensuse.org/Packaging SuSE], | |||
[http://www.debian.org/doc/debian-policy/ Debian], ma | |||
[http://www.mail-archive.com/distributions@lists.freedesktop.org/msg00156.html ci sono differenze tra le distribuzioni], quindi si presume che non possono essere usate direttamente. | |||
[http://www.debian.org/doc/debian-policy/ Debian], | |||
[http://www.mail-archive.com/distributions@lists.freedesktop.org/msg00156.html | |||
'''I file .spec creati devono riguardare software opensource come previsto dal [[Legal:Fedora_Project_Contributor_Agreement|FPCA]].''' | |||
[ | |||
== | == Mantenimento del pacchetto == | ||
Quando il pacchetto viene accettato, dev'essere mantenuto dal maintainer (o dal co-maintainer). | |||
Vedere [[Package update HOWTO]] e [[Package update guidelines]] per maggiori informazioni. | |||
Se si aggiorna a più di una release Fedora, farlo a ritroso nel tempo; ad esempio, release per Fedora N, una volta accettato, Fedora N -1 | |||
release | ( il sistema presuppone che versioni successive di Fedora hanno versioni uguali o più aggiornate dei programmi). | ||
( | |||
Incoraggiare gli sviluppatori upstream ad usare convenzioni stardard nel rilascio del codice sorgente; questo renderà più facile il packaging del software. Per maggiori informazioni, vedere: | |||
* [http://www.dwheeler.com/essays/releasing-floss-software.html Releasing Free/Libre/Open Source Software (FLOSS) for Source Installation] ( | * [http://www.dwheeler.com/essays/releasing-floss-software.html Releasing Free/Libre/Open Source Software (FLOSS) for Source Installation] (sommario veloce) | ||
* [http://www.gnu.org/prep/standards/html_node/Managing-Releases.html GNU Coding Standards release process] | * [http://www.gnu.org/prep/standards/html_node/Managing-Releases.html GNU Coding Standards release process] | ||
* [http://en.tldp.org/HOWTO/Software-Release-Practice-HOWTO/ Software Release Practice HOWTO] | * [http://en.tldp.org/HOWTO/Software-Release-Practice-HOWTO/ Software Release Practice HOWTO] | ||
Line 919: | Line 853: | ||
* [http://offog.org/articles/packaging/ Packaging Unix software] | * [http://offog.org/articles/packaging/ Packaging Unix software] | ||
== | == Per maggiori informazioni == | ||
La pagina [[:Category:Package Maintainers|Package Maintainers]] è collegata a molte altre pagine utili e | |||
[[Package update HOWTO]] | [[Package update HOWTO]] descrive come aggiornare un pacchetto esistente già mantenuto in Fedora. | ||
Per maggiori informazioni, fuori dal wiki Fedora, vedere: | |||
* [http://www.g-loaded.eu/2006/04/05/how-to-build-rpm-packages-on-fedora/ How to build RPM packages on Fedora] - | * [http://www.g-loaded.eu/2006/04/05/how-to-build-rpm-packages-on-fedora/ How to build RPM packages on Fedora] - ripasso veloce | ||
* Packaging software | * Packaging software con RPM (developerWorks) [http://www.ibm.com/developerworks/library/l-rpm1/ Part 1], [http://www.ibm.com/developerworks/library/l-rpm2/ Part 2] e [http://www.ibm.com/developerworks/library/l-rpm3.html Part 3] | ||
* Fedora Classroom | * Fedora Classroom ha avuto una sessione IRC sul packaging e si può far riferimento al log su https://fedoraproject.org/wiki/Building_RPM_packages_%2820090405%29 | ||
* [http://koti.welho.com/vskytta/packagers-handbook/packagers-handbook.html Fedora Packager | * [http://koti.welho.com/vskytta/packagers-handbook/packagers-handbook.html Manuale Fedora Packager] | ||
* [http://www.redhatmagazine.com/2008/02/28/when-sally-met-eddie-the-fedora-package-story/ When Sally met Eddie] - | * [http://www.redhatmagazine.com/2008/02/28/when-sally-met-eddie-the-fedora-package-story/ When Sally met Eddie] - Un semplice testo con pochi dettagli | ||
* [http://rpm.org/max-rpm-snapshot/ Maximum RPM Book] - | * [http://rpm.org/max-rpm-snapshot/ Maximum RPM Book] - Molte informazioni complete, ma in alcuni casi obsolete | ||
* [http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch-creating-rpms.html RPM Guide, section on creating RPMs] - | * [http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch-creating-rpms.html RPM Guide, section on creating RPMs] - Ha parecchie buone informazioni leggermente più aggiornate, ma è una bozza | ||
* [http://docs.fedoraproject.org/developers-guide/ch-rpm-building.html | * [http://docs.fedoraproject.org/developers-guide/ch-rpm-building.html Guida per sviluppatori, sezione building RPM] | ||
* [http://www.gurulabs.com/GURULABS-RPM-LAB/GURULABS-RPM-GUIDE-v1.0.PDF Creating RPMS slides] | * [http://www.gurulabs.com/GURULABS-RPM-LAB/GURULABS-RPM-GUIDE-v1.0.PDF Creating RPMS slides] da Guru Labs | ||
* [http://freshrpms.net/docs/fight/ | * [http://freshrpms.net/docs/fight/ La lotta, il mio primo tentativo di fare un'introduzione leggibile sull'rpm building.] | ||
* [http://genetikayos.com/code/repos/rpm-tutorial/trunk/rpm-tutorial.html RPM Tutorial (Fullhart)] | * [http://genetikayos.com/code/repos/rpm-tutorial/trunk/rpm-tutorial.html RPM Tutorial (Fullhart)] | ||
* [http://www-uxsup.csx.cam.ac.uk/talks/rpmbuild/rpmbuild.pdf Cambridge RPM tutorial] | * [http://www-uxsup.csx.cam.ac.uk/talks/rpmbuild/rpmbuild.pdf Cambridge RPM tutorial] è una presentazione sulla creazione basilare degli RPM | ||
* [http://en.tldp.org/HOWTO/RPM-HOWTO/index.html RPM HOWTO: RPM | * [http://en.tldp.org/HOWTO/RPM-HOWTO/index.html] RPM HOWTO: RPM al Minimo di Donnie Barnes | ||
* [http://home.fnal.gov/~dawson/rpms/howto/index.html RPM HowTo | * [http://home.fnal.gov/~dawson/rpms/howto/index.html] RPM HowTo di Dawson | ||
* [http://en.opensuse.org/SUSE_Build_Tutorial SuSE build tutorial] - | * [http://en.opensuse.org/SUSE_Build_Tutorial SuSE build tutorial] - ma su SuSE, non per Fedora. [http://en.opensuse.org/Build_Service/cross_distribution_package_how_to Cross-distribution package HOWTO] contiene suggerimenti se si fanno rpm per diverse distribuzioni. | ||
* [http://wiki.mandriva.com/en/Development/Howto/RPM Mandriva Rpm HowTo (en)] ([http://www.mandrivaclub.com/xwiki/bin/view/KB/MandrivaRpmHowTo alt]) | * [http://wiki.mandriva.com/en/Development/Howto/RPM Mandriva Rpm HowTo (en)] ([http://www.mandrivaclub.com/xwiki/bin/view/KB/MandrivaRpmHowTo alt]) è un tutorial RPM anche se per Mandriva. Da notare che in Fedora ''non'' si ricomprimono i tarball originali, come Mandriva suggerisce, perché questo avrebbe cambiato le loro hash crittografate. | ||
* [http://linuxshellaccount.blogspot.com/2008/03/creating-your-own-linux-rpms-initial.html | * [http://linuxshellaccount.blogspot.com/2008/03/creating-your-own-linux-rpms-initial.html Creazione del proprio Linux RPM - Software Building Iniziale] è un'altra introduzione ma fa il punto su "Il processo per costruire RPM è più facile della creazione dei pacchetti per Solaris... Meno passaggi, e l'abilità di aggiungere tutte le informazioni sul software in uno specifico file, fatti per una maggiore essenzialità (più facile da modificare e riprodurre) del sistema di packaging". | ||
* [http://fedoranews.org/alex/tutorial/rpm/ | * [http://fedoranews.org/alex/tutorial/rpm/ Tutto ciò che bisogna sapere su RPM] (più sull'installazione che sulla creazione) | ||
* The [http://wiki.rpm.org/ rpm.org Wiki] | * The [http://wiki.rpm.org/ rpm.org Wiki] ha alcune informazioni utili, come la [http://wiki.rpm.org/Problems lista dei problemi conosciuti] | ||
Da notare: il sito [http://rpm5.org/ rpm5.org] ha alcuni documenti ma non dipende da loro; è la casa di un fork di RPM mantenuto da Jeff Johnson. L'RPM usato da Fedora (e da Novell/SuSE) ha invece la sede in [http://www.rpm.org rpm.org].<br> | |||
[http://lwn.net/Articles/236029/ lwn.net | [http://lwn.net/Articles/236029/ lwn.net] contiene un articolo a riguardo. | ||
[[Category:Package Maintainers]][[Category:How to]] | [[Category:Package Maintainers]] | ||
[[Category:How to]] | |||
[[Category:Italiano]] | |||
[[Category:Da revisionare]] |
Latest revision as of 20:59, 19 September 2016
Introduzione
Questa pagina descrive in dettaglio i meccanismi di base su come creare un pacchetto RPM ed in particolare come creare uno SPEC file. A differenza di altre guide su RPM, questa pagina spiega le specifiche per Fedora legate alle linee guida ufficiali. Da quando è mantenuta su Fedora wiki, è probabile che sia più aggornata rispetto ad altre guide. Nonostante tutto, non tutto l'intero documento è applicabile anche ad altre distro basate su RPM. Se "si vogliono stringere i tempi" leggere How to create a GNU Hello RPM package.
Attualmente la Documentazione Fedora ha rilasciato una bozza di guida per i packager: Packagers Guide
Da notare che questa pagina NON mostra le linee guida ufficiali sulla creazione dei pacchetti per Fedora; a questo proposito, il Packaging Committee gestisce le regole e le linee guida stesse per il packaging in Fedora. Quelle più importanti:
Packaging Guidelines e Package Naming Guidelines sono le principali. Detto ciò, questa pagina dovrebbe essere compatibile con loro.
Se si prevede di creare un pacchetto RPM per il repository di Fedora, seguire la procedura Come diventare manutentori dei pacchetti Fedora Collection.
Impostazione del sistema
Prima di creare pacchetti RPM in Fedora, bisogna installare alcuni strumenti di sviluppo e settare l'account (o gli account) che si userà. Come root (non digitare il '#' !)
# dnf install @development-tools # dnf install fedora-packager # dnf install rpmdevtools
E' possibile creare un "utente dedicato" appositamente per costruire pacchetti rpm. In questo modo, se qualcosa dovesse andare male, il programma o il processo di costruzione non cancellerà dati personali e non invierà file o chiavi private al mondo esterno.
Creare un nuovo utente chiamato semplicemente "makerpm", aggiungerlo al gruppo 'mock', impostarne la password eseguendo:
# /usr/sbin/useradd makerpm # usermod -a -G mock makerpm # passwd makerpm
Poi loggarsi come utente speciale (makerpm).
Una volta loggatosi, si dovrà creare una struttura nella propria cartella home eseguendo (non digitare il '$'):
$ rpmdev-setuptree
Il programma "rpm-setuptree" creerà una cartella ~/rpmbuild. All'interno di "rpmbuild" ci sono una serie di sottocartelle (come SPECS e BUILD) che si useranno per creare i propri pacchetti. Sarà inoltre creato il file ~/.rpmmacros
, usato per impostare opzioni aggiuntive.
Le linee guida per il packaging raccomandano l'uso di comandi che preservano il timestamps dei file; è possibile farlo automaticamente usando wget o curl per procurarsi i file sorgente.
Se si usa wget assicurarsi di aggiungere il comando "timestamping = on
" al file ~/.wgetrc
. allo stesso modo se si usa curl, nel file ~/.curlrc
dev'essere presente il testo "-R"
.
Una volta fatto questi passaggi per la creazione dell'account, normalmente non sarà necessario rifarli ancora.
Le basi della creazione di pacchetti RPM
Per creare un pacchetto RPM, è necessario creare un file di testo ".spec" che fornisce informazioni sul software che viene pacchettizzato.
Quindi si esegue il comando "rpmbuild" sul file spec, che completa una serie di passi per produrre il pacchetto.
Normalmente si opera collocando il sorgente originale (incontaminato), ad esempio un file tar.gz degli sviluppatori originali, in "~ /rpmbuild/SOURCES". Si consiglia di inserire il file .spec in "~/rpmbuild/SPECS" chiamandolo "NAME.spec" , dove NAME è il nome base del pacchetto. Per creare tutti i pacchetti (sia binari che pacchetti sorgenti), si deve passare alla directory "~/rpmbuild/SPECS" ed eseguire:
$ rpmbuild -ba NAME.spec
Quando viene richiamato in questo modo rpmbuild legge il file .spec e tenta di passare attraverso le seguenti fasi in questo ordine (i nomi che iniziano con %
sono macro predefinite come descritto di seguito):
Alcune directory hanno determinati funzioni per rpmbuild
che possono essere sostituiti nel file .spec
in base alle macro predefinite (iniziano per %
):
Come si può vedere, alcune directory hanno scopi particolari per rpmbuild
. Queste sono:
Nome della Macro | Nome | Predefinito | Funzione |
---|---|---|---|
%_specdir |
Specification directory | ~/rpmbuild/SPECS |
File SPEC degli RPM (.spec) |
%_sourcedir |
Source directory | ~/rpmbuild/SOURCES |
Pacchetto dei sorgenti incontaminati (es: tarballs) e patch |
%_builddir |
Build directory | ~/rpmbuild/BUILD |
I file sorgente vengono spacchettati e compilati nella sua subdirectory. |
%_buildrootdir |
Build root directory | ~/rpmbuild/BUILDROOT |
I file vengono installati qui durante la fase %install .
|
%_rpmdir |
Binary RPM directory | ~/rpmbuild/RPMS |
Binari RPM sono creati e immagazzinati qui sotto. |
%_srcrpmdir |
Source RPM directory | ~/rpmbuild/SRPMS |
Gli RPM sorgente sono creati e immagazzinati qui sotto. |
Per creare i pacchetti binario e sorgente, dalla directory ~/rpmbuild/SPECS
avviare:
$ rpmbuild -ba NAME.spec
Quando invocato in questo modo rpmbuild
legge il file .spec
e segue le seguenti fasi di lavoro:
Nome dela Macro | Nome | Predefinito | Funzione |
---|---|---|---|
%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.
|
%prep |
%_sourcedir |
%_builddir |
Compila i file nella directory sotto quella di build %_builddir . Di solito si possono realizzare qui alcune variazioni di "./configure && make ".
|
%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.
|
%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 ".
|
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.
|
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, cambiare il file .spec
(o altri file di input) a seconda delle necessità.
Prepararsi per pacchettizzare un programma in particolare
Se ci sono programmi speciali richiesti per costruire o avviare il programma da pacchettizzare, installarli e prendere nota di cosa sono (queste informazioni serviranno).
Per pacchettizzare un programma per i repository Fedora, si devono pacchettizzare i sorgenti incontaminati (originali), insieme a patch e istruzioni di costruzione; non va bene cominciare con codice precompilato.
Salvare il file con il sorgente originale (solitamente un file .tar.gz
) nella cartella "~/rpmbuild/SOURCES
" (dell'utente costruttore di rpm).
Leggere dal manuale le istruzioni d'installazione del programma; si deve rendere automatizzato il tutto editando uno ".spec" file, quindi capire cosa si deve fare prima. Probabilmente è meglio fare una prova di compilazione attraverso la procedura di costruzione/installazione senza usare l'RPM per prima (è consigliato specialmente se non si ha dimistichezza con gli rpm). Con qualche eccezione, tutti i programmi binari e le librerie incluse nei pacchetti Fedora devono essere costruiti dal codice sorgente contenuto nei pacchetti sorgente.
Suddividere il programma
Il codice sorgente delle applicazioni è spesso rilasciato con il codice sorgente di librerie esterne incorporate. Non incorporare insieme librerie esterne e applicazione che le usa in un singolo pacchetto. Al contrario separarle in più pacchetti.
Licenza
Usare solo software che può essere pacchettizzato legalmente.
Leggere Packaging:Guidelines#Legal, Licensing:Main and Packaging:LicensingGuidelines. In generale, serve ai soli pacchetti software rilasciati come open source software (OSS) con una licenza approvata (così come le GNU GPL, GNU LGPL, BSD-new, MIT/X o Apache 2.0). Assicurarsi che il software sia realmente licenziato in questo modo (ad esempio controlli casuali del codice sorgente degli header, README file e così via). Se ci sono pacchetti di librerie, assicurarsi che anch'esse siano OSS.
Riusare informazioni esistenti
Provare a riutilizzare quello che si può. Ovviamente, assicurarsi che non si stia pacchettizzando qualcosa che già esiste; nella Fedora Package Collection Fedora Package Database c'é una lista dei pacchetti esistenti. Inoltre controllare la In Progress Review Requests (per pacchetti in fase di revisione) e la lista Retired Packages. E' possibile usare Fedora Packages Git Repositories per vedere direttamente gli .spec file (e patch) di qualsiasi pacchetto esistente in Fedora.
E' possibile scaricare gli RPM sorgenti usando il DNF download Plugin:
$ dnf download --source sourcepackage-name
In alternativa, un rpm sorgente può essere recuperato manualmente visitando la pagina web Fedora mirror http o ftp,
selezionando la cartella releases/40/Everything/source/SRPMS
.
(rimpiazzare "40
" con la versione di Fedora desiderata),
e scaricare l'rpm sorgente voluto (il nome termina con .src.rpm).
Ottenuto l'rpm sorgente, installarlo in ~/rpmbuild
:
$ rpm -ivh sourcepackage-name*.src.rpm
E' possibile inoltre depacchettizzare il .src.rpm in una directory con rpm2cpio
:
$ mkdir PROGRAMNAME_src_rpm $ cd PROGRAMNAME_src_rpm $ rpm2cpio ../PROGRAMNAME-*.src.rpm | cpio -i
Qualche volta è più facile iniziare con un pacchetto esistente, per poi ripulirlo per Fedora;
RPM Find e PKGS.org potrebbero aiutare a trovare RPM per sistemi non-Fedora
(si possono installare rpm sorgenti di altri sistemi come in Fedora).
In caso, si potrebbe vedere per pacchetti sorgente (non pacchetti .deb
binari) per Ubuntu
o Debian (pacchetti sorgente sono degli standard tarball con una
sottocartella debian/
, possibilmente associata con delle patch).
Se FreeBSD ports collection dovesse averlo,
si potrebbe scaricare il FreeBSD ports tarball
e vedere se le loro informazioni di pacchettizzazione possono aiutare come inizio.
Tuttavia, questo potrebbe non essere di aiuto a tutti.
Differenti distribuzioni hanno differenti regole e quello che fanno potrebbe essere inappropriato per Fedora.
Creare un file spec
E' necessario creare ora il file ".spec" nella directory "~/rpmbuild/SPECS
".
E' consigliato dare al file il nome del programma (es: "program.spec
"). Usare il nome dell'archivio oppure il nome sostenuto dall'autore del programma dove possibile, ma assicurarsi di rispettare le
Linee guida per il Naming dei pacchetti.
Modelli ed esempi di SPEC
Modelli
Quando si crea uno .spec file per la prima volta, è possibile usare editor come vim o emacs che creeranno automaticamente uno .spec iniziale:
$ cd ~/rpmbuild/SPECS $ vi program.spec
Di seguito un esempio di questo template (Nota: il modello fornito sotto non necessariamente è conforme con le linee guida del Fedora Packaging):
Name: Version: Release: 1%{?dist} Summary: Group: License: URL: Source0: BuildRequires: Requires: %description %prep %autosetup %build %configure make %{?_smp_mflags} %install %make_install %files %doc %license %changelog
E' possibile usare $RPM_BUILD_ROOT
al posto di %{buildroot}
; basta che siano coerenti.
E' possibile usare il comando rpmdev-newspec
per creare un file di .spec . rpmdev-newspec NOME-DEL-NUOVO-PACCHETTO
crea un file spec iniziale per un nuovo pacchetto, su misura per vari tipi di pacchetti. Il programma individuerà il tipo di modello da usare dal nome del pacchetto, oppure specificare un particolare tipo di modello. Controllare /etc/rpmdevtools/spectemplate-*.spec
per consultare i modelli disponibili e rpmdev-newspec --help
per maggiori informazioni. Per esempio, per creare un nuovo file di spec per un modulo python:
cd ~/rpmbuild/SPECS rpmdev-newspec python-antigravity vi python-antigravity.spec
Esempi
eject
L'esempio di seguito mostra uno .spec per Fedora 16 per il programma eject
:
Summary: A program that ejects removable media using software control Name: eject Version: 2.1.5 Release: 21%{?dist} License: GPLv2+ Group: System Environment/Base Source: %{name}-%{version}.tar.gz Patch1: eject-2.1.1-verbose.patch Patch2: eject-timeout.patch Patch3: eject-2.1.5-opendevice.patch Patch4: eject-2.1.5-spaces.patch Patch5: eject-2.1.5-lock.patch Patch6: eject-2.1.5-umount.patch URL: http://www.pobox.com/~tranter ExcludeArch: s390 s390x BuildRequires: gettext BuildRequires: libtool %description The eject program allows the user to eject removable media (typically CD-ROMs, floppy disks or Iomega Jaz or Zip disks) using software control. Eject can also control some multi-disk CD changers and even some devices' auto-eject features. Install eject if you'd like to eject removable media using software control. %prep %autosetup -n %{name} %build %configure make %{?_smp_mflags} %install %make_install install -m 755 -d %{buildroot}/%{_sbindir} ln -s ../bin/eject %{buildroot}/%{_sbindir} %find_lang %{name} %files -f %{name}.lang %doc README TODO ChangeLog %license COPYING %{_bindir}/* %{_sbindir}/* %{_mandir}/man1/* %changelog * Tue Feb 08 2011 Fedora Release Engineering <rel-eng@lists.fedoraproject.org> - 2.1.5-21 - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild * Fri Jul 02 2010 Kamil Dudka <kdudka@redhat.com> 2.1.5-20 - handle multi-partition devices with spaces in mount points properly (#608502)
Panoramica del file SPEC
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.
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 riferimanto a Nome, Versione e Release rispettivamente. Quando si cambia un tag, la macro automaticamente aggiorna al nuovo valore.
- Name: Il nome del pacchetto, che dovrebbe 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 esempio2008-05-01
diventa8.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 a1
. 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. NON finisce con una sola frase.
- Group: Necessita di un gruppo preesistente, come "Applications/Engineering"; avviare "
less /usr/share/doc/rpm/GROUPS
" per conoscere la lista completa. Usare il gruppo "Documentation" per qualsiasi sotto pacchetto (ad esempiokernel-doc
) contenente documentazione. Nota: Questo tag è disapprovato a partire da Fedora 17. Vedere [Introduzione di riferimento Spec File] - License: La licenza che 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 cartellaSOURCES
. 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, nominarliSource1
,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 programmaEGGS
, determinarne il pacchetto che lo possiede con "rpm -qf
". Mantenere le dipendenze ad un numero minimo (ad esempio usarewhich EGGS
sed
invece diperl
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
può essere utile.auto-buildrequires
- 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 inNAME
. Vedere la sezione %prep. - %build: Comandi script per "costruire" il programma (ad esempio compilare) ed ottenerlo pronto per l'installazione. Incluse le istruzion su come farlo. Vedere la sezione %build.
- %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 in Fedora mentre è necessaria per EPEL. Tipicamente contiene solo:
rm -rf %{buildroot} # ridondante eccetto per RHEL 5
- %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 creare un pacchetto "ricollocabile"; non valgono in Fedora e sono complicati.
Approfondimento sezioni SPEC file
Sezione %prep
La sezione "%prep" descrive come spacchettare gli archivi compressi così da poter iniziare la compilazione. Di solito include i comandi "%autosetup"; in alternativa di usano i comandi "%setup" e/o "%patch" con riferimenti alle linee Source0:, Source1:, etc. Vedere la sezione su %setup e %patch in Maximum RPM per maggiori dettagli.
Le macro %{patches} e %{sources} sono disponibili da RPM 4.4.2; se si usa una lunga lista di patch o sorgenti ed %autosetup non è vi è utile, è possibile fare qualcosa del genere:
for p in %{patches}; do ... done
Tuttavia tener presente che usandole si otterranno .spec file incompatibli con RPM usati in RHEL ed altre distro basate su RPM.
Sezione %prep: comando %autosetup
Il comando "%autosetup
" spacchetta i sorgente.
-n
name : Se il tarball Source decomprime in una directory non nominata come l'RPM, questa opzione può essere usata per specificare il corretto nome. Per esempio, se il file .tar decomprime nella cartella FOO, allora usare "%autosetup -n FOO
".-c
name : Se il tarball Source in più cartelle invece di una singola, l'opzione può essere usata per crearne una chiamata name.
Se si usa il comando "%setup
" invece, allora l'opzione -q
è comunemente usata per sopprimere gli output non necessari.
Ci sono più opzioni %setup, utili principalmente se si stanno creando sottopacchetti. Quelle principali sono:
-a number |
Decomprime il Source dato dal numero indicato dopo aver cambiato cartella (ad esempio "–a 0 " per Source0).
|
-b number |
Decomprime il Source dato dal numero indicato prima aver cambiato cartella (ad esempio "–a 0 " per Source0).
|
-D |
Non cancella la cartella dopo la decompressione. |
-T |
Disabilita la decompressione automatica dell'archivio. |
Sezione %prep: comando %patch
Se è stato usato il comando "%autosetup
", le nozioni sotto indicate non servono.
Se si hanno necessità più complesse o di compatibilità con EPEL, allora possono servire.
Il comando "%patch0
" applica Patch0 (e %patch1 applica Patch1 etc.). Le patch sono normali metodi di modifica necessari per "aggiustare" il codice sorgente. Si applica la solita opzione "-pNUMBER
" che passa l'argomento al programma patch
.
I file Patch sono nominati spesso come "telnet-0.17-env.patch
", nel formato %{name} - %{version} - REASON.patch
" (a volte la versione è omessa). I file Patch sono il risultato di "diff -u
"; se si fa dalla subdirectory di ~/rpmbuild/BUILD
allora non è necessario specificare un livello -p
.
Questa è la tipica procedura per creare una patch da un singolo file:
cp foo/bar foo/bar.orig vim foo/bar diff -u foo/bar.orig foo/bar > ~/rpmbuild/SOURCES/PKGNAME.REASON.patch
Se si editano molti file, un metodo facile è la copia dell'intera subdirectory sotto BUILD
per poi avviare il diff
. Dopo aver cambiato cartella a "~rpmbuild/BUILD/NAME
", allora:
cp -pr ./ ../PACKAGENAME.orig/ ... modifiche ... diff -u ../PACKAGENAME.orig . > ~/rpmbuild/SOURCES/NAME.REASON.patch
Se si modificano più file in una sola patch, è possibile anche copiare quelli originali usando alcune desinenze come ".orig
" prima di modificarle. Per poi usare "gendiff
" (nel pacchetto rpm-build
) per creare una patch con le modifiche.
Assicurarsi che le patch corrispondano correttamente al contesto. Il valore predefinito "fuzz" è "0
". Ci si può lavorare aggiungendo "%global _default_patch_fuzz 2
" per ripristinare il valore trovato nelle vecchie versioni dell'RPM in Fedora, ma generalmente è raccomandato evitarlo.
Come spiegato in Packaging/PatchUpstreamStatus, tutte le patch dovrebbero avere un commento nello .spec file sul loro stato nell'upstream, includendo il bug, la data e la mail. Se è unico si dovrebbe menzionarne il motivo. Il Fedora Project non vuole allontanarsi dagli sviluppi dell'upstream; vedere PackageMaintainers/WhyUpstream.
Sezione %prep: file non modificati
A volte uno o più file del Source non necessitano d'essere decompressi. Si possono "prep" (prepararli) nella cartella build come (dove SOURCE1
si riferisce al corrispondente file Source):
cp -p %SOURCE1 .
Sezione %build
La sezione "%build" è qualche volta complicata; in essa si può configurare e compilare/costruire i file che saranno installati.
Molti programmi seguono la GNU configure
(o alcune varianti). Come predefinito, installeranno in un prefix "/usr/local
", ragionevolmente per dei file spacchettati. Tuttavia una volta impacchettati, cambia in "/usr
". Le librerie dovrebbero essere installate o in /usr/lib
oppure in /usr/lib64
in base all'architettura.
Dal momento che GNU configure
è così comune, la macro "%configure
" può essere usata per invocare automaticamente le corrette opzioni (ad esempio cambiare il prefix a /usr
). Alcune sue varianti funzionano spesso:
%configure make %{?_smp_mflags}
Per sostituire le variabili del makefile, passarle come parametro a make
:
make %{?_smp_mflags} CFLAGS="%{optflags}" BINDIR=%{_bindir}
Per maggiori informazioni vedere "GNU autoconf, automake, and libtool".
Alcuni programmi usano cmake
. Vedi Packaging/cmake.
Sezione %check
Se disponibili dei self-test, è buona idea includerli. Dovrebbero essere piazzati nella sezione %check (che segue la sezione %build) invece che all'interno della %build stessa, così da poter essere facilmente saltati se necessario.
Spesso questa sezione contiene:
make test
A volte può essere:
make check
Osservare il file Makefile per sapere il modo più appropriato.
Sezione %install
Questa sezione coinvolge degli script per "install" (installare) il programma, copiando i file rilevanti da %{_builddir}
a %{buildroot}
(che solitamente significa da ~/rpmbuild/BUILD
a ~/rpmbuild/BUILDROOT
) e creando e cartelle all'interno di %{buildroot}
.
Parte della terminologìa può essere fuorviante:
- La "build directory", anche conosciuta come
%{_builddir}
, non è la stessa della "build root", conosciuta anche come%{buildroot}
. La compilazione avviene nella prima, mentre i file da impacchettare sono copiati dalla prima alla seconda. - Durante la sezione %build, la cartella di partenza è
%{buildsubdir}
, sottocartella all'interno di%{_builddir}
, creata precedentemente durante il %prep. Di solito è qualcosa del genere~/rpmbuild/BUILD/%{name}-%{version}
. - La sezione %install non parte quando l'RPM binario è installato dall'utente finale, ma è avviata solo nella creazione del pacchetto.
Alcune varianti di "make install
":
%install
rm -rf %{buildroot} # ridondante ad eccezione di RHEL5 %make_install
Idealmente si dovrebbe usare DESTDIR=%{buildroot}
se il programma lo supporta, dato che redirige i file d'installazione alla specifica cartella ed è esattamente ciò che ci si aspetta che faccia durante la sezione %install.
Se il programma non supporta DESTDIR
(e solo se), è possibile in alternativa una delle seguenti strade:
- Patchare il makefile così che possa supportare
DESTDIR
. Creare cartelle all'interno diDESTDIR
dove necessario e includerne la patch dall' upstream. - Usare la macro "
%makeinstall
". Questo metodo potrebbe funzionare, ma può portare a fallimenti. Tramite la macro si arriva a qualcosa del genere "make prefix=%{buildroot}%{_prefix} bindir=%{buildroot}%{_bindir} ... install
", che in alcuni programmi pu non funzionare. Creare cartelle all'interno di%{buildroot}
dove serve. - Considerare l'uso del pacchetto
auto-destdir
. Richiede "BuildRequires: auto-destdir
" and di cambiare "make install
" in "make-redir DESTDIR=%{buildroot} install
". Funziona bene se l'installazione usa solo certi comandi comuni per installare i file, comecp
einstall
. - Installare manualmente. Dovrbbe includere la creazione delle necessarie cartelle sotto
%{buildroot}
e la copia dei file da%{_builddir}
a%{buildroot}
. Bisogna essere cauti con gli aggiornamenti, contengono spesso nuovi filename. Un esempio di questa procedura:
%install rm -rf %{buildroot} mkdir -p %{buildroot}%{_bindir}/ cp -p mycommand %{buildroot}%{_bindir}/
Sezione %files
Questa sezione dichiara i file e le cartelle proprietà del pacchetto quindi incorporati nell'RPM binario.
Nozioni sulla sezione %files
Il %defattr
imposta i permessi predefiniti del file e spesso appare all'inizio della sezione %files
. Da notare che non è più necessario a meno che non bisogna i permessi. Il formato è:
%defattr(<file permissions>, <user>, <group>, <directory permissions>)
Il quarto parametro è solitamente omesso. Si usa %defattr(-,root,root,-)
, dove "-
" usa i permessi predefiniti.
Si dovrebbero poi elencare i file e le cartelle che saranno di proprietà del pacchetto. A tal proposito usare le macro per i nomi delle cartelle, mostrate in Packaging:RPMMacros (ad esempio usare %{_bindir}/mycommand
invece di /usr/bin/mycommand
). Se la stringa inizia con "/
" (o quando esteso da una macro) allora viene prelevato dalla cartella %{buildroot}
. Oppure, si presume che il file sia nella cartella corrente (ad esempio dentro %{_builddir}
come per i file di documentazione da includere). Se il pacchetto installa un solo file /usr/sbin/mycommand
, la sezione %files
può semplicemente essere:
%files %{_sbindir}/mycommand
Per ottenere un rpm meno soggetto ai cambiamenti dell'upstream, dichiarare tutti i file all'interno di una cartella di proprietà del pacchetto con la stringa:
%{_bindir}/*
Per includere una singola cartella:
%{_datadir}/%{name}/
Notare che %{_bindir}/*
non dice che il pacchetto in oggetto sia proprietario della cartella /usr/bin
, ma solo dei file contenuti all'interno. Se si elenca una cartella, allora si richiede la proprietà di quella cartella e dei file e sottocartelle contenute. Quindi non si elenca %{_bindir}
assicurardosi anche delle cartelle condivise con altri rpm.
Si verificheranno errori se:
- una stringa non incontra alcun file o cartella
- file o cartelle sono elencate più volte
- file o cartelle in
%{buildroot}
non listate
E' inoltre possibile escludere file usando %exclude
. Può aiutare per includere quasi tutti i file da differenti stringhe ma fallirà se non incontra nulla.
%files prefix
Potrebbe essere necessario aggiungere uno o più prefissi alle linee della sezione %files
; separate da uno spazio. Vedi Max RPM section on %files directives.
Solitamente "%doc
" è usato per elencare file di documentazione dentro %{_builddir}
che non sono stati copiati in %{buildroot}
. I file README
e INSTALL
sono di solito inclusi. Saranno piazzati nella cartella /usr/share/doc
, la cui proprietà non ha bisogna d'essere dichiarata.
Nota: Se si specifica una voce %doc
, rpmbuild < 4.9.1 rimuove la cartella doc, nella quale piazza i file prima di installarli. Ciò significa che i file già all'interno, ad esempio installati nella sezione %install
, sono rimossi e non finiranno nel pacchetto. Se si vuole installare alcuni file in nella sezione %install
, farlo in una cartella temporanea all'interno della build dir (non in build root), ad esempio _docs_staging
, ed includerli nella sezione %files
come %doc _docs_staging/*
.
I file di configurazione dovrebbero essere posti in /etc
e sono normalmente specificati così (che preserva le modifiche durante gli aggiornamenti):
%config(noreplace) %{_sysconfdir}/foo.conf
Se l'aggiornamento usa un formato di configurazione non-retrocompatibile, specificarli così:
%config %{_sysconfdir}/foo.conf
"%attr(mode, user, group)
" può essere usato per controlli più precisi sui permessi, dove "-
" significa usare il predefinito:
%attr(0644, root, root) FOO.BAR
"%caps(capabilities)
" può essere usato per dare certe capacità POSIX ad un file. Ad esempio:
%caps(cap_net_admin=pe) FOO.BAR
Se un file è in lingua naturale, usare %lang
per annotarlo:
%lang(de) %{_datadir}/locale/de/LC_MESSAGES/tcsh*
I programmi che utilizzano file di localizzazione dovrebbero seguire i metodi raccomandati per gestire i file i18n:
- trovare i filename nel passaggio
%install
:%find_lang ${name}
- aggiungere le dipendenze per la costruzione richieste:
BuildRequires: gettext
- usare i filename trovati:
%files -f ${name}.lang
%readme
non è valido in Fedora.
%files e Filesystem Hierarchy Standard (FHS)
Riferimento a Filesystem Hierarchy Standard (FHS).
Gli eseguibili vanno in /usr/bin
, i file di configurazione globali vanno in /etc
, le librerie in /usr/lib
(o /usr/lib64
) e così via. C'é un'eccezione: eseguibili non eseguiti normalmente direttamente dall'utente o dall'amministratore dovrebbero andare nella sottocartella di /usr/libexec
, denominata con %{_libexecdir}/%{name}
.
Non installare file in /opt
o in /usr/local
.
Sfortunatamente molt programmi non rispettano la FHS. In particolare, librerie indipendenti dall'architettura vengono inserite in /usr/lib
invece di /usr/share
. Il primo è per librerie diendenti dall'architettura, mentre il secondo è per quelle indipendenti; significa che i sistemi con differenti architetture di CPU possono condividere la /usr/share
. Ci sono molte eccezioni in Fedora (Python e Perl), ma Fedora applica queste regole più rigidamente rispetto ad alcune altre distro. rpmlint
generalmente segnala se si mette qualcosa di diverso dai file ELF in /usr/lib
.
Esempio di %files
Di seguito un esempio di sezione %files:
%files %doc README %license LICENSE COPYING %{_bindir}/* %{_sbindir}/* %{_datadir}/%{name}/ %config(noreplace) %{_sysconfdir}/*.conf
Trovare duplicati
Per listare qualsiasi duplicato di un rpm:
cd ~/rpmbuild/RPMS/ARCH # Substitute "ARCH" for your architecture rpm -qlp PACKAGE1.*.rpm | sort > ,1 rpm -qlp PACKAGE2.*.rpm | sort > ,2 comm -12 ,1 ,2
Scriptlet
Quando un utente installa l'rpm, si consigliano alcuni comandi da eseguire. Questo si può ottenere con gli scriptlet. Vedi Packaging/ScriptletSnippets.
Gli scriptlet si eseguono:
- prima (
%pre
) o dopo (%post
) l'installazione di un pacchetto - prima (
%preun
) o dopo (%postun
) la disinstallazione di un pacchetto - all'avvìo (
%pretrans
) o alla fine (%posttrans
) di una transazione
Per esempio, ogni rpm binario che immagazzina file di librerie condivise in qualsiasi percorso di dynamic linker, deve richiamare ldconfig
in %post
e %postun
. Se il pacchetto ha molti sottopacchetti con librerie, ognuno di essi dovrebbe fare la stessa cosa.
%post -p /sbin/ldconfig %postun -p /sbin/ldconfig
Se si esegue un solo comando, l'opzione "-p
" avvìa il comando adiacente senza invocare la shell. Tuttavia, per diversi comandi, ometterla e aggiungere tutti i comandi shell.
Se si avvìa un programma negli scriptlet, qualsiasi richiesta va specificata nella forma "Requires(CONTEXT)
" (ad esempio Requires(post)
).
%pre
, %post
, %preun
e %postun
forniscono l'argomento $1
, che è il numero di pacchetti di questo nome che saranno lasciati nel sistema. Non confrontare per uguaglianza con 2
, controlla invece se sono meggiori o uguali a 2
. Per %pretrans
e %posttrans
, $1
è sempre 0
.
Per esempio se il pacchetto installa un manuale il quale indice deve essere aggiornato con install-info
dal pacchetto info
, innanzitutto non è garantita la presenza del pacchetto info
senza una sua richiesta specifica e poi non si può fallire completamente se install-info
non funziona:
Requires(post): info Requires(preun): info ... %post /sbin/install-info %{_infodir}/%{name}.info %{_infodir}/dir || : %preun if [ $1 = 0 ] ; then /sbin/install-info --delete %{_infodir}/%{name}.info %{_infodir}/dir || : fi
Esiste un altro problema tecnico relativo all'installazione dei manuali. Il comando install-info
aggiornerà la certella delle informazioni, quindi si dovrebbero cancellare le cartelle vuote inutilizzate da %{buildroot} durante la sezione %install
:
rm -f %{buildroot}%{_infodir}/dir
Un'altra abilità simile agli scriptlet è "trigger", avviabile quando altri pacchetti sono installati o disinstallati. Vedi RPM Triggers.
Macro
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 ".fc40 ")
|
%{fedora} |
NUMBER |
Numero di rilascio di Fedora (e.g. "40 ")
|
%{_includedir} |
/usr/include
| |
%{_infodir} |
/usr/share/info
| |
%{_initrddir} |
/etc/rc.d/init.d
| |
%{_libdir} |
/usr/lib
| |
%{_libexecdir} |
/usr/libexec
| |
%{_localstatedir} |
/var
| |
%{_mandir} |
/usr/share/man
| |
%{name} |
Name of 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
Vedere anche Packaging/RPMMacros e RPM Guide capitolo 9.
Altri tag
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 paccehtto.
- Conflicts: specifica quali altri pacchetti non possono essere installati simultaneamente a quello in oggetto. Evitarlo se possibile. Vedere Packaging/Conflicts.
- 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.
Architetture valide sono listate in Architectures.
Subpackage
Uno SPEC file può definire diversi binari. In altre parole, un SRPM con uno SPEC file può risultare in più RPM. Notare che c'é ancora un solo processo di creazione (%prep, %build, %install etc.). Sottopacchetti name-doc
e name-devel
sono comuni per la documentazionee i file di sviluppo rispettivamente.
Usare la direttiva %package
per iniziare la definizione di un sottopacchetto:
%package subpackage_name
Dopo ogni direttiva %package
, listarne i tag. Dovrebbe almeno includere i tag Summary e Group, oltre a %description subpackage_name
e %files subpackage_name
:
Tutto quanto non specificato dal sottopacchetto sarà ereditato dal suo genitore.
Come predefinito, se il nome del pacchetto è "foo
" e quello del sottopacchetto è "bar
", allora i nomi risultanti saranno foo-bar
". E' possibile evitarlo con l'opzione "-n
" (ma servirà usarlo in tutte le altre direttive una volta qui specificato):
%package -n new_subpackage_name
Leggere la sezione sui sottopacchetti della Guida RPM per maggiori informazioni.
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
".
Linee guida specifiche
Ci sono molte linee guida specifiche che sono di aiuto (ad esempio per i linguaggi di programmazione specifici, per applicazioni, librerie e sistemi di build). Molte di loro sono elencate come parte delle Application Specific Guidelines of Packaging/Guidelines. Esempi di linee guida:
Altre sono:
- Il comando 'SEARCH' di Fedoraproject.org.
- PackagingDrafts
- Special Interest Group (SIG)
- Pagine Wiki con prefisso 'Packaging'
Suggerimenti vari
Packaging/FrequentlyMadeMistakes contiene informazioni sugli errori più comuni commessi. Ci sono anche altre raccomandazioni e trucchi controversi in PackageMaintainers/Packaging Tricks.
Provare a scrivere i propri .sepc files così da funzonare quando nuove versioni dall'upstream sono pronte, senza nessuna modifica a parte il numero di versione e l'aggiornamento dei sorgenti. Per esempio, se contiene file *.txt con istruzioni d'esecuzione, invece di fare
chmod a-x Filename1.txt Filename2.txt Filename3.txt
considerare comandi come il seguente:
chmod a-x *.txt
Se si vogliono vedere un sacco di esempi di scriptlet, è possibile mostrarli tutti dai pacchetti installati con:
rpm -qa --queryformat "\n\nPACKAGE: %{name}\n" --scripts | less
Non cercare di interagire con l'utente; RPM è designato per supportare tante installazioni. Se un'applicazione necessita di mostrare 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. Se si installa uno script init e systemd, considerare l'uso di chkconfig
o 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:
%global _enable_debug_package 0 %global debug_package %{nil} %global __os_install_post /usr/lib/rpm/brp-compress %{nil}
mentre nella sezione %install
:
export DONT_STRIP=1
Un modo per controllare la versione di Fedora in uno .spec file per i build condizionali è:
%if 0%{?fedora} <= <version>
Il ?
permette il riconoscimento della versione se %fedora
non è definito. Fa sì che il risultato finale sia 0
, pur non interferendo sul risultato se presente un valore per %fedora
. (Notare che questo metodo non funziona nelle build "scratch" in Koji, dove %fedora
è impostato durante la creazione di un SRPM.)
Le GUI devono avere una voce desktop così da permetterne l'uso dal menu grafico. Per i file .desktop
, vedere Fedora packaging guidelines for desktop files e desktop entry spec. Per le icone in /usr/share/icons
, vedere icon theme spec.
Costruzione del pacchetto binario
Test con rpmlint
Prima di provare a costruire qualsiasi cosa, si dovrebbe eseguire rpmlint
sullo spec file:
$ rpmlint program.spec
Troverà molti errori velocemente. Se l'errore riportato non ha molto senso, ridare lo stesso comando aggiungendo l'opzione "-i" (questo darà maggiori informazioni).
L'ideale sarebbe quello d'avere il minor numero di errori, ma talvolta rpmlint riporta dei falsi positivi. Le linee guida Fedora packaging spiega quali sono da ignorare.
Creazione degli RPM dallo spec file
Una volta creato uno spec file, chiamato program.spec, è possibile creare l'rpm sorgente e l'rpm binario semplicemente avviando:
$ rpmbuild -ba program.spec
Se funziona, i file binari RPM verranno creati nella sottocartella ~/rpmbuild/RPMS/ e l'RPM sorgente in ~/rpmbuild/SRPMS.
Quando qualcosa va male, è possibile entrare ("cd") nella directory appropriata e vedere cosa contiene. Se si vogliono saltare i passaggi precedenti, usare l'opzione "--short-circuit"; è utile quando si è avuto un build con successo, ma si ha un errore nella sezione %install. Ad esempio, per reiniziare lo stage %install (saltando i passaggi precedenti):
$ rpmbuild -bi --short-circuit program.spec
Se si vuole creare l'rpm sorgente (.src.rpm), entrare nella cartella SPECS e:
$ rpmbuild -bs program.spec
Verrà creato l'rpm sorgente nella cartella ~/rpmbuild/SRPMS. Creare solo l'rpm sorgente è abbastanza veloce, poiché non fa altro che associare lo .spec file e i file SOURCES nel .src.rpm . Creare un rpm binario tipicamente prende più tempo perché richiede l'avvìo degli script %prep, %build e %install.
Testare con rpmlint gli RPM creati
Avviato rpmlint sullo spec file, generato l'RPM binario e generato l'RPM sorgente. rpmlint lavora sugli spec, sugli rpm binari o sorgente, trovando cose differenti in ognuno. E' necessario eliminare o modificare degli "rpmlint warning" prima di rilasciare un pacchetto. Questa pagina offre spiegazioni per alcuni dei problemi comuni che potrebbero saltare fuori.
Dalla cartella SPECS:
$ rpmlint NAME.spec ../RPMS/*/NAME*.rpm ../SRPMS/NAME*.rpm
Generalmente rpmbuild costruisce rpm binari con informazioni di debug, anche questi possono essere sottoposti al test.
Spostandosi nella cartella "~/rpmbuild/RPMS" poi nella sottocartella denominata dall'architettura (32 o 64 bit) si troveranno alcuni rpm binari. E' possibile vederne facilmente i file ed i permessi con rpmls (assicurarsi di trovare ciò che ci si aspetta):
$ rpmls *.rpm
Se corretti, provare ad installarli diventando root:
$ su # rpm -ivp package1.rpm package2.rpm package3.rpm ...
Per poi testarli, utilizzandoli in differenti modi. Se si decide di usare uno strumento ad interfaccia grafica (GUI), assicurarsi che venga mostrato nel menu (se non lo è, allora qualcosa è sbagliato alla voce .desktop).
Successivamente è possibile disinstallarli:
# rpm -e package1 package2 package3
Mock and Koji
Mock è un potente tool che usa gli SRPM creati per costruire pacchetti binari all'interno di un ambiente appositamente creato. Questo può essere d'aiuto per la rilevazione delle dipendenze tra pacchetti. Se fallisce, potrebbe mancare qualcosa alla voce BuildRequires. Vedere Using Mock to test package builds per ulteriori info sull'utilizzo di mock
; una volta che il proprio account rientra nel gruppo "mock
", è possibile avviare comandi come il seguente per eseguire test in locale:
$ mock -r fedora-9-i386 rebuild path_to_source_RPM
Una volta che Mock ha funzionato correttamente, si può usare Koji (il quale usa Mock) per costruire in differenti sistemi. PackageMaintainers/Join e PackageMaintainers/UsingKoji hanno molte informazioni su Koji. Una volta settati, si possono eseguire test sul proprio rpm sorgente con differenti sistemi
$ koji build --scratch dist-f9 path_to_source_RPM
Si può sostituire la voce "%fc9
" con qualsiasi altra release successiva di Fedora, ma non usare dist-rawhide
. Ricordarsi che i valori di %fedora
, %fc9, ... non saranno giusti per una scratch build, quindi non funzioneranno se il proprio .spec file fa qualcosa di diverso basato su quei valori.
I build koji possono solo dipendere dai pacchetti che sono attualmente disponibili nei repository TARGET. Quindi non si può usare Koji per costruire per distribuzioni rilasciate se il proprio pacchetto dipende da altri nuovi pacchetti che Bodhi non ha ancora rilasciato.
Se si vuole costruire un pacchetto che non è ancora una versione aggiornata stabile, presentare una richiesta "buildroot override" via Bodhi. Se il pacchetto non è a proprio carico, contattare il/i maintainer. [Prima dell'attuale metodo che prevede una richiesta "buildroot override", si poteva aprire un ticket con rel-eng a https://fedorahosted.org/rel-eng/newticket e chiedere che il pacchetto venisse aggiunto come buildroot override]
Strumenti utili
Il pacchetto rpmdevtools
fornisce diversi strumenti utili; "rpm -qil rpmdevtools
" mostra ciò che verrà installato.
rpmdev-bumpspec : dal tag release dello spec file, aggiunge un commento al changelog con la data e la versione del software:
$ rpmdev-bumpspec --comment=COMMENT --userstring=NAME+EMAIL_STRING SPECFILES
DNF download plugin (dal core DNF plugins) contiene molti strumenti utili:
dnf download
: scarica il pacchetto sorgente
$ dnf download --source PACKAGENAME
Il pacchetto auto-buildrequires
ha un paio di buoni strumenti d'aiuto per configurare correttamente la voce BuildRequires. Dopo averlo installato, rimpiazzare "rpmbuild
" con "auto-br-rpmbuild
" e si vedrà automaticamente generata la lista buildrequires.
Potrebbe essere utile RUST (GPL), anche se non crea rpm di adeguata qualità per i repository Fedora. Alien converte pacchetti di diverso formato. Non produce rpm sorgente puliti ma potrebbe essere utile per la conversione di pacchetti esistenti dai quali trarre informazioni preziose.
Se si ha intenzione di creare un pacchetto RPM per Fedora, assicurarsi di sottoporre il proprio file ad una Fedora Review, che aiuta a garantire che ci si attenga alle Linee-guida sul Packaging.
Finalmente, docker-rpm-builder (APL 2.0) usa Docker per costruire i pacchetti RPM; mentre l'uso di 'rpmbuild' richiede di lavorare nella stessa distro del target, e 'mock' funziona bene su distribuzioni Fedora/Centos/RHEL per qualsiasi target, quest'ultimo strumento lavora con Docker.
Se si preferisce costruire RPM per altre distribuzioni o architetture avendo accesso pubblico ai repository, è possibile usare Copr.
Per firmare il pacchetto, usare rpmsign
.
Linee guida e regole
Una volta creato il proprio pacchetto, bisogna seguire queste regole e linee guida:
- How to join the Fedora Package Collection Maintainers - Descrive il processo per diventare Fedora package maintainer
- Packaging Guidelines
- Package Naming Guidelines
- Dist Tag Guidelines
- Package Review Guidelines
Ci sono molte linee guida ufficiali che possono essere d'aiuto in circostanze particolari (Java programs, OCaml programs, GNOME programs, etc.). Si può inoltre imparare molto dalle sezioni SIGs e Package Maintainers. Lista delle pagine wiki sul Packaging.
Inoltre, si potrebbero trovare utili quelle non ufficiali Packaging Drafts e Packaging Drafts To Do.
Si potrebbero trovare spunti da SuSE, Debian, ma ci sono differenze tra le distribuzioni, quindi si presume che non possono essere usate direttamente.
I file .spec creati devono riguardare software opensource come previsto dal FPCA.
Mantenimento del pacchetto
Quando il pacchetto viene accettato, dev'essere mantenuto dal maintainer (o dal co-maintainer). Vedere Package update HOWTO e Package update guidelines per maggiori informazioni. Se si aggiorna a più di una release Fedora, farlo a ritroso nel tempo; ad esempio, release per Fedora N, una volta accettato, Fedora N -1 ( il sistema presuppone che versioni successive di Fedora hanno versioni uguali o più aggiornate dei programmi).
Incoraggiare gli sviluppatori upstream ad usare convenzioni stardard nel rilascio del codice sorgente; questo renderà più facile il packaging del software. Per maggiori informazioni, vedere:
- Releasing Free/Libre/Open Source Software (FLOSS) for Source Installation (sommario veloce)
- GNU Coding Standards release process
- Software Release Practice HOWTO
- Filesystem Hierarchy Standard (FHS)
- Packaging Unix software
Per maggiori informazioni
La pagina Package Maintainers è collegata a molte altre pagine utili e Package update HOWTO descrive come aggiornare un pacchetto esistente già mantenuto in Fedora.
Per maggiori informazioni, fuori dal wiki Fedora, vedere:
- How to build RPM packages on Fedora - ripasso veloce
- Packaging software con RPM (developerWorks) Part 1, Part 2 e Part 3
- Fedora Classroom ha avuto una sessione IRC sul packaging e si può far riferimento al log su https://fedoraproject.org/wiki/Building_RPM_packages_%2820090405%29
- Manuale Fedora Packager
- When Sally met Eddie - Un semplice testo con pochi dettagli
- Maximum RPM Book - Molte informazioni complete, ma in alcuni casi obsolete
- RPM Guide, section on creating RPMs - Ha parecchie buone informazioni leggermente più aggiornate, ma è una bozza
- Guida per sviluppatori, sezione building RPM
- Creating RPMS slides da Guru Labs
- La lotta, il mio primo tentativo di fare un'introduzione leggibile sull'rpm building.
- RPM Tutorial (Fullhart)
- Cambridge RPM tutorial è una presentazione sulla creazione basilare degli RPM
- [1] RPM HOWTO: RPM al Minimo di Donnie Barnes
- [2] RPM HowTo di Dawson
- SuSE build tutorial - ma su SuSE, non per Fedora. Cross-distribution package HOWTO contiene suggerimenti se si fanno rpm per diverse distribuzioni.
- Mandriva Rpm HowTo (en) (alt) è un tutorial RPM anche se per Mandriva. Da notare che in Fedora non si ricomprimono i tarball originali, come Mandriva suggerisce, perché questo avrebbe cambiato le loro hash crittografate.
- Creazione del proprio Linux RPM - Software Building Iniziale è un'altra introduzione ma fa il punto su "Il processo per costruire RPM è più facile della creazione dei pacchetti per Solaris... Meno passaggi, e l'abilità di aggiungere tutte le informazioni sul software in uno specifico file, fatti per una maggiore essenzialità (più facile da modificare e riprodurre) del sistema di packaging".
- Tutto ciò che bisogna sapere su RPM (più sull'installazione che sulla creazione)
- The rpm.org Wiki ha alcune informazioni utili, come la lista dei problemi conosciuti
Da notare: il sito rpm5.org ha alcuni documenti ma non dipende da loro; è la casa di un fork di RPM mantenuto da Jeff Johnson. L'RPM usato da Fedora (e da Novell/SuSE) ha invece la sede in rpm.org.
lwn.net contiene un articolo a riguardo.