RPM HOWTO (RPM at Idle)
Donnie Barnes,
[email protected]. Svensk �vers�ttning: Linus
�kerlund,
[email protected]
v2.0, 8 April 1997. Svensk �vers�ttning: 8 juni 1998.
____________________________________________________________
Inneh�llsf�rteckning
1. Inledning
2. �versikt
3. Grundl�ggande information
3.1 Skaffa RPM
3.2 RPM-krav
4. Anv�nda RPM
5. Okej, vad kan jag
6. Skapa RPM-paket
6.1 rpmrc-filen
6.2 Spec-filen
6.3 Rubrik-delen
6.4 Prep
6.5 Build
6.6 Install
6.7 Valfria skal-program som k�rs f�re eller efter installering/avinstallering
6.8 Files
6.9 Bygga paketet
6.9.1 K�llkodens katalog-tr�d
6.9.2 Test-bygga
6.9.3 Skapa fil-listan
6.9.4 Skapa paketet med RPM
6.10 Testa det
6.11 Vad du ska g�ra med dina nya RPM-paket
6.12 Och nu d�?
7. RPM-skapande f�r flera arkitekturer
7.1 Exempel p� spec-filer
7.2 Opt-flaggor
7.3 Makron
7.4 Utesluta arkitekturer fr�n paket
7.5 Avslutning
8. Upphovsr�tt
______________________________________________________________________
1. Inledning
RPM st�r f�r Red Hat Package Manager (Red Hat paket-
hanterare.�vers.anm). �ven om namnet inneh�ller Red Hat, s� �r RPM
helt och h�llet avsett att vara ett �ppet paket-system, tillg�ngligt
f�r alla. Det till�ter anv�ndare att ta k�llkoden till ny mjukvara och
paketera det till k�llkods- eller bin�r-format, s� att bin�r-filerna
l�tt kan installeras och sp�ras, och k�llkod l�tt kan kompileras om.
Det administrerar �ven en databas, �ver alla paket och deras filer,
vilken kan anv�ndas f�r att verifiera och "fr�ga" paket efter
information om filer och/eller paket.
Red Hat Software uppmuntrar framst�llare av andra distributioner att
ta sig tid att ta en titt p� RPM, och anv�nda det i sina egna
distributioner. RPM �r ganska flexibelt och l�tt-anv�nt, trots att det
tillhandah�ller en bas f�r ett v�ldigt omfattande system. Det �r �ven
helt och h�llet �ppet och tillg�ngligt, �ven om de uppskattar bugg-
rapporteringar och bugg-fixar. Till�telse ges att anv�nda och
distribuera RPM, utan avgifter, under GPL.
Mer fullst�ndigt dokumentation om RPM �r tillg�nglig i Ed Baileys bok
Maximum RPM. Den �r tillg�nglig f�r nedladdning eller best�llning fr�n
www.redhat.com <
http://www.redhat.com>.
2. �versikt
L�t mig f�rst f�rklara en del av filosofin bakom RPM. Ett design-m�l
var att till�ta anv�ndningen av "of�rd�rvad" k�llkod. Med RPP (v�rt
tidigare system f�r paket-administrering, p� vilket inget i RPM �r
baserat) var v�ra k�llkods-paket "hackade" k�llkoder, som vi byggde
fr�n. Teoretiskt s� var det m�jligt att installera en k�llkods-RPM och
sedan make-a det utan problem. Men k�llkoden var inte den
ursprungliga, och det fanns inga uppgifter om vilka �ndringar vi hade
gjort, f�r att f� den att kompilera. Man var tvungen att ladda ned den
urprungliga k�llkoden separat. Med RPM f�r du of�rd�rvad k�llkod,
tillsammans med en patch, som vi anv�nde f�r att kompilera fr�n. Vi
ser detta som en stor f�rdel. Varf�r? Av flera anledningar. En av dem
�r, att om det kommer en ny version av ett program, s� beh�ver vi inte
b�rja om fr�n b�rjan, f�r att f� det att kompilera under RHL. Du kan
titta p� patchen, f�r att se vad du kan bli tvungen att g�ra. Alla
saker som kompileras in, som standard, �r p� detta s�tt klart synliga.
RPM �r ocks� designat att ha kraftfulla "fr�ge"-m�jligheter. Du kan
leta igenom hela din paket-databas eller bara vissa filer. Du kan
ocks� enkelt ta reda p� vilket paket en fil tillh�r, och var den kom
ifr�n. RPM-filerna sj�lva �r komprimerade arkiv, men du kan fr�ga
individuella paket enkelt och snabbt, p� grund av en standardiserad
bin�r rubrik-fil (header file. �vers.anm.), vilken inneh�ller all
information du n�gon g�ng skulle vilja ha. Denna �r inte komprimerad.
Detta till�ter snabb informations-s�kning.
En annan kraftfull funktion �r m�jligheten att verifiera paket. Om du
�r orolig att du har raderat en fil som �r viktig f�r n�got paket,
verifiera det bara. Du f�r ett meddelande om alla ovanligheter. P�
detta stadium kan du, om det �r n�dv�ndigt, ominstallera paketet.
Eventuella konfigurerings-filer som du har bevaras ocks�.
Vi vill tacka m�nniskorna bakom BOGUS-distributionen f�r m�nga av
deras id�er och koncept, vilka tagits med i RPM. �ven om RPM skrivits
helt och h�llet av Red Hat Software, s� �r dess funktion baserad p�
kod som skrivits av BOGUS (PM och PMS).
3. Grundl�ggande information
3.1. Skaffa RPM
Det b�sta s�ttet att skaffa RPM �r att installera Red Hat Linux. Om du
inte vill g�ra det, s� kan du fortfarande skaffa och anv�nda RPM. Du
kan h�mta det fr�nftp.redhat.com
<
ftp://ftp.redhat.com/pub/redhat/code/rpm>.
3.2. RPM-krav
Huvud-kravet f�r att kunna k�ra RPM �r att du har cpio 2.4.2 eller
senare. �ven om det h�r systemet �r avsett att anv�ndas med Linux, s�
skulle det mycket v�l g� att konvertera det till andra Unix-system.
Det har faktiskt kompilerats p� SunOS, Solaris, AIX, Irix, AmigaOS och
andra operativ-system. Vi m�ste dock varna dig, f�r bin�r-paketen som
skapats p� en annan Unix-typ kan inte kompileras.
Dessa �r de minimala kraven f�r att installera RPM-paket. F�r att
skapa RPM-paket fr�n k�llkod beh�ver du allt som normalt kr�vs f�r att
kompilera paket, som gcc, make osv.
4. Anv�nda RPM
I dess enklaste form kan RPM anv�ndas f�r att installera paket:
rpm -i foobar-1.0-1.i386.rpm
Det n�st enklaste kommandot �r f�r att avinstallera ett paket:
rpm -e foobar
Ett av de mest komplicerade, men mycket anv�ndbara kommandona, l�ter
dig installera paket via FTP. Om du �r uppkopplat p� n�tet, och vill
installera ett nytt paket, s� �r allt du beh�ver g�ra att specificera
en korrekt URL, t.ex.:
rpm -i
ftp://ftp.pht.com/pub/linux/redhat/rh-2.0-beta/RPMS/foobar-1.0-1.i386.rpm
Observera att RPM nu kommer att fr�ga och/eller installera via FTP.
�ven om dessa kommandon �r enkla, s� kan rpm anv�ndas p� m�nga olika
s�tt, vilket vi ser i Usage-meddelandet:
RPM version 2.3.9
Copyright (C) 1997 - Red Hat Software
This may be freely redistributed under the terms of the GNU Public License
usage: rpm {--help}
rpm {--version}
rpm {--initdb} [--dbpath <dir>]
rpm {--install -i} [-v] [--hash -h] [--percent] [--force] [--test]
[--replacepkgs] [--replacefiles] [--root <dir>]
[--excludedocs] [--includedocs] [--noscripts]
[--rcfile <file>] [--ignorearch] [--dbpath <dir>]
[--prefix <dir>] [--ignoreos] [--nodeps]
[--ftpproxy <host>] [--ftpport <port>]
file1.rpm ... fileN.rpm
rpm {--upgrade -U} [-v] [--hash -h] [--percent] [--force] [--test]
[--oldpackage] [--root <dir>] [--noscripts]
[--excludedocs] [--includedocs] [--rcfile <file>]
[--ignorearch] [--dbpath <dir>] [--prefix <dir>]
[--ftpproxy <host>] [--ftpport <port>]
[--ignoreos] [--nodeps] file1.rpm ... fileN.rpm
rpm {--query -q} [-afpg] [-i] [-l] [-s] [-d] [-c] [-v] [-R]
[--scripts] [--root <dir>] [--rcfile <file>]
[--whatprovides] [--whatrequires] [--requires]
[--ftpuseport] [--ftpproxy <host>] [--ftpport <port>]
[--provides] [--dump] [--dbpath <dir>] [targets]
rpm {--verify -V -y} [-afpg] [--root <dir>] [--rcfile <file>]
[--dbpath <dir>] [--nodeps] [--nofiles] [--noscripts]
[--nomd5] [targets]
rpm {--setperms} [-afpg] [target]
rpm {--setugids} [-afpg] [target]
rpm {--erase -e} [--root <dir>] [--noscripts] [--rcfile <file>]
[--dbpath <dir>] [--nodeps] [--allmatches]
package1 ... packageN
rpm {-b|t}[plciba] [-v] [--short-circuit] [--clean] [--rcfile <file>]
[--sign] [--test] [--timecheck <s>] specfile
rpm {--rebuild} [--rcfile <file>] [-v] source1.rpm ... sourceN.rpm
rpm {--recompile} [--rcfile <file>] [-v] source1.rpm ... sourceN.rpm
rpm {--resign} [--rcfile <file>] package1 package2 ... packageN
rpm {--addsign} [--rcfile <file>] package1 package2 ... packageN
rpm {--checksig -K} [--nopgp] [--nomd5] [--rcfile <file>]
package1 ... packageN
rpm {--rebuilddb} [--rcfile <file>] [--dbpath <dir>]
rpm {--querytags}
Du kan hitta mer detaljer om vad dessa alternativ g�r i man-sidan f�r
RPM.
5. Okej, vad kan jag faktiskt g�ra med RPM?
RPM �r ett mycket anv�ndbart verktyg och, som du ser, s� har det m�nga
m�jligheter. Det b�sta s�ttet att f�rst� dem �r att ta en titt p�
n�gra exempel. Jag tog upp installering och avinstallering ovan, s�
h�r kommer n�gra andra exempel:
� L�t oss s�ga att du, av misstag, raderat n�gra filer, men inte �r
s�ker p� vad du har raderat. Om du ville verifiera hela ditt
system, och se efter vad som fattas, s� skulle du skriva:
rpm -Va
� L�t oss s�ga att du hittar en fil som du inte k�nner igen. F�r att
ta reda p� vilket paket den tillh�r, s� skulle du skriva:
rpm -qf /usr/X11R6/bin/xjewel
Utdatan skulle bli:
xjewel-1.6-1
� Du hittar en ny koules-RPM, men du vet inte vad det �r. F�r att f�
en del information skriver du:
rpm -qpi koules-1.2-2.i386.rpm
Utdatan skulle bli:
Name : koules Distribution: Red Hat Linux Colgate
Version : 1.2 Vendor: Red Hat Software
Release : 2 Build Date: Mon Sep 02 11:59:12 1996
Install date: (none) Build Host: porky.redhat.com
Group : Games Source RPM: koules-1.2-2.src.rpm
Size : 614939
Summary : SVGAlib action game with multiplayer, network, and sound support
Description :
This arcade-style game is novel in conception and excellent in execution.
No shooting, no blood, no guts, no gore. The play is simple, but you
still must develop skill to play. This version uses SVGAlib to
run on a graphics console.
� Vidare vill du se vilka filer som koules-RPM installerar. Du skulle
skriva:
rpm -qpl koules-1.2-2.i386.rpm
Utdatan blir:
/usr/doc/koules
/usr/doc/koules/ANNOUNCE
/usr/doc/koules/BUGS
/usr/doc/koules/COMPILE.OS2
/usr/doc/koules/COPYING
/usr/doc/koules/Card
/usr/doc/koules/ChangeLog
/usr/doc/koules/INSTALLATION
/usr/doc/koules/Icon.xpm
/usr/doc/koules/Icon2.xpm
/usr/doc/koules/Koules.FAQ
/usr/doc/koules/Koules.xpm
/usr/doc/koules/README
/usr/doc/koules/TODO
/usr/games/koules
/usr/games/koules.svga
/usr/games/koules.tcl
/usr/man/man6/koules.svga.6
Dessa �r bara n�gra exempel. Mer kreativa exempel kan du komma p� n�r
du har l�rt k�nna RPM b�ttre.
6. Skapa RPM-paket
Att skapa RPM-paket �r ocks� ganska l�tt, speciellt om du kan f�
mjukvaran som du f�rs�ker g�ra ett paket av att kompilera.
Den grundl�ggande proceduren f�r att skapa ett RPM-paket �r som
f�ljer:
� Se till att /etc/rpmrc �r inst�lld f�r ditt system.
� F� k�llkoden som du ska bygga RPM-paketet f�r att kompilera p� ditt
system.
� G�r en patch med de �ndringar du beh�vde g�ra, f�r att f� k�llkoden
att kompilera ordentligt.
� G�r en specifikations-fil f�r paketet.
� Se till s� att allt �r p� sin plats.
� Skapa paketet med hj�lp av RPM
Under normal anv�ndning skapar RPM b�de bin�r- och k�llkods-paket.
6.1. rpmrc-filen
Som det �r nu, s� �r det enda s�ttet att konfigurera RPM via
/etc/rpmrc-filen. Ett exempel ser ut s� h�r:
require_vendor: 1
distribution: I roll my own!
require_distribution: 1
topdir: /usr/src/me
vendor: Mickiesoft
packager: Mickeysoft Packaging Account <
[email protected]>
optflags: i386 -O2 -m486 -fno-strength-reduce
optflags: alpha -O2
optflags: sparc -O2
signature: pgp
pgp_name: Mickeysoft Packaging Account
pgp_path: /home/packages/.pgp
tmppath: /usr/tmp
require_vendor-raden g�r att RPM kr�ver (require) att finna en vendor-
rad. Denna kan komma fr�n /etc/rpmrc eller fr�n rubrik-delen (header)
eller spec-filen sj�lv. F�r att sl� av detta, s� kan du �ndra v�rdet
till 0. Detsamma g�ller f�r require_distribution- och require_group-
raderna.
N�sta rad �r distribution-raden. Du kan ange denna h�r, eller senare i
rubrik-delen av spec-filen. N�r du skapar ett RPM-paket f�r en
speciell distribution, s� �r det en god id� att se till att den h�r
raden �r korrekt, �ven om det inte kr�vs. vendor-raden fungerar i
stort sett p� samma s�tt, men kan vara vad som helst (allts� Joe's
Software och Rock Music Emporium).
RPM har nu ocks� st�d f�r att skapa paket p� flera olika arkitekturer.
rpmrc-filen kan inneh�lla flera "optflag"-variabler (optimerings-
flaggor), f�r att kompilera saker, som kr�ver en arkitektur-specifik
flagga under kompileringen. Se senare avsnitt f�r om hur du kan
anv�nda denna varibel.
Ut�ver de ovan n�mnda makrona, s� finns det flera till. Du kan
anv�nda:
rpm --showrc
f�r att ta reda p� hur dina taggar �r satta, och vilka alla
tillg�ngliga flaggor �r.
6.2. Spec-filen
Vi ska b�rja med att diskutera spec-filen. Spec-filer kr�vs, f�r att
du ska kunna skapa ett paket. Spec-filen �r en beskrivning av
mjukvaran, tillsammans med instruktioner f�r hur den ska kompileras,
och en fil-lista �ver alla de bin�r-filer som installeras.
Du b�r ge din spec-fil ett namn, i linje med konventionen. Det ska
vara paket-namn-bindestreck-versions-nummer-bindestreck-utg�vonummer-
punkt-spec.
H�r �r en liten spec-fil (vim-3.0-1.spec): (Det st�r s�, men det
verkar uppenbart att det r�r sig om eject-1.4-3.spec. �vers.anm.)
Summary: ejects ejectable media and controls auto ejection
Name: eject
Version: 1.4
Release: 3
Copyright: GPL
Group: Utilities/System
Source: sunsite.unc.edu:/pub/Linux/utils/disk-management/eject-1.4.tar.gz
Patch: eject-1.4-make.patch
Patch1: eject-1.4-jaz.patch
%description
This program allows the user to eject media that is autoejecting like
CD-ROMs, Jaz and Zip drives, and floppy drives on SPARC machines.
%prep
%setup
%patch -p1
%patch1 -p1
%build
make RPM_OPT_FLAGS="$RPM_OPT_FLAGS"
%install
install -s -m 755 -o 0 -g 0 eject /usr/bin/eject
install -m 644 -o 0 -g 0 eject.1 /usr/man/man1
%files
%doc README COPYING ChangeLog
/usr/bin/eject
/usr/man/man1/eject.1
6.3. Rubrik-delen
Rubrik-delen inneh�ller n�gra standard-f�lt, som du m�ste fylla i. Det
finns n�gra konventioner du m�ste f�lja ocks�. F�lten som m�ste fyllas
i �r de f�ljande:
� Summary: Detta �r en en-rads beskrivning av paketet.
� Name: Detta m�ste vara namn-str�ngen fr�n rpm-filnamnet du har
t�nkt anv�nda
� Version: Detta m�ste vara versions-str�ngen fr�n rpm-filnamnet du
har t�nkt anv�nda.
� Release: Detta �r utg�vo-numret f�r ett paket av samma version
(allts�, om vi skapar ett paket, och uppt�cker n�got mindre fel i
det, s� att vi m�ste skapa om det, s� ska n�sta paket ha utg�vo-
nummer 2).
� Icon: Detta �r namnet p� ikon-filen, f�r anv�ndning med andra h�g-
niv� installerings-verktyg (som Red Hats "glint"). Den m�ste vara
en gif, och finnas i SOURCES-katalogen.
� Source: Denna rad pekar ut den of�rd�rvade k�llkods-filens HEM-
katalog. Den anv�nds om du n�gonsin skulle vilja ha k�llkoden igen,
eller leta efter nya versioner. Konvention: filnamnet i den h�r
raden M�STE matcha filnamnet du har p� ditt eget system (ladda
allts� inte ned k�llkoden och �ndra dess namn). Du kan ocks� ange
mer �n en k�llkodsfil, genom att anv�nda rader som: using lines
like:
Source0: blah-0.tar.gz
Source1: blah-1.tar.gz
Source2: fooblah.tar.gz
Dessa filer ska vara i SOURCES-katalogen. (Katalog-strukturen
diskuteras i ett senare avsnitt, "K�llkodens katalog-tr�d".)
� Patch: Detta �r st�llet d�r du kan hitta patchen, om du skulle
beh�va ladda ned den igen. Konvention: filnamnet h�r m�ste matcha
det du anv�nder n�r du skapar DIN patch. Observera ocks� att du kan
ha flera patch-filer, precis som kan ha flera k�llkods-filer. Du
kan ha n�got i stil med:
Patch0: blah-0.patch
Patch1: blah-1.patch
Patch2: fooblah.patch
Dessa filer ska finnas i SOURCES-katalogen.
� Copyright: Denna rad anger hur upphovsr�tten f�r paketet ser ut. Du
b�r anv�nda n�gonting i stil med GPL, BSD, MIT, public domain,
distribuerbart eller kommersiellt.
� BuildRoot: Denna rad l�ter dig specificera en katalog som "rot" f�r
skapandet och installerandet av nya paket. Du kan anv�nda detta f�r
att hj�lpa dig att testa ditt paket, innan du installerar det p�
din maskin.
� Group: Denna rad anv�nds f�r att tala om f�r h�g-niv�
installerings-program (som Red Hats "glint"), var de ska placera
detta speciellt program i den hierarkiska strukturen. Grupp-tr�det
ser f�r tillf�llet ut ungef�r s� h�r:
Applications
Communications
Editors
Emacs
Engineering
Spreadsheets
Databases
Graphics
Networking
Mail
Math
News
Publishing
TeX
Base
Kernel
Utilities
Archiving
Console
File
System
Terminal
Text
Daemons
Documentation
X11
XFree86
Servers
Applications
Graphics
Networking
Games
Strategy
Video
Amusements
Utilities
Libraries
Window Managers
Libraries
Networking
Admin
Daemons
News
Utilities
Development
Debuggers
Libraries
Libc
Languages
Fortran
Tcl
Building
Version Control
Tools
Shells
Games
� %description Detta �r inte riktigt en rubrik-post, men b�r tas upp
i anslutning till resten av rubrik-delen. Du beh�ver en
"description" per paket och/eller under-paket. Detta �r ett f�lt p�
flera rader, som du ska anv�nda f�r att ge en omfattande
beskrivning av paketet.
6.4. Prep
Detta �r den andra avdelningen i spec-filen. Den anv�nds f�r att g�ra
k�llkoden redo f�r kompilering. H�r ska du g�ra allt som �r n�dv�ndigt
f�r att f� k�llkoden patchad och inst�lld, som den beh�ver vara
konfigurerad f�r att k�ra make.
En sak att observera: Vartenda av dessa avsnitt �r egentligen bara ett
st�lle att k�ra skal-program. Du skulle helt enkelt kunna g�ra ett sh-
skal-program och stoppa in det efter %prep-taggen, f�r att packa upp
och patcha k�llkoden. Vi har dock skapat makron f�r att hj�lpa till
med detta.
Den f�rsta av dessa makron �r %setup-makron. I dess enklaste form
(inga kommando-rads-parametrar), s� packar den helt enkelt upp
k�llkoden och cd-ar till k�llkods-katalogen. Den k�nner ocks� till
f�ljande parametrar:
� -n namn s�tter namnet p� installerings-katalogen till det angivna
namnet. Standarden �r $NAMN-$VERSION. Andra m�jligheter inbegriper
$NAMN, ${NAMN}${VERSION}, eller vad den huvudsakliga tar-filen nu
anv�nder. (Observera att dessa "$"-variabler inte �r riktiga
varibler, som �r tillg�ngliga inom spec-filen. De anv�nds h�r bara
i st�llet f�r exempel p� namn. Du m�ste anv�nda det riktiga namnet
och den riktiga versionen i ditt paket, inte en variabel.)
� -c skapar och cd-ar till den angivna katalogen innan den k�r untar.
� -b # packar upp Source# innan den cd-ar till katalogen (och detta
g�r inte ihop med -c, s� anv�nd det inte). Detta �r bara anv�ndbart
i paket med flera k�llkods-filer.
� -a # packar upp Source# efter att det cd-ar till katalogen.
� -T Denna parameter k�r �ver standard-handlingen, att packa upp
k�llkoden, och kr�ver en -b 0 eller -a 0 f�r att f� den
huvudsakliga k�llkods-filen uppackad. Du beh�ver detta n�r det
finns sekund�ra k�llkodsfiler.
� -D Radera inte katalogen innan uppackningen. Det �r endast
anv�ndbart d�r du har mer �n en konfigurerings-makro. Den ska
endast anv�ndas i konfigurerings-makron efter den f�rsta (men
aldrig i den f�rsta).
N�sta av de tillg�ngliga makrona �r %patch-makron. Denna makro hj�lper
dig att automatisera processen att l�gga till patchar till k�llkoden.
Den k�nner till flera parametrar, vilka r�knas upp nedan:
� # l�gger till Patch# som patch-fil.
� -p # anger antalet kataloger att strippa, f�r patch(1)-kommandot.
� -P Standard-handlingen �r att l�gga till Patch (eller Patch0).
Denna parameter f�rhindrar detta och kr�ver en 0 f�r att f� den
huvudsakliga k�llkods-filen uppackad. Denna parameter �r anv�ndbar
i en andra (eller senare) %patch-makro, vilken kr�ver ett annat
nummer �n den f�rsta makron.
� Du kan ocks� k�ra %patch#, ist�llet f�r att k�ra det riktiga
kommandot: %patch # -P .
Fler makron �n s� b�r du inte beh�va. Efter att du har gjort allt
detta, s� kan du g�ra vilka ytterligare inst�llningar du beh�ver,
genom skal-program av sh-typen. Allt du tar med, fram till %build-
makron (vilken tas upp i n�sta avsnitt) k�rs via sh. Se exemplen ovan
f�r information om vilka sorters saker du kan t�nkas vilja g�ra h�r.
6.5. Build
Det finns egentligen inga makron f�r detta avsnitt. H�r ska du bara
l�gga in de kommandon, som du beh�ver f�r att kompilera mjukvaran,
efter att du har packat upp k�llkoden, patchat den och cd-at till
katalogen. Det h�r �r bara en upps�ttning kommandon som skickas till
sh, s� alla giltiga sh-kommandon fungerar h�r (inklusive kommentarer).
Din aktuella arbets-katalog st�lls i varje avsnitt om till k�llkodens
topp-katalog, gl�m inte det. Du kan cd-a till underkataloger, om det
�r n�dv�ndigt.
6.6. Install
Det finns inga makron h�r, heller. H�r ska du bara stoppa in de
kommandon som �r n�dv�ndiga f�r att installera. Om du har make install
tillg�ngligt, i paketet du skapar, l�gg in det h�r. Om inte, s� kan du
antingen patch makefilen, s� att den har make install och sedan g�ra
en make install h�r, eller s� kan du installera filerna manuellt med
sh-kommandon. Du kan se din aktuella katalog som k�llkodens topp-
katalog.
6.7. installering/avinstallering Valfria skal-program som k�rs f�re
eller efter
Du kan l�gga in skal-program f�re och efter installering och
avinstalleringen, i bin�r-paket. En bra anledning att g�ra detta �r
f�r att g�ra saker som att k�ra ldconfig efter installeringen, eller
radera paket som inneh�ller delade bibliotek (shared libraries).
Makrona f�r alla skal-program �r som f�ljer:
� %pre �r makrot f�r skal-program som k�rs innan installeringen.
� %post �r makrot f�r skal-program som k�rs efter installeringen.
� %preun �r makrot f�r skal-program som k�rs f�re avinstalleringen.
� %postun �r makrot f�r skal-program som k�rs efter avinstalleringen.
Inneh�llet i dessa avsnitt kan vara vilka sh-program som helst, men du
beh�ver inte #!/bin/sh.
6.8. Files
Det h�r �r avsnittet d�r du m�ste r�kna upp filerna till bin�r-
paketet. RPM kan inte p� n�got s�tt veta vilka bin�r-filer som
installeras som ett resultat av make install. Det finns INGET s�tt att
g�ra detta. Vissa har f�reslagit att det skulle k�ra find innan och
efter att paketet installerats. I ett system med flera anv�ndare �r
detta dock oacceptabelt, eftersom andra filer kan skapas, under det
att ett paket skapas, som inte har n�gonting att g�ra med sj�lva
paketet.
Det finns n�gra makron tillg�ngliga f�r att g�ra n�gra speciella
grejer h�r ocks�. De r�knas upp och beskrivs h�r:
� %doc anv�nds f�r att markera dokumentation i k�llkods-paketet, som
du vill installera i en bin�r-installering. Dokumenten kommer
installeras i /usr/doc/$NAMN-$VERSION-$UTG�VA. Du kan r�kna upp
flera dokument p� samma rad med denna makro, eller s� kan du r�kna
upp dem separat, med en makro f�r varje dokument.
� %config anv�nds f�r att markera konfigurerings-filer i ett paket.
Detta inkluderar filer som sendmail.cf, passwd osv. Om du senare
avinstallerar ett paket som inneh�ller konfigurerings-filer, s�
kommer alla of�r�ndrade filer raderas, och de som har �ndrats
kommer flyttas till sina gamla namn, med .rpmsave tillagt till
namnet. Du kan r�kna upp flera filer med denna makro ocks�.
� %dir markerar en enda katalog, i en fillista, s� att den blir
inkluderad som "�gd" av paketet. Som standard �r det s�, att om du
listar ett katalog-namn UTAN en %dir-makro, s� kommer ALLT i den
katalogen att inkluderas i fil-listan, och senare installeras, som
en del av det paketet.
� %files -f <filnamn> l�ter dig lista dina filer i en godtyckligt
vald fil, i k�llkodens build-katalog. Det h�r �r trevligt i de fall
d�r du har ett paket som kan skapa sin egen fillista. D� inkluderar
du bara den fillistan h�r, och s� beh�ver du inte sj�lv r�kna upp
filerna.
Det viktigaste att t�nka p� i fillistan �r hur du r�knar upp
kataloger. Om du tar med /urs/bin av misstag, s� kommer ditt bin�r-
paket att inneh�lla varje fil i /usr/bin p� ditt system.
6.9. Bygga paketet
6.9.1. K�llkodens katalog-tr�d
Det f�rsta du beh�ver �r ett korrekt konfigurerar build-katalog-tr�d.
Detta kan du st�lla in med /etc/rpmrc-filen. De flesta anv�nder helt
enkelt /usr/src.
Du kan bli tvungen att skapa f�ljande kataloger i ditt build-tr�d:
� BUILD �r katalogen d�r allt skapande (building) utf�rs av RPM. Du
beh�ver inte utf�ra dina test-byggen p� n�got speciellt st�lle, men
det �r h�r RPM kommer utf�ra sitt byggnads-arbete.
� SOURCES �r katalogen d�r du b�r stoppa in dina ursprungliga
k�llkods-filer (packade med tar) och dina patchar. H�r kommer RPM
leta, som standard.
� SPECS �r katalogen d�r alla spec-filer ska finnas.
� RPMS �r katalogen d�r RPM kommer stoppa de bin�ra RPM-paket som det
byggt.
� SRPMS �r katalogen d�r alla k�llkods-RPM-paket kommer hamna.
6.9.2. Test-bygga
Det f�rsta du antagligen kommer vilja g�ra �r att f� k�llkoden att
kompilera, utan att anv�nda RPM. F�r att g�ra detta, packa upp
k�llkoden, och byt ut katalog-namnet till $NAMN.orig. Packa sedan upp
k�llkoden igen. Anv�nd k�llkoden att kompilera fr�n. G� in i k�llkods-
katalogen och f�lj instruktionerna f�r att kompilera den. Om du m�ste
modifiera saker och ting, s� beh�ver du en patch. S� fort du har
kompilerat det, st�da upp i k�llkods-katalogen. Se till s� att du har
tagit bort alla filer som skapas av configure-programmet. cd-a ut ur
k�llkods-katalogen till dess f�r�ldra-katalog. Sen kan du g�ra n�got i
stil med:
diff -uNr dirname.orig dirname > ../SOURCES/dirname-linux.patch
Detta skapar en patch �t dig, som du kan anv�nda i din spec-fil.
Observera att "linux" i patch-namnet bara �r ett s�tt att identifiera
den. Det �r b�st om du anv�nder n�got mer beskrivande namn, s�som
"config" eller "bugs" f�r att beskriva varf�r du var tvungen att skapa
en patch. Det �r ocks� en god id� att titta p� patch-filerna du ska�
par, innan du anv�nder dem, f�r att se till s� att inga bin�r-filer
kom med av misstag.
6.9.3. Skapa fil-listan
Nu n�r du har k�llkoden som ska kompileras, och vet hur du ska g�ra
det, kompilera och installera den. Titta p� utdatan fr�n
installerings-sekvensen och skapa din fil-lista, som du ska anv�nda i
spec-filen, fr�n den. Vi skapar oftast spec-filen parallellt med dessa
andra steg. Du kan skapa en f�rsta fil-lista och fylla i de enkla
delarna, och sedan fylla i de andra stegen, medan du utf�r dem.
6.9.4. Skapa paketet med RPM
S� fort du har en spec-fil, s� �r du klar att f�rs�ka skapa ditt
paket. Det b�sta s�ttet att g�ra detta, �r med en kommando-rad i stil
med:
rpm -ba foobar-1.0.spec
Det finns ocks� andra alternativ, som �r anv�ndbara med -b-parametern:
� p betyder att endast prep-avsnittet i spec-filen ska k�ras.
� l �r ett list-kollning, som g�r n�gra kontroller p� %files.
� c g�r en prep och kompilerar. Detta �r anv�ndbart n�r du �r os�ker
p� om k�llkoden alls kommer att kompilera. Det kan verka on�digt,
eftersom du helst vill fippla med k�llkoden sj�lv, tills du f�r den
att kompilera, och sedan anv�nda RPM, men n�r du vant dig vid att
anv�nda RPM, s� kommer du hitta tillf�llen d� du f�r anv�ndning f�r
detta.
� i g�r en prep, kompilera och installera.
� b prep, kompilera, installera och bygg endast ett bin�r-paket.
� a skapa allt (b�da k�llkods- och bin�r-paket).
Det finns flera alternativ till -b-parametern. Dessa �r:
� --short-circuit hoppar direkt till ett specifikt steg (kan -->
--endast anv�ndas med c och i).
� --clean raderar byggnades-tr�det n�r det allt �r klart.
� --keep-temps spara alla tempor�ra filer och skal-program, --> --som
skapades i /tmp. Du kan faktiskt se vilka filer som skapades i -->
--/tmp med -v-parametern.
� --test utf�r inga steg p� riktigt, men anv�nder keep-temp.
6.10. Testa det
N�r du har en k�llkods- och en bin�r-rpm f�r ditt paket, s� m�ste du
testa det. Det enklaste och b�sta s�ttet �r att anv�nda en helt annan
maskin �n den du skapade paketet p�. N�r allt kommer omkring s� har
du bara gjort en massa make install p� din egen maskin, s� det borde
vara ganska v�l installerat.
Du kan k�ra rpm -u paketnamn p� paketet du vill testa, men det kan
vara f�rr�diskt, eftersom du, d� du skapade paketet, gjorde en make
install. Om du gl�mde att ta med n�got i fil-listan, s� kommer det
inte bli avinstallerat. Du kommer d� om-installera bin�r-paketet och
ditt system kommer vara komplett igen, men din rpm �r det fortfarande
inte. Kom ih�g, att bara f�r att du k�r rpm -ba paket, s� kommer de
flesta som installerar paketet k�ra rpm -i paket. Se till s� att du
inte g�r n�got i build- och install-avsnitten, som beh�ver g�ras n�r
bin�r-filerna redan �r installerade.
6.11. Vad du ska g�ra med dina nya RPM-paket
S� fort du skapat dina egna RPM-paket (om vi f�ruts�tter att det �r
n�got som inte redan gjorts till RPM-paket), s� kan du dela med dig av
ditt arbete till andra (vilket ocks� f�ruts�tter att det du gjorde ett
RPM-paket av �r fritt distribuerbart). F�r att g�ra detta, ladda upp
det till ftp.redhat.com <
ftp://ftp.redhat.com>.
6.12. Och nu d�?
Se avsnittet ovan, om att Testa det och Vad du ska g�ra med dina nya
RPM-paket. Vi vill ha alla tillg�ngliga RPM-paket vi kan f�, och vi
vill att de ska vara bra RPM-paket. Ta dig tid att testa dem
ordentligt, och ta dig sedan tid att ladda upp dem, s� att alla kan f�
tillg�ng till dem. Var v�nlig se till att du laddar upp fritt
distribuerbar mjukvara. Kommersiell mjukvara och shareware ska inte
laddas upp, om de inte har en copyright som explicit s�ger att det �r
till�tet. Detta inkluderar Netscapes mjukvara, ssh, pgp osv.
7. RPM-skapande f�r flera arkitekturer
RPM kan nu anv�ndas f�r att bygga paket f�r Intel i386, Digital Alpha
som k�r Linux och Sparc. Det har �ven rapporterats att det fungerar p�
SGIs och HPs arbetsstationer. Det finns flera funktioner som g�r det
enkelt att skapa paket p� alla plattformar. Den f�rsta av dessa �r
"optflags"-direktivet i /etc/rpmrc. Det kan anv�ndas f�r att ange
flaggor, vilka anv�nds n�r mjukvara byggs med arkitektur-specifika
v�rden. En annan funktion �r "arch"-makrona i spec-filen. De kan
anv�ndas f�r att utf�ra olika saker, beroende p� vilken arkitektur du
skapar paketen p�. En annan funktion �r "Exclude"-direktivet i rubrik-
delen.
7.1. Exempel p� spec-filer
Det f�ljande �r delar av spec-filen till "fileutils"-paketet. Det �r
konfigurerat f�r att kunna byggas p� b�de Alpha och Intel.
Summary: GNU File Utilities
Name: fileutils
Version: 3.16
Release: 1
Copyright: GPL
Group: Utilities/File
Source0: prep.ai.mit.edu:/pub/gnu/fileutils-3.16.tar.gz
Source1: DIR_COLORS
Patch: fileutils-3.16-mktime.patch
%description
These are the GNU file management utilities. It includes programs
to copy, move, list, etc, files.
The ls program in this package now incorporates color ls!
%prep
%setup
%ifarch alpha
%patch -p1
autoconf
%endif
%build
configure --prefix=/usr --exec-prefix=/
make CFLAGS="$RPM_OPT_FLAGS" LDFLAGS=-s
%install
rm -f /usr/info/fileutils*
make install
gzip -9nf /usr/info/fileutils*
.
.
.
7.2. Opt-flaggor
I det h�r exemplet kan du se hur "optflags"-direktivet anv�nds fr�n
/etc/rpmrc. Beroende p� vilken arkitektur det byggas p�, s� ges det
korrekta v�rdet till RPM_OPT_FLAGS. Du m�ste patcha Makefilen f�r ditt
paket, f�r att anv�nda denna variabel, ist�llet f�r de vanliga
direktiven som kanske anv�nds (som -m486 och -O2). Du kan f� en b�ttre
k�nsla f�r vad som beh�ver g�ras, genom att installera detta k�llkods-
paket och sedan packa upp k�llkoden och unders�ka Makefilen. Ta sedan
en titt p� patchen f�r Makefilen och se vilka �ndringar som m�ste
g�ras.
7.3. Makron
%ifarch-makron �r v�ldigt viktig i allt detta. I de flesta fall
beh�ver du skapa en patch eller tv�, som �r specifika f�r endast en
arkitektur. I det h�r fallet kommer RPM till�ta dig att l�gga till den
patchen till endast en arkitektur.
I exemplet ovan har fileutils en patch f�r 64-bitars maskinter. Denna
ska uppenbarligen endast l�ggas till p� Alpha. S� vi la till en
%ifarch-makro kring 64-bitars-patchen, p� f�ljande s�tt:
%ifarch axp
%patch1 -p1
%endif
Detta ser till s� att patchen inte l�ggs till p� n�gon annan arkitek�
tur �n alpha.
7.4. Utesluta arkitekturer fr�n paket
F�r att du ska kunna underh�lla k�llkods-paket i en katalog, f�r alla
plattformar, s� har vi implementerat m�jligheten att "utesluta" paket
fr�n att byggas p� vissa arkitekturer. Detta �r f�r att du fortfarande
ska kunna g�ra saker som
rpm --rebuild /usr/src/SRPMS/*.rpm
och f� r�tt paket att byggas. Om du fortfarande inte har portat en
applikation till en viss plattform, s� �r allt du beh�ver g�ra att
l�gga till en rad som:
ExcludeArch: axp
till rubrik-delen av spec-filen i k�llkods-paketet. Bygg sedan om
paketet p� plattformen som det ska kunna byggas p�. Du har sedan ett
k�llkods-paket som g�r att bygga p� en Intel, och kan som enkelt kan
hoppas �ver p� en Alpha.
7.5. Avslutning
Att anv�nda RPM f�r att bygga paket f�r flera arkitekturer �r oftast
enklare att g�ra �n att skaffa paketet sj�lvt och bygga det p� b�da
st�llena. Detta blir dock mycket enklare, i det att fler av de "h�rda"
paketen byggs. Som alltid s� �r den b�sta hj�lpen, om du fastnar, d�
du bygger RPM-paket, att titta p� andra, liknande paket.
8. Upphovsr�tt
Detta dokument och dess inneh�ll �r upphovsr�tts-skyddat.
Vidaredistribution av detta dokument �r till�ten, s� l�nge inneh�llet
�r helt och h�llet intakt och utan �ndringar. Med andra ord, du f�r
endast omformatera och trycka om och vidaredistribuera det.
