RPM HOWTO (RPM at Idle) <Author>Donnie Barnes, <tt/djb@redhat.com/. Svensk översättning: Linus Åkerlund, uxm165t@tninet.se <date>v2.0, 8 April 1997. Svensk översättning: 8 juni 1998. <!-- Copyright 1997, Red Hat Software --> <toc> <sect>Inledning <p> RPM står för <bf/R/ed Hat <bf/P/ackage <bf/M/anager (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. <p> 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. <p> Mer fullständigt dokumentation om RPM är tillgänglig i Ed Baileys bok <em/Maximum RPM/. Den är tillgänglig för nedladdning eller beställning från <url url="http://www.redhat.com" name="www.redhat.com">. <sect>Översikt <p> 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 <em/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 <tt/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 <em/kan/ bli tvungen att göra. Alla saker som kompileras in, som standard, är på detta sätt klart synliga. <p> 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 <em/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 <em/snabb/ informations-sökning. <p> 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å. <p> 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). <sect>Grundläggande information <p> <sect1>Skaffa RPM <p> 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ån<url url="ftp://ftp.redhat.com/pub/redhat/code/rpm" name="ftp.redhat.com">. <sect1>RPM-krav <p> 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. <p> 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 <tt/gcc/, <tt/make/ osv. <sect>Använda RPM <p> I dess enklaste form kan RPM användas för att installera paket: <tscreen><verb> rpm -i foobar-1.0-1.i386.rpm </verb></tscreen> Det näst enklaste kommandot är för att avinstallera ett paket: <tscreen><verb> rpm -e foobar </verb></tscreen> <p> Ett av de mest komplicerade, men <em/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.: <tscreen><verb> rpm -i ftp://ftp.pht.com/pub/linux/redhat/rh-2.0-beta/RPMS/foobar-1.0-1.i386.rpm </verb></tscreen> <p> Observera att RPM nu kommer att fråga och/eller installera via FTP. <p> Även om dessa kommandon är enkla, så kan rpm användas på många olika sätt, vilket vi ser i <tt/Usage/-meddelandet: <tscreen><verb> 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} </verb></tscreen> Du kan hitta mer detaljer om vad dessa alternativ gör i man-sidan för RPM. <sect>Okej, vad kan jag <em/faktiskt/ göra med RPM? <p> 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: <itemize> <item>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: <tscreen><verb> rpm -Va </verb></tscreen> <item>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: <tscreen><verb>rpm -qf /usr/X11R6/bin/xjewel </verb></tscreen> Utdatan skulle bli: <tscreen><verb>xjewel-1.6-1</verb></tscreen> <item>Du hittar en ny koules-RPM, men du vet inte vad det är. För att få en del information skriver du: <tscreen><verb>rpm -qpi koules-1.2-2.i386.rpm</verb></tscreen> Utdatan skulle bli: <tscreen><verb>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. </verb></tscreen> <item>Vidare vill du se vilka filer som koules-RPM installerar. Du skulle skriva: <tscreen><verb>rpm -qpl koules-1.2-2.i386.rpm</verb></tscreen> Utdatan blir: <tscreen><verb> /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 </verb></tscreen> </itemize> <p> Dessa är bara några exempel. Mer kreativa exempel kan du komma på när du har lärt känna RPM bättre. <sect>Skapa RPM-paket <p> 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: <itemize> <item>Se till att <tt>/etc/rpmrc</tt> är inställd för ditt system. <item>Få källkoden som du ska bygga RPM-paketet för att kompilera på ditt system. <item>Gör en patch med de ändringar du behövde göra, för att få källkoden att kompilera ordentligt. <item>Gör en specifikations-fil för paketet. <item>Se till så att allt är på sin plats. <item>Skapa paketet med hjälp av RPM </itemize> Under normal användning skapar RPM både binär- och källkods-paket. <sect1>rpmrc-filen <p> Som det är nu, så är det enda sättet att konfigurera RPM via <tt>/etc/rpmrc</tt>-filen. Ett exempel ser ut så här: <tscreen><verb> 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 </verb></tscreen> <tt>require_vendor</tt>-raden gör att RPM kräver (require) att finna en vendor-rad. Denna kan komma från <tt>/etc/rpmrc</tt> eller från rubrik-delen (header) eller spec-filen själv. För att slå av detta, så kan du ändra värdet till <tt/0/. Detsamma gäller för <tt>require_distribution</tt>- och <tt>require_group</tt>-raderna. Nästa rad är <tt>distribution</tt>-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. <tt>vendor</tt>-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. <tt/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: <tscreen><verb> rpm --showrc </verb></tscreen> för att ta reda på hur dina taggar är satta, och vilka alla tillgängliga flaggor är. <sect1>Spec-filen <p> 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. <p> 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. <p> 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.) <tscreen><verb> 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 </verb></tscreen> <sect1>Rubrik-delen <p> 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: <itemize> <item><tt/Summary:/ Detta är en en-rads beskrivning av paketet. <item><tt/Name:/ Detta måste vara namn-strängen från rpm-filnamnet du har tänkt använda <item><tt/Version:/ Detta måste vara versions-strängen från rpm-filnamnet du har tänkt använda. <item><tt/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). <item><tt/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. <item><tt/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: <tscreen><verb> Source0: blah-0.tar.gz Source1: blah-1.tar.gz Source2: fooblah.tar.gz </verb></tscreen> Dessa filer ska vara i <tt/SOURCES/-katalogen. (Katalog-strukturen diskuteras i ett senare avsnitt, "Källkodens katalog-träd".) <item><tt/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: <tscreen><verb> Patch0: blah-0.patch Patch1: blah-1.patch Patch2: fooblah.patch </verb></tscreen> Dessa filer ska finnas i <tt/SOURCES/-katalogen. <item><tt>Copyright:</tt> 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. <item><tt/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. <item><tt/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: <tscreen><verb> 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 </verb></tscreen> <item><tt/%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. </itemize> <sect1>Prep <p> 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 <tt/make/. <p> 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 <tt/%prep/-taggen, för att packa upp och patcha källkoden. Vi har dock skapat makron för att hjälpa till med detta. <p> Den första av dessa makron är <tt/%setup/-makron. I dess enklaste form (inga kommando-rads-parametrar), så packar den helt enkelt upp källkoden och <tt/cd/-ar till källkods-katalogen. Den känner också till följande parametrar: <itemize> <item><tt/-n namn/ sätter namnet på installerings-katalogen till det angivna <tt/namn/et. Standarden är <tt/$NAMN-$VERSION/. Andra möjligheter inbegriper <tt/$NAMN/, <tt/${NAMN}${VERSION}/, eller vad den huvudsakliga tar-filen nu använder. (Observera att dessa "$"-variabler <em/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.) <item><tt/-c/ skapar och cd-ar till den angivna katalogen <em/innan/ den kör untar. <item><tt/-b #/ packar upp Source# <em/innan/ den cd-ar till katalogen (och detta går inte ihop med <tt/-c/, så använd det inte). Detta är bara användbart i paket med flera källkods-filer. <item><tt/-a #/ packar upp Source# <em/efter/ att det cd-ar till katalogen. <item><tt/-T/ Denna parameter kör över standard-handlingen, att packa upp källkoden, och kräver en <tt/-b 0/ eller <tt/-a 0/ för att få den huvudsakliga källkods-filen uppackad. Du behöver detta när det finns sekundära källkodsfiler. <item><tt/-D/ Radera <em/inte/ katalogen innan uppackningen. Det är endast användbart där du har mer än en konfigurerings-makro. Den ska <em/endast/ användas i konfigurerings-makron <em/efter/ den första (men aldrig i den första). </itemize> <p> Nästa av de tillgängliga makrona är <tt/%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: <itemize> <item><tt/#/ lägger till Patch# som patch-fil. <item><tt/-p #/ anger antalet kataloger att strippa, för patch(1)-kommandot. <item><tt/-P/ Standard-handlingen är att lägga till <tt/Patch/ (eller <tt/Patch0/). Denna parameter förhindrar detta och kräver en <tt/0/ för att få den huvudsakliga källkods-filen uppackad. Denna parameter är användbar i en andra (eller senare) <tt/%patch/-makro, vilken kräver ett annat nummer än den första makron. <item> Du kan också köra <tt/%patch#/, istället för att köra det riktiga kommandot: <tt/%patch # -P/ . </itemize> <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 <tt/sh/-typen. Allt du tar med, fram till <tt/%build/-makron (vilken tas upp i nästa avsnitt) körs via <tt/sh/. Se exemplen ovan för information om vilka sorters saker du kan tänkas vilja göra här. <sect1>Build <p> 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 <tt/sh/, så alla giltiga <tt/sh/-kommandon fungerar här (inklusive kommentarer). <bf/Din aktuella arbets-katalog ställs i varje avsnitt om till källkodens topp-katalog/, glöm inte det. Du kan <tt/cd/-a till underkataloger, om det är nödvändigt. <sect1>Install <p> 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 <tt/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 <tt/make install/ och sedan göra en <tt/make install/ här, eller så kan du installera filerna manuellt med <tt/sh/-kommandon. Du kan se din aktuella katalog som källkodens topp-katalog. <sect1>Valfria skal-program som körs före eller efter installering/avinstallering <p> 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 <tt/ldconfig/ efter installeringen, eller radera paket som innehåller delade bibliotek (shared libraries). Makrona för alla skal-program är som följer: <itemize> <item><tt/%pre/ är makrot för skal-program som körs innan installeringen. <item><tt/%post/ är makrot för skal-program som körs efter installeringen. <item><tt/%preun/ är makrot för skal-program som körs före avinstalleringen. <item><tt/%postun/ är makrot för skal-program som körs efter avinstalleringen. </itemize> <p> Innehållet i dessa avsnitt kan vara vilka <tt/sh/-program som helst, men du behöver <em/inte/ <tt>#!/bin/sh</tt>. <sect1>Files <p> Det här är avsnittet där du <em/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 <tt/make install/. Det finns <em/INGET/ sätt att göra detta. Vissa har föreslagit att det skulle köra <tt/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. <p> 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: <itemize> <item><tt/%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 <tt>/usr/doc/$NAMN-$VERSION-$UTGÅVA</tt>. 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. <item><tt/%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 <tt/.rpmsave/ tillagt till namnet. Du kan räkna upp flera filer med denna makro också. <item><tt/%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 <em/UTAN/ en <tt/%dir/-makro, så kommer <em/ALLT/ i den katalogen att inkluderas i fil-listan, och senare installeras, som en del av det paketet. <item><tt/%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. </itemize> <p> Det viktigaste att tänka på i fillistan är hur du räknar upp kataloger. Om du tar med <tt>/urs/bin</tt> av misstag, så kommer ditt binär-paket att innehålla <em/varje/ fil i <tt>/usr/bin</tt> på ditt system. <sect1>Bygga paketet <p> <sect2>Källkodens katalog-träd <p> Det första du behöver är ett korrekt konfigurerar build-katalog-träd. Detta kan du ställa in med <tt>/etc/rpmrc</tt>-filen. De flesta använder helt enkelt <tt>/usr/src</tt>. <p> Du kan bli tvungen att skapa följande kataloger i ditt build-träd: <itemize> <item><tt/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. <item><tt/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. <item><tt/SPECS/ är katalogen där alla spec-filer ska finnas. <item><tt/RPMS/ är katalogen där RPM kommer stoppa de binära RPM-paket som det byggt. <item><tt/SRPMS/ är katalogen där alla källkods-RPM-paket kommer hamna. </itemize> <p> <sect2>Test-bygga <p> 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 <tt>configure</tt>-programmet. <tt/cd/-a ut ur källkods-katalogen till dess föräldra-katalog. Sen kan du göra något i stil med: <tscreen><verb> diff -uNr dirname.orig dirname > ../SOURCES/dirname-linux.patch </verb></tscreen> 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 <em/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. <p> <sect2>Skapa fil-listan <p> 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. <p> <sect2>Skapa paketet med RPM <p> 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: <p> <tscreen><verb> rpm -ba foobar-1.0.spec </verb></tscreen> <p> Det finns också andra alternativ, som är användbara med <tt/-b/-parametern: <itemize> <item><tt/p/ betyder att endast <tt/prep/-avsnittet i spec-filen ska köras. <item><tt/l/ är ett list-kollning, som gör några kontroller på <tt/%files/. <item><tt/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. <item><tt/i/ gör en prep, kompilera och installera. <item><tt/b/ prep, kompilera, installera och bygg endast ett binär-paket. <item><tt/a/ skapa allt (båda källkods- och binär-paket). </itemize> Det finns flera alternativ till <tt/-b/-parametern. Dessa är: <itemize> <item><tt/--short-circuit/ hoppar direkt till ett specifikt steg (kan --> --endast användas med c och i). <item><tt/--clean/ raderar byggnades-trädet när det allt är klart. <item><tt/--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 <tt/-v/-parametern. <item><tt/--test/ utför inga steg på riktigt, men använder keep-temp. </itemize> <sect1>Testa det <p> 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 <tt/make install/ på din egen maskin, så det borde vara ganska väl installerat. <p> Du kan köra <tt/rpm -u paketnamn/ på paketet du vill testa, men det kan vara förrädiskt, eftersom du, då du skapade paketet, gjorde en <tt/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 <tt/rpm -ba paket/, så kommer de flesta som installerar paketet köra <tt/rpm -i paket/. Se till så att du inte gör något i <tt/build/- och <tt/install/-avsnitten, som behöver göras när binär-filerna redan är installerade. <p> <sect1>Vad du ska göra med dina nya RPM-paket <p> 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 <url url="ftp://ftp.redhat.com" name="ftp.redhat.com">. <sect1>Och nu då? <p> 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. <em/Var vänlig/ se till att du laddar upp <em/fritt distribuerbar mjukvara/. Kommersiell mjukvara och shareware ska <em/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. <sect>RPM-skapande för flera arkitekturer <p> 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 <tt>/etc/rpmrc</tt>. 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. <sect1>Exempel på spec-filer <p> 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. <tscreen><verb> 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* . . . </verb></tscreen> <sect1>Opt-flaggor <p> I det här exemplet kan du se hur "optflags"-direktivet används från <tt>/etc/rpmrc</tt>. Beroende på vilken arkitektur det byggas på, så ges det korrekta värdet till <tt/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 <tt/-m486/ och <tt/-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. <sect1>Makron <p> <tt/%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 <tt/%ifarch/-makro kring 64-bitars-patchen, på följande sätt: <tscreen><verb> %ifarch axp %patch1 -p1 %endif </verb></tscreen> Detta ser till så att patchen inte läggs till på någon annan arkitektur än alpha. <sect1>Utesluta arkitekturer från paket <p> 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 <tscreen><verb> rpm --rebuild /usr/src/SRPMS/*.rpm </verb></tscreen> 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: <tscreen><verb> ExcludeArch: axp </verb></tscreen> 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. <sect1>Avslutning <p> 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. <sect>Upphovsrätt <p> 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. </article>