Introduzione al packaging RPM

1. Roma, 5 Marzo 2011
Pacchi e pacchetti
Introduzione al packaging RPM
Gianluca Sforna
Fedora Project contributor
Questa presentazione è disponibile con la licenza Creative Commons Attribution-ShareAlike (BY-SA) 3.0
ad eccezione dei logo e dei trademark Red Hat e Fedora, usati con permesso.

2. Ringraziamenti
Organizzatori, Speaker, Sponsor
Tom 'spot' Callaway (presentazione originale)

3. Cosa è RPM
sia formato che gestore
pacchetti
basato su database
traccia dipendenze
verifica dei pacchetti
Image CC-BY
http://www.flickr.com/photos/leecannon/4832542876
incluso in LSB
usato da Red Hat Enterprise
Linux, Fedora e altri

4. Perchè pacchettiziamo
standardizza deployment
sicuro di averlo installato
semplifica l'ambiente
sicuro di come trovarlo
gestione conformità
sicuro di cosa è presente

5. Miti da sfatare
non funziona molto bene
difficile creare pacchetti
difficile installare pacchetti
difficile rimuovere pacchetti
incubi da dipendenze
dependency hell
Image CC-BY
http://www.flickr.com/photos/miheco/2167149428/

6. Il mostro non esiste!
RPM è spesso sottovalutato
funziona molto bene
creare pacchetti è più facile
di ciò che si crede
facili da installare...
facili da rimuovere...
... se sono fatti bene!

7. Il nodo dipendenze
le dipendenze sono utili
ma possono diventare un
problema
yum risolve il problema
metadati estratti dai pacchetti
yum usa i metadati per
Image CC-BY
http://www.flickr.com/photos/psyberartist/3483489839/
risolvere le dipendenze
installa il necessario, rimuove
quello che non serve più

8. Packaging come norma
controllo utilizzo del software
cosa, dove, quando?
controllo versione
integrazione kickstart
minimizzazione rischi
sicurezza
applicazioni indesiderate
licenza

9. Concetti base RPM
pacchetto binario:
goldfish-1.0.0-1.i386.rpm
goldfish - nome
1.0.0 - versione
1 – release
i386 - architettura

10. Operazioni
installazione => nome del file
rpm -ivh goldfish-1.0.0-1.i386.rpm
i: install, v: verbose, h: mostra hash (#)
interrogazione => nome pacchetto
rpm -ql goldfish
q: query, l: list files
rimozione => nome pacchetto
rpm -e goldfish
e: erase

11. Source RPM (SRPM)
pacchetto sorgente
goldfish-1.0.0-1.src.rpm
gli SRPM contengono
tutto il necessario per
generare i pacchetti RPM
binari
file spec
sorgenti (tar.gz)
patch

12. Operazioni SRPM
installazione => nome del file SRPM
rpm -ivh goldfish-1.0.0-1.src.rpm
i files finiscono nella source directory
Red Hat default:
/usr/src/redhat/SOURCES
SRPM non entrano del database RPM
rimozione => spec file name
rpmbuild --rmsource --rmspec goldfish.spec

13. Dai sorgenti al binario
creazione dei pacchetti binari dal SRPM:
rpmbuild --rebuild goldfish-1.0.0-1.src.rpm
creazione rpm dal file spec
rpmbuild -ba goldfish.spec
-b: build, -a: all packages (src e binari)
i sorgenti con le patch applicate vanno nella
"builddir"
Red Hat default:
/usr/src/redhat/BUILD

14. Regola zero
MAI
compilare RPM
come root

15. Build da utente
creare ambiente di build nella propria home
mkdir -p ~/rpmbuild/
{BUILD,BUILDROOT,RPMS,SOURCES,SPECS,SRPMS}
mkdir -p ~/rpmbuild/RPMS/{noarch,i386,i686}
aggiungere in ~/.rpmmacros:
%_topdir %(echo $HOME)/rpmbuild
in Fedora, lo stesso risultato si ottiene col
comando 'rpmdev-setuptree' (presente in
'rpmdevtools')

16. Macro
Simili alle variabili negli script shell
possono comportarsi da stringhe o interi ma è più
semplice trattarle sempre da stringhe
le più comuni macro sono già definite
rpm --showrc mostra tutte le macro definite
rpm --eval %{macroname} mostra l'espansione
della macro
quasi tutte le macro di sistema inziano con _
(es. %{_bindir})

17. Macro utente
~/.rpmmacros
permette di avere macro specifiche per utente
attenzione se si usano nello spec
le macro definite per utente non saranno presenti
in altri sistemi

18. Preparare un RPM
il file spec è come una ricetta
simile ad uno script shell
elenca i contenuti dell'RPM
sorgenti
patch
altri file
descrive il processo di build
Image CC-BY-SA
http://www.flickr.com/photos/ted_major/5045483028

19. Anatomia di uno spec
preambolo
%prep (setup)
%build
%install
%clean Image CC-BY
http://www.flickr.com/photos/27620885@N02/2671077524/
%files
%changelog

20. spec file: preambolo
sezione iniziale
proprietà del pacchetto
Name/Version/Group/License
Release (revisione del pacchetto)
Source/Patch
Require (dipendenze)
compilazione e installazione
Summary/Description
definizione macro locali

21. Esempio di preambolo
Name: helloworld
Version: 1.1
Release: 3
Summary: An application that prints “Hello World!”
License: GPLv2+
Group: System Environment/Base
Source0: http://helloworld.com/helloworld-1.1.tar.gz
Patch0: fixtypo.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
%description
This program prints hello world on the screen to avoid the “programmers
curse”. The Programmmers Curse states that unless your first example is
“Hello World!”, then you will be cursed, and never able to use that tool.

22. spec file: setup
Creazione albero sorgenti
Scompattazione sorgenti
Applicazione patch
Eventuali comandi pre-build
Esempio di setup
%prep
%setup -q
%patch0 -p1

23. spec file: build
creazione componenti binarie
macro %configure
utile per progetti basati su autotools
esegue ./configure con sane opzioni di default

24. esempio %build
%build
%configure
make %{?_smp_mflags}
da adattare a seconda del metodo di build
usato (scons, cmake, etc) dal progetto

25. spec file: install
creazione della buildroot
preparazione struttura del filesystem
copia dei file compilati nella buildroot
eventuale pulizia file installati non necessari

26. esempio %install
%install
rm -rf %{buildroot}
mkdir -p %{buildroot}%{_bindir}
cp helloworld.sh %{buildroot}%{_bindir}/helloworld
%{_bindir}
macro che espande a /usr/bin.
%{buildroot}
directory in cui vengono installati i files prima di
essere copiati negli RPM binari
definita nel preambolo

27. spec file: clean & files
clean cancella la buildroot
files: elenca il contenuto del
pacchetto
se non appare in %files, non c'è
nel pacchetto
RPM si fermerà in presenza di
file non pacchettizzati
MAI cercare di aggirare il controllo

28. esempio %clean e %files
%clean
rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
%attr(0755,gold,fish) %{_bindir}/helloworld

29. spec file: changelog
usato per annotare i cambiamenti al pacchetto
non è una alternativa al changelog dei sorgenti
da aggiornare ad OGNI cambiamento
esempio di sezione %changelog:
%changelog
* Mon Jun 2 2008 Gianluca Sforna <giallu@gmail.com> 1.1-3
- minor example changes
* Mon Apr 16 2007 Gianluca Sforna <giallu@gmail.com> 1.1-2
- update example package
* Sun May 14 2006 Gianluca Sforna <giallu@gmail.com> 1.1-1
- initial package

30. Best Practices
K.I.S.S.
una patch per ogni modifica
evitare pre/post quando possibile
usare sempre il changelog
ispirarsi a pacchetti Fedora
usare macro (correttamente)
essere coerenti
preferire macro di sistema

31. Altre Best Practices
usare rpmlint, correggere gli errori
segnalati
includere config/script come files
(Source#)
Commenti!
...ma che lo spec rimanga leggibile
pensare a chi dovrà lavorare al
pacchetto dopo di noi.
MAI eseguire rpm da uno spec file
come in Ghostbusters.
Incrociare i flussi? male.

32. Errori di inesperienza
generatori di pacchetti
"funziona" non è lo stesso di
"fatto bene"
pacchettizzare binari, non
partendo dai sorgenti
non sempre evitabile, ma potendo
scegliere meglio non farlo
disattivare controllo file non
pacchettizzati
solo se si è in cerca di guai...

33. Link utili
Linee guida per il packaging:
http://fedoraproject.org/wiki/Packaging:Guidelines
http://fedoraproject.org/wiki/Packaging:ReviewGuidelines
Maximum RPM:
http://rpm.org/max-rpm-snapshot/
Fedora GIT Tree (contiene migliaia di spec)
http://pkgs.fedoraproject.org/gitweb/
Rpmlint website:
http://rpmlint.zarb.org

34. Domande?
Contatti:
http://morefedora.blogspot.com
giallu@fedoraproject.org
@giallu su identi.ca e twitter