Post on 18-Nov-2014
description
transcript
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: