Introduzione al packaging RPM

Gianluca SfornaFedora 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.

Pacchi e pacchetti

Roma, 5 Marzo 2011

RingraziamentiOrganizzatori, Speaker, Sponsor

Tom 'spot' Callaway (presentazione originale)

Cosa è RPMsia formato che gestore pacchetti

basato su database

traccia dipendenze

verifica dei pacchetti

incluso in LSB

usato da Red Hat Enterprise Linux, Fedora e altri

Image CC-BYhttp://www.flickr.com/photos/leecannon/4832542876

Perchè pacchettiziamostandardizza deployment

sicuro di averlo installato

semplifica l'ambiente

sicuro di come trovarlo

gestione conformità

sicuro di cosa è presente

Miti da sfatarenon funziona molto bene

difficile creare pacchetti

difficile installare pacchetti

difficile rimuovere pacchetti

incubi da dipendenze

dependency hellImage CC-BY

http://www.flickr.com/photos/miheco/2167149428/

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!

Il nodo dipendenzele dipendenze sono utili

ma possono diventare un problema

yum risolve il problema

metadati estratti dai pacchetti

yum usa i metadati per risolvere le dipendenze

installa il necessario, rimuove quello che non serve più

Image CC-BYhttp://www.flickr.com/photos/psyberartist/3483489839/

Packaging come normacontrollo utilizzo del software

cosa, dove, quando?

controllo versione

integrazione kickstart

minimizzazione rischi

sicurezza

applicazioni indesiderate

licenza

Concetti base RPMpacchetto binario: goldfish-1.0.0-1.i386.rpm

goldfish - nome

1.0.0 - versione

1 – release

i386 - architettura

Operazioniinstallazione => 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

Source RPM (SRPM)pacchetto sorgentegoldfish-1.0.0-1.src.rpm

gli SRPM contengono tutto il necessario per generare i pacchetti RPM binari

file spec

sorgenti (tar.gz)

patch

Operazioni SRPMinstallazione => nome del file SRPM

rpm -ivh goldfish-1.0.0-1.src.rpm

i files finiscono nella source directoryRed Hat default:

/usr/src/redhat/SOURCES

SRPM non entrano del database RPM

rimozione => spec file name

rpmbuild --rmsource --rmspec goldfish.spec

Dai sorgenti al binariocreazione 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

Regola zero

MAIcompilare RPM

come root

Build da utentecreare ambiente di build nella propria homemkdir -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')

MacroSimili 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})

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

Preparare un RPMil 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-SAhttp://www.flickr.com/photos/ted_major/5045483028

Anatomia di uno specpreambolo

%prep (setup)

%build

%install

%clean

%files

%changelog

Image CC-BYhttp://www.flickr.com/photos/27620885@N02/2671077524/

spec file: preambolosezione iniziale

proprietà del pacchetto

Name/Version/Group/License

Release (revisione del pacchetto)

Source/Patch

Require (dipendenze)compilazione e installazione

Summary/Description

definizione macro locali

Esempio di preamboloName: helloworldVersion: 1.1Release: 3Summary: An application that prints “Hello World!”License: GPLv2+Group: System Environment/BaseSource0: http://helloworld.com/helloworld-1.1.tar.gzPatch0: fixtypo.patchBuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)BuildArch: noarch

%descriptionThis 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.

spec file: setupCreazione albero sorgenti

Scompattazione sorgenti

Applicazione patch

Eventuali comandi pre-build

Esempio di setup%prep%setup -q%patch0 -p1

spec file: buildcreazione componenti binarie

macro %configure

utile per progetti basati su autotools

esegue ./configure con sane opzioni di default

esempio %build%build%configuremake %{?_smp_mflags}

da adattare a seconda del metodo di build usato (scons, cmake, etc) dal progetto

spec file: installcreazione della buildroot

preparazione struttura del filesystem

copia dei file compilati nella buildroot

eventuale pulizia file installati non necessari

esempio %install%installrm -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

spec file: clean & filesclean 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

esempio %clean e %files%cleanrm -rf %{buildroot}

%files%defattr(-,root,root,-)%attr(0755,gold,fish) %{_bindir}/helloworld

spec file: changelogusato 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

Best PracticesK.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

Altre Best Practicesusare 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.

Errori di inesperienzageneratori 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...

Link utiliLinee 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

Domande?

http://morefedora.blogspot.comgiallu@fedoraproject.org@giallu su identi.ca e twitter

Contatti: