Pacchi e pacchetti
Upcoming SlideShare
Loading in...5
×
 

Pacchi e pacchetti

on

  • 1,947 views

Introduzione al packaging RPM

Introduzione al packaging RPM

Statistics

Views

Total Views
1,947
Views on SlideShare
1,716
Embed Views
231

Actions

Likes
0
Downloads
16
Comments
0

12 Embeds 231

http://morefedora.blogspot.com 129
http://www.fedora-it.org 25
http://www.codemotion.it 23
http://morefedora.blogspot.it 18
http://2011.codemotion.it 17
http://feeds2.feedburner.com 8
http://planet.fedoraonline.it 4
http://mariotuxbox 2
http://codemotion.macaronilab.com 2
url_unknown 1
http://www.slideshare.net 1
http://feeds.feedburner.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-ShareAlike LicenseCC Attribution-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Con il file ~/.rpmmacros è possibile

Pacchi e pacchetti Pacchi e pacchetti Presentation Transcript

  • 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.
  • Ringraziamenti Organizzatori, Speaker, Sponsor Tom spot Callaway (presentazione originale)
  • 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
  • Perchè pacchettiziamo standardizza deployment sicuro di averlo installato semplifica lambiente sicuro di come trovarlo gestione conformità sicuro di cosa è presente
  • 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/
  • 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 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ù
  • Packaging come norma controllo 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
  • 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
  • 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
  • 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
  • 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
  • Regola zero MAI compilare RPM come root
  • 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)
  • 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 lespansione 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 RPM il file spec è come una ricetta simile ad uno script shell elenca i contenuti dellRPM sorgenti patch altri file descrive il processo di build Image CC-BY-SA http://www.flickr.com/photos/ted_major/5045483028
  • Anatomia di uno spec preambolo %prep (setup) %build %install %clean Image CC-BY http://www.flickr.com/photos/27620885@N02/2671077524/ %files %changelog
  • 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
  • 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 “programmerscurse”. 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: setup Creazione albero sorgenti Scompattazione sorgenti Applicazione patch Eventuali comandi pre-buildEsempio di setup%prep%setup -q%patch0 -p1
  • spec file: build creazione componenti binarie macro %configure utile per progetti basati su autotools esegue ./configure con sane opzioni di default
  • esempio %build %build %configure make %{?_smp_mflags} da adattare a seconda del metodo di build usato (scons, cmake, etc) dal progetto
  • spec file: install creazione 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 & 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
  • esempio %clean e %files %clean rm -rf %{buildroot} %files %defattr(-,root,root,-) %attr(0755,gold,fish) %{_bindir}/helloworld
  • 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
  • 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
  • Altre Best Practicesusare rpmlint, correggere gli errorisegnalatiincludere 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 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...
  • Link utiliLinee guida per il packaging: http://fedoraproject.org/wiki/Packaging:Guidelines http://fedoraproject.org/wiki/Packaging:ReviewGuidelinesMaximum 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?Contatti:http://morefedora.blogspot.comgiallu@fedoraproject.org@giallu su identi.ca e twitter