RPM HOWTO (RPM at Idle) Donnie Barnes, djb@redhat.com. Svensk översättning: Linus Åkerlund, uxm165t@tninet.se 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 . 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 . 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 ] rpm {--install -i} [-v] [--hash -h] [--percent] [--force] [--test] [--replacepkgs] [--replacefiles] [--root ] [--excludedocs] [--includedocs] [--noscripts] [--rcfile ] [--ignorearch] [--dbpath ] [--prefix ] [--ignoreos] [--nodeps] [--ftpproxy ] [--ftpport ] file1.rpm ... fileN.rpm rpm {--upgrade -U} [-v] [--hash -h] [--percent] [--force] [--test] [--oldpackage] [--root ] [--noscripts] [--excludedocs] [--includedocs] [--rcfile ] [--ignorearch] [--dbpath ] [--prefix ] [--ftpproxy ] [--ftpport ] [--ignoreos] [--nodeps] file1.rpm ... fileN.rpm rpm {--query -q} [-afpg] [-i] [-l] [-s] [-d] [-c] [-v] [-R] [--scripts] [--root ] [--rcfile ] [--whatprovides] [--whatrequires] [--requires] [--ftpuseport] [--ftpproxy ] [--ftpport ] [--provides] [--dump] [--dbpath ] [targets] rpm {--verify -V -y} [-afpg] [--root ] [--rcfile ] [--dbpath ] [--nodeps] [--nofiles] [--noscripts] [--nomd5] [targets] rpm {--setperms} [-afpg] [target] rpm {--setugids} [-afpg] [target] rpm {--erase -e} [--root ] [--noscripts] [--rcfile ] [--dbpath ] [--nodeps] [--allmatches] package1 ... packageN rpm {-b|t}[plciba] [-v] [--short-circuit] [--clean] [--rcfile ] [--sign] [--test] [--timecheck ] specfile rpm {--rebuild} [--rcfile ] [-v] source1.rpm ... sourceN.rpm rpm {--recompile} [--rcfile ] [-v] source1.rpm ... sourceN.rpm rpm {--resign} [--rcfile ] package1 package2 ... packageN rpm {--addsign} [--rcfile ] package1 package2 ... packageN rpm {--checksig -K} [--nopgp] [--nomd5] [--rcfile ] package1 ... packageN rpm {--rebuilddb} [--rcfile ] [--dbpath ] 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 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 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 . 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.