Nästa Föregående Innehållsförteckning

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:

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 <packages@mickiesoft.com>

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:

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ä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:

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 Valfria skal-program som körs före eller efter installering/avinstallering

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:

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:

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

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:

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 skapar, innan du använder dem, för att se till så att inga binär-filer kom med av misstag.

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.

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:

Det finns flera alternativ till -b-parametern. Dessa är:

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.

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.

Nästa Föregående Innehållsförteckning