Menad¿er Pakietów RedHat-a (RPM) - Jak To Zrobiæ
  Autor: Donnie Barnes djb@redhat.com
  V2.0, 8 Kwietnia 1997
  WWeerrssjjaa ppoollsskkaa:: JJaacceekk PPlliisszzkkaa pplliisszzkkaa@@ffuuww..eedduu..ppll

  Niniejszy dokument jest t³umaczeniem RPM-HOWTO i w skrócie opisuje jak
  co¶ zrobiæ u¿ywaj±c rpm-a czyli Menad¿era Pakietów RedHat-a (RRedHat
  PPackage MManager).  Dokument ten zosta³ napisany w standardzie
  ISO-8859-2.  Orygina³ t³umaczenia tego dokumentu znajduje siê pod
  adresem http://www.jtz.org.pl <http://www.jtz.org.pl>.
  http://www.jtz.org.pl a tak¿e na ftp://ftp.icm.edu.pl/pub/Linux/sun­
  site/docs/HOWTO/ <ftp://ftp.icm.edu.pl/pub/Linux/sunsite/docs/HOWTO/>.
  ______________________________________________________________________

  Table of Contents:

  1.      Wprowadzenie

  2.      Do czego s³u¿y RPM?

  3.      Informacje ogólne

  3.1.    Sk±d wzi±æ RPM?

  3.2.    Wymagania RPM

  4.      U¿ywanie RPM

  5.      A co tak

  6.      Tworzenie rpm-ów.

  6.1.    Plik rpmrc

  6.2.    Plik specyfikuj±cy .spec

  6.3.    Nag³ówek

  6.4.    Sekcja Prep

  6.5.    Sekcja Build

  6.6.    Sekcja Install

  6.7.    Opcjonalne sekcje pre i post dla sekcji Install/Uninstall

  6.8.    Sekcja Files

  6.9.    Tworzenie pakietu

  6.9.1.  Katalogi z plikami ¼ród³owymi

  6.9.2.  Próbne tworzenie pakietu

  6.9.3.  Tworzenie listy plików

  6.9.4.  Tworzenie pakietu RPM

  6.10.   Testowanie pakietu

  6.11.   Co robiæ z Twoimi nowymi RPM-ami ?

  6.12.   Co teraz?

  7.      Tworzenie RPM-ów na wiele platform.

  7.1.    Przyk³adowy plik specyfikuj±cy .spec

  7.2.    Dyrektywa optflags

  7.3.    Makra

  7.4.    Wy³±czanie pewnych platform w pakietach

  7.5.    Ostatnie poprawki

  8.      Uwaga o prawach autorskich
  ______________________________________________________________________

  11..  WWpprroowwaaddzzeenniiee

  Skrót RPM pochodzi od ang.  RRed Hat PPackage MManager co oznacza w
  wolnym t³umaczeniu menad¿er pakietów RedHat-a.  Jednak pomimo tego, ¿e
  w nazwie znajduje siê Red Hat, to w zamierzeniu jest on systemem
  otwartym, dostêpnym dla ka¿dego. Umo¿liwia on spakowanie zarówno kodu
  ¼ród³owego jak i programów binarnych do zwartej postaci zawieraj±cej
  dodatkowo informacje istotne przy zarz±dzaniu oprogramowaniem.
  Umo¿liwia to ³atw± instalacjê, od¶wie¿anie oraz usuwanie
  oprogramowania. Informacja o zainstalowanym oprogramowaniu jest ³atwo
  dostêpna jako ¿e RPM tworzy bazê danych o wszystkich pakietach
  zainstalowanych w naszym systemie.  Pozwala to na szybkie sprawdzenie
  czy dany pakiet jest zainstalowany, a je¶li tak to co zawiera, jaka
  jest jego wersja, jakie pliki zosta³y przez niego w systemie
  zainstalowane oraz jakich innych pakietów wymaga.  Pozwala te¿
  sprawdziæ do jakiego pakietu nale¿y dany plik.

  Przyp. t³um. rpm jest obecnie u¿ywany zarówno do plików w postaci
  ¼ród³owej jak i binarnej. W oryginale autor odwo³ujê siê g³ównie do
  tej pierwszej. Jednak poniewa¿ obecnie czê¶ciej u¿ywa siê pakietów w
  postaci binarnej to pliki z których powsta³ rpm a które maj± byæ
  zainstalowane równie¿ bêdê nazywa³ plikami ¼ród³owymi za¶ proces
  instalacji b±d¼ kompilacji - instalacj±.

  Firma Red Hat Software zachêca inne firmy i grupy tworz±ce
  oprogramowanie do bli¿szego zapoznania siê z RPM i wykorzystania go
  przy tworzeniu w³asnych pakietów.  Bêd±c do¶æ elastycznym i ³atwym w
  u¿yciu, RPM pozwala budowaæ nawet bardzo obszerne zbiory pakietów.
  Pomimo tego, ¿e jest to system ca³kowicie otwarty i dostêpny, jego
  autorzy chêtnie wys³uchaj± informacji o b³êdach i ewentualnych
  poprawkach.  (Jednak przed zg³oszeniem ``b³êdu'' nale¿y, tak jak
  zawsze, najpierw sprawdziæ czy ma siê najnowsz± stabiln± wersjê,
  przejrzeæ dokumentacjê oraz przeszukaæ archiwa USENET i je¶li i tam
  nie bêdzie odpowiedzi - spytaæ na odpowiedniej grupie dyskusyjnej np.
  pl.comp.os.linux -przyp. t³um.)  U¿ywanie i rozpowszechnianie RPM jest
  wolne od op³at i regulowane Publiczn± Licencj± GNU - GPL (ang. GNU
  Public Licence).

  Bardziej szczegó³owa dokumentacja dotycz±ca RPM jest zawarta w ksi±¿ce
  Eda Bailey'a, _M_a_x_i_m_u_m _R_P_M, która mo¿na ¶ci±gn±æ b±d¼ zakupiæ w
  www.redhat.com <http://www.redhat.com>.

  22..  DDoo cczzeeggoo ss³³uu¿¿yy RRPPMM??

  Na pocz±tku warto powiedzieæ co nieco o ``filozofii'' RPM.  Celem jego
  projektantów by³o umo¿liwienie u¿ycia pierwotnych kodów ¼ród³owych.
  Zanim powsta³ RPM, jego autorzy u¿ywali RPP (przy czym podkre¶laj±, ¿e
  RPM _n_i_e nie jest na nim oparty ), w którym udostêpniano poprawione
  kody ¼ród³owe, konkretnie te, które by³y u¿ywane do instalacji.
  Teoretycznie mog³oby to wystarczyæ, bo mo¿na by³o zainstalowaæ pakiet
  ¼ród³owy RPP i skompilowaæ go (poleceniem make) bez wiêkszych
  problemów.  Jednak¿e nie by³y to oryginalne ¼ród³a i trudno by³o na
  pierwszy rzut oka powiedzieæ co w nich zosta³o zmienione.  Niezbêdnym
  by³o ¶ci±gniêcie równie¿ oryginalnych ¼róde³.  RPM za¶ zawiera
  oryginalne ¼ród³a wraz z poprawkami których dokonano. W opinii autorów
  rozwi±zanie to jest znacznie lepsze. Dlaczego?

  Z paru powodów. Po pierwsze, je¶li pojawi siê nowa wersja programu to
  nie zaczynamy od zera. Niektóre poprawki, które by³y dobre dla
  poprzedniej wersji, mog± byæ w³a¶ciwe, najwy¿ej po minimalnych
  zmianach i dla obecnej. By siê o tym przekonaæ, wystarczy do nich
  zajrzeæ.  Poza tym wszystkie domy¶lne opcje potrzebne do instalacji s±
  w ten sposób ³atwo dostêpne.

  Poza tym RPM zaprojektowano tak, aby umo¿liwiæ sprawdzanie wielu
  istotnych informacji dotycz±cych zarówno pojedyñczego, konkretnego
  pakietu jak i ich zestawu b±d¼ te¿ wszystkich pakietów zainstalowanych
  w danym systemie.  Przyk³adem takiej informacji jest lista pakietów,
  których dany pakiet wymaga wraz z numerami wersji.  Mo¿liwe jest
  równie¿ sprawdzenie z jakiego pakietu pochodzi konkretny plik oraz
  gdzie mo¿na znale¼æ jego wersjê ¼ród³ow±.  Pliki RPM s± ju¿
  wewnêtrznie spakowane, ale sprawdzanie informacji dotycz±cych
  konkretnego pakietu jest proste i _s_z_y_b_k_i_e dziêki specjalnemu binarnemu
  nag³ówkowi który zawiera praktycznie wszystkie niezbêdne informacje o
  pakiecie.

  Innym atutem RPM jest umiejêtno¶æ weryfikacji  pakietów.  Je¶li boisz
  siê, ¿e skasowa³e¶ jaki¶ wa¿ny plik, to mo¿esz to po prostu sprawdziæ.
  RPM poinformuje Ciê o wykrytych nieprawid³owo¶ciach. Je¶li zajdzie
  potrzeba, to mo¿esz ³atwo odnowiæ zainstalowany pakiet przy czym Twoje
  pliki konfiguracyjne zostan± zachowane.  Oczywi¶cie mo¿esz te¿
  zainstalowaæ je od nowa.

  Autorzy chc± podziêkowaæ grupie ludzi od dystrybucji BOGUS za wiele
  ich idei i pomys³ów które wykorzystano w RPM.  Gdy¿ o ile RPM zosta³
  napisany w ca³o¶ci przez Red Hat Software, to zasady jego dzia³ania s±
  oparte na kodzie stworzonym przez BOGUS (PM oraz PMS).

  33..  IInnffoorrmmaaccjjee ooggóóllnnee

  33..11..  SSkk±±dd wwzzii±±ææ RRPPMM??

  Najprostszym sposobem jest instalacja Linux-a Red Hat.  Je¶li kto¶ nie
  chce tego robiæ to mo¿e u¿ywaæ RPM bez tego. W Polsce RPM jest
  dostêpny np. pod adresem: ftp.icm.edu.pl
  <ftp://ftp.icm.edu.pl/pub/redhat/code/rpm> - polskim mirrorze
  ftp.redhat.com.

  33..22..  WWyymmaaggaanniiaa RRPPMM

  Podstawowym wymaganiem RPM-a jest cpio o numerze wersji 2.4.2 lub
  wy¿szym. Mimo ¿e RPM jest pomy¶lany do pracy pod Linux-em to równie
  mo¿e byæ przeniesiony na inne systemy Unix. W rzeczywisto¶ci uda³o siê
  go ju¿ uruchomiæ pod SunOS, Solaris, AIX, Irix, AmigaOS i wieloma
  innymi systemami.  Jednak nale¿y pamiêtaæ, ¿e pakiety binarne
  stworzone na ró¿nych Unix-ach mog± nie byæ ze sob± zgodne.
  S± to minimalne wymagania by zainstalowaæ RPM-y.  By tworzyæ RPM-y z
  kodu ¼ród³owego potrzebne jest równie¿ wszystko to co normalnie jest
  wymagane przy tworzeniu pakietu np.  gcc, make, itd.

  44..  UU¿¿yywwaanniiee RRPPMM

  Najprostszym wykorzystaniem RPM jest instalacja nowego pakietu:

               rpm -i foobar-1.0-1.i386.rpm

  Równie proste jest jego odinstalowanie:

               rpm -e foobar

  Przyk³adem bardziej z³o¿onego, ale  _b_a_r_d_z_o u¿ytecznego polecenia jest
  instalacja pakietów poprzez FTP. Je¶li jeste¶ pod³±czony do sieci i
  chcesz zainstalowaæ nowy pakiet, to wszystko co musisz zrobiæ to podaæ
  nazwê pliku jako poprawny URL, np.:

               rpm -i ftp://ftp.pht.com/pub/linux/redhat/rh-2.0-beta/RPMS/foobar-1.0-1.i386.rpm

  Chcia³bym podkre¶liæ, ¿e w tym przypadku RPM sprawdzi b±d¼ zainstaluje
  pakiet poprzez FTP.

  By³y to w miarê proste polecenia, lecz rpm mo¿e byæ u¿yty na wiele
  wiêcej sposobów jak mo¿na siê ³atwo przekonaæ pisz±c w linii komend

               rpm

  i naciskaj±c Enter:

  RPM version 2.3.9
  Copyright (C) 1997 - Red Hat Software
  This may be freely redistributed under na warunkach
   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}

  Wszystkie te opcje s± opisane w podrêczniku systemowym "man"
  dotycz±cym RPM.

  55..  AA ccoo ttaakk _n_a_p_r_a_w_d_ê mmoo¿¿nnaa zzrroobbiiææ zz RRPPMM??

  RPM jest bardzo wygodnym narzêdziem i jak mo¿na by³o siê przekonaæ, ma
  sporo opcji.  Najlepsz± metod± zapoznania siê z nimi s± przyk³ady.

  Pokaza³em ju¿ najprostsz± instalacjê i usuwanie pakietów, czas na
  trochê ciekawsze przyk³ady:

  ·  W praktyce instaluj±c pakiet chce siê usun±c jego star± wersjê
     (opcja -U od ang. upgrade). Czêsto chcemy równie¿ widzieæ postêp
     instalacji (-h od ang. hash) oraz dostaæ poszerzone komunikaty o
     b³êdach (-v od ang. verbose), tak wiêc praktycznie najczê¶ciej
     pakiety instaluje siê poprzez:
               rpm -Uhv foobar-1.0-1.i386.rpm

  ·  Powiedzmy, ¿e skasowa³e¶ przypadkiem jakie¶ pliki, niestety, nie
     znasz nawet ich nazw.  Je¶li wiêc chcesz zweryfikowaæ ca³y system i
     sprawdziæ czego mo¿e brakowaæ, zrób tak:

       rpm -Va

  (od ang. Verify all)

  ·  Powiedzmy, ¿e natkn±³e¶ siê na plik, którego nie znasz.  ¯eby
     sprawdziæ do jakiego pakietu nale¿y, zrób:

       rpm -qf /usr/X11R6/bin/xjewel

  (od ang. query file).  W wyniku otrzymasz nazwê pakietu:

       xjewel-1.6-1

  ·  Natkn±³e¶ siê na jaki¶ plik RPM i chcia³by¶ sprawdziæ co jest w
     ¶rodku. Zrób tak:

       rpm -qpi koules-1.2-2.i386.rpm

  Wy¶wietli Ci siê co¶ takiego:

       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.

  (od ang. query package info).

  ·  A teraz chcia³by¶ sprawdziæ jakie pliki wchodz± w sk³ad tego
     pakietu:

       rpm -qpl koules-1.2-2.i386.rpm

  W wyniku otrzymasz ich listê:

       /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

  (od ang. query package list)

  ·  Chcesz wy¶wietliæ listê pakietów zainstalowanych w Twoim systemie?
     Nic prostszego:

       rpm -qa

  (od ang. query all).

  ·  Chcesz sprawdziæ czy pakiet jest kompletny, nie przek³amany i mam
     poprawny podpis PGP?

       rpm -K -vv pakiet.rpm

  To by³o tylko parê przyk³adów, wiêcej znajdziesz np. w man-ie.  Na
  pewno wpadniesz na ciekawsze w miarê jak bêdziesz lepiej poznawa³ RPM.

  66..  TTwwoorrzzeenniiee rrppmm--óóww..

  Tworzenie rpm-ów jest do¶æ proste, szczególnie je¶li oprogramowanie
  które chcesz w nie w³o¿yæ poprawnie siê instaluje.

  Procedura tworzenia RPM-ów wygl±da tak:

  ·  Upewnij siê, ¿e plik /etc/rpmrc jest obecny i poprawnie
     skonfigurowany w Twoim systemie.

  ·  Doprowad¼ to tego, ¿e pliki ¼ród³owe dla których tworzysz rpm
     poprawnie siê instaluj±.

  ·  Przygotuj listê poprawek jakich musia³e¶ dokonaæ by kod kompilowa³
     siê poprawnie.

  ·  Przygotuj plik specyfikuj±cy (.spec) dla Twojego pakietu.

  ·  Upewnij siê, ¿e wszystko jest na swoim miejscu.

  ·  Zbuduj pakiet u¿ywaj±c rpm.

  Zazwyczaj RPM tworzy zarówno pakiety binarne jak i ¼ród³owe.

  66..11..  PPlliikk rrppmmrrcc

  W chwili obecnej, jedyny sposób konfiguracji RPM-a jest dostêpny
  poprzez plik /etc/rpmrc.  Przyk³adowy plik wygl±da tak:

       require_vendor: 1
       distribution: Moja w³asna dystrybucja!
       require_distribution: 1
       topdir: /usr/src/me
       vendor: Kubu¶soft
       packager: Pakuj±cy RPM w Kubu¶soft <pakiety@kubu¶soft.com.pl>

       optflags: i386 -O2 -m486 -fno-strength-reduce
       optflags: alpha -O2
       optflags: sparc -O2

       signature: pgp
       pgp_name: Pakuj±cy RPM w Kubu¶soft
       pgp_path: /home/pakiety/.pgp

       tmppath: /usr/tmp

  Wiersz require_vendor zmusza RPM-a do szukania wiersza z nazw±
  producenta pakietów (vendor).  Ta mo¿e pochodziæ z pliku /etc/rpmrc
  lub z nag³ówka pliku .spec.  By wy³±czyæ tê opcjê, zmieñ liczbê na 0.
  Analogicznie jest w przypadku wierszy require_distribution oraz
  require_group.

  Nastêpnym wiersz zawiera  distribution i okre¶la nazwê dystrybucji.
  Mo¿esz j± zdefiniowaæ tutaj, b±d¼ pó¼niej, w nag³ówku pliku
  specyfikuj±cego.  Tworz±c pakiet dla konkretnej dystrybucji warto
  zadbaæ by wiersz ten zawiera³ poprawn± informacjê, nawet pomimo tego,
  ¿e nie jest wymagany.  Tyczy siê to równie¿ wiersza vendor
  (producent), choæ nazwa mo¿e byæ zupe³nie dowolna (np. Joe's Software,
  Rock Music Emporium).

  RPM pozwala równie¿ tworzyæ pakiety dla ró¿nych platform sprzêtowych.
  Plik rpmrc mo¿e zawieraæ zmienn± ``optflags'' wykorzystywan± przy
  building budowaniu tych elementów pakietu, które wymagaj± opcji
  zale¿nych od platformy.  Dok³adniejszy opis tej zmiennej pojawi siê w
  jednym z nastêpnych rodzia³ów.

  Nie s± to oczywi¶cie wszystkie etykiety/makra.  Jest ich wiêcej. By
  siê im przyjrzeæ spróbuj komendy:

       rpm --showrc

  która powinna wypisaæ wszystkie mo¿liwe etykiety wraz z ich
  warto¶ciami (o ile s± ustawione).

  66..22..  PPlliikk ssppeeccyyffiikkuujj±±ccyy ..ssppeecc

  Niniejszy rozdzia³ zawiera opis pliku specyfikuj±cego dla pakietu.
  Plik taki s± niezbêdne by stworzyæ pakiet.  Zawiera on opis
  oprogramowania wraz z instrukcjami instalacyjnymi oraz listê
  wszystkich plików binarnych przez niego instalowanych.

  Plik specyfikuj±cy warto jest nazwaæ zgodnie z konwencj±.  Powinno to
  wygl±daæ mniej wiêcej tak: nazwa pakietu-kreska-numer wersji-kreska-
  numer modyfikacji-kropka-spec.

  A tak wygl±da przyk³adowy plik specyfikuj±cy (eject-3.0-1.spec):

       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

  66..33..  NNaagg³³óówweekk

  Nag³ówek pliku .spec zawiera kilka standardowych pól które powinny byæ
  wype³nione. Oto znaczenie poszczególnych pól:
  ·  Summary: Jest to jednowierszowy, skrócony opis pakietu.

  ·  Name: To pole zawiera nazwê pliku rpm.  ¦ci¶le jest to string
     bêd±cy t± czê¶ci± nazwy pliku rpm która odpowiada nazwie pakietu.

  ·  Version: To pole zawiera wersjê pliku rpm.  ¦ci¶le jest to string
     bêd±cy t± czê¶ci± nazwy pliku rpm która odpowiada wersji pakietu.

  ·  Release: To pole zawiera numer modyfikacji pliku rpm. Jest to
     liczba mówi±ca z któr± modyfikacj± (podwersj±) obecnej wersji
     pakietu mamy do czynienia (tzn. je¶li dokonany w pakiecie tylko
     minimalnych poprawek b³êdów to wypuszczamy pakiet w tej samej
     wersji ale z numerem modyfikacji wiêkszym o jeden).

  ·  Icon: To pole zawiera nazwê pliku z ikon± przeznaczon± do
     wykorzystania przez narzêdzia instalacyjne wy¿szego poziomu (np.
     ``glint'' RedHat-a). Plik ten powinien byæ zapisany w formacie GIF
     i znajdowaæ siê w katalogu SOURCES.

  ·  Source: This wiersz zawiera nazwê pliku ¼ród³owego z którego jest
     budowany dany rpm.  Jest to pomocne w sytuacji gdy chce siê kiedy¶
     zajrzeæ do odpowiednich kodów ¼ród³owych lub sprawdziæ czy nie ma
     ich nowszej wersji.  Uwaga:  Nazwa pliku w tym wierszu MUSI
     odpowiadaæ nazwie pliku obecnego w Twoim systemie.  (tzn. nie
     zmieniaj nazw plików ¼ród³owych po ich ¶ci±gniêciu).  Mo¿na podaæ
     wiêcej ni¿ jeden plik ¼ród³owy pisz±c w poni¿szy sposób:

       Source0: blah-0.tar.gz
       Source1: blah-1.tar.gz
       Source2: fooblah.tar.gz

  Te pliki powinny siê znale¼æ w katalogu SOURCES.  (Struktura tego kat­
  alogu jest opisana w rozdziale "Katalogi z plikami ¼ród³owymi".)

  ·  Patch: To pole zawiera miejsce w którym bêdzie mo¿na znale¼æ
     poprawki(patch) je¶li zainstnieje potrzeba ich ponownego
     ¶ci±gniêcia.  Uwaga:  Nazwa tego pliku musi odpowiadaæ nazwie pliku
     jaki jest u¿yty do naniesienia Twoich poprawek.  Mo¿na te¿ podaæ
     wiele plików z poprawkami analogicznie do wielu plików ¼ród³owych:

       Patch0: blah-0.patch
       Patch1: blah-1.patch
       Patch2: fooblah.patch

  Te pliki powinny siê znale¼æ w katalogu SOURCES.

  ·  Copyright: Ten wiersz opisuje do jakiej kategorii ze wzglêdu na
     prawo autorskie nale¿y dane oprogramowanie. Najlepiej wykorzystaæ
     jedn± z dobrze zdefiniowanych kategorii: GPL, BSD, MIT, public
     domain, distributable, lub commercial.

  ·  BuildRoot: Ten wiersz pozwala zdefiniowaæ g³ówny katalog (``root'')
     dla tworzenia i instalacji pakietu.  Mo¿na to wykorzystaæ np. do
     testowania instalacji pakietu zanim siê go zainstaluje w docelowym
     miejscu.

  ·  Group: Ten wiersz s³u¿y do tego, by programy instalacyjne wy¿szego
     poziomu (wspomniany ``glint'') wiedzia³y w jakim miejscu ich
     hierarchicznej struktury grup pakietów umie¶ciæ dany pakiet.  W
     chwili obecnej drzewo grup pakietów wygl±da mniej wiêcej tak:

       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  Nie jest to element nag³ówka w ¶cis³ym tego s³owa
     znaczeniu ale jego opis powinien siê znale¼æ wraz z opisem
     nag³ówka. Dla ka¿dego pakietu lub subpakietu potrzebne jest jedno
     takie pole zawieraj±ce przejrzysty i zrozumia³y opis pakietu.

  66..44..  SSeekkccjjaa PPrreepp

  Jest to druga czê¶æ pliku specyfikuj±cego.  U¿ywa siê jej do
  przygotowania ¼róde³ do kompilacji/instalacji.  W niej powinny
  znajdowaæ siê wszystkie czynno¶ci niezbêdne by nanie¶æ poprawki do
  ¼róde³ i doprowadziæ je do stanu w którym bêdzie mo¿na wydaæ komendê
  make.

  Jedn± rzecz nale¿y podkre¶liæ: Ka¿da z tych czê¶ci jest tak naprawdê
  tylko miejscem do umieszczenia odpowiednich skryptów.  Mo¿esz po
  prostu napisaæ skrypt w sh a nastêpnie umie¶ciæ go po znaczniku %prep
  by rozpakowaæ i wprowadziæ poprawki do swoich programów.  By to
  u³atwiæ powsta³y specjalne makra.

  Pierwszym z nich jest makro %setup.  W swojej najprostszej formie (bez
  dodatkowych opcji w linii poleceñ), rozpakowywuje ona ¼ród³a i zmienia
  bie¿±cy katalog na katalog zawieraj±cy ¼ród³a.  Poza tym ma jednak
  dodatkowe opcje:

  ·  -n name ustawi nazwê roboczego katalogu na name.  Domy¶lnie jest to
     $NAZWA-$WERSJA.  Do innych mo¿liwo¶ci nale¿± $NAZWA,
     ${NAZWA}${WERSJA}, czy jakakolwiek inna u¿ywana przez g³ówny plik
     tar.  (Proszê zauwa¿yæ, ¿e zmienne ``$'' _n_i_e s± faktycznymi
     zmiennymi dostêpnymi wewn±trz pliku specyfikuj±cego. W
     rzeczywisto¶ci s± one tutaj u¿yte w miejsce przyk³adowej nazwy. W
     pakiecie nale¿y u¿yæ rzeczywistej nazwy i wersji, a nie zmiennej.)

  ·  -c utworzy i wejdzie do wymienionego katalogu _z_a_n_i_m zacznie siê
     rozpakowywanie poprzez untar.

  ·  -b # wykona untar (rozpakuje) Source# _z_a_n_i_m wejdzie do katalogu
     roboczego (nie ma sensu ³±czenie tej opcji z -c, a wiêc siê tego
     nie robi).  Jest to przydatne w przypadku wielu plików ¼ród³owych.

  ·  -a # wykona untar (rozpakuje) Source# _p_o wej¶ciu do katalogu.

  ·  -T Ta opcja zmienia domy¶ln± procedurê rozpakowywania  (untar)
     ¼róde³ i wymaga -b 0 lub -a 0 by g³ówny plik ¼ród³owy zosta³
     rozpakowany (untar).  Komenda ta jest potrzebna gdy u¿ywany jest
     wiêcej ni¿ jeden komplet plików ¼ród³owych.

  ·  -D _N_i_e usuwaj katalogu przed rozpakowaniem.  Jest ona przydatna
     tylko wtedy, gdy ma siê wiêcej ni¿ jedno makro konfiguracyjne.
     Powinna byæ u¿ywana _w_y_³_±_c_z_n_i_e w makrach konfiguracyjnych wy³±cznie
     _p_o wykonaniu pierwszego z nich (ale nigdy wêwn±trz pierwszego z
     nich).

  Nastêpne dostêpne makra znajduj± siê w makrze %patch.  Makro te pomaga
  zautomatyzowaæ proces nanoszenie poprawek do ¼róde³.  Mo¿liwe s±
  liczne opcje opisane poni¿ej:

  ·  # zastosuje Patch# jako plik z poprawkami.

  ·  -p # podaje liczbê katalogów do odrzucenia z nazwy przed
     wykorzystaniem polecenia patch(1)

  ·  -P Domy¶lnie stosowana jest Patch (lub Patch0).  Ta flaga wy³±cza
     to zachowanie a wiêc wymaga dodatkowo 0 by g³ówne pliki ¼ród³owe
     zosta³y rozpakowane. Opcja ta jest przydatna w drugim (b±d¼
     dalszym) makrze %patch które wymaga innego ni¿ pierwsze makro
     numeru poprawki.

  ·  Mo¿na te¿ napisaæ %patch# zamiast : %patch # -P

  To s± wszystkie makra jakich potrzebujesz. Po ich poprawnym napisaniu
  mo¿na wykonaæ dowolne inne komendy konfiguracyjne poprzez stworzenie
  odpowiednich fragmentów skryptów w sh.  Wszystko co zostanie
  umieszczone a¿ do makra %build (omawianego w nastêpnym rozdziale)
  bêdzie wykonane przez sh.  Przyk³ady powy¿ej mog± sugerowaæ rzeczy
  jakie chcia³by¶ tam umie¶ciæ.

  66..55..  SSeekkccjjaa BBuuiilldd

  Dla tej sekcji nie ma jakich¶ specjalnych makr.  Powinno siê w niej
  umieszczaæ dowolne polecenia potrzebne do stworzenia pakietu po
  rozpakowaniu ¼róde³, naniesieniu poprawek i przej¶ciu do katalogu
  roboczego. Jest to po prostu nastêpny zbiór poleceñ przekazany do sh,
  wiêc mo¿na tu u¿ywaæ dowolnych poprawnych poleceñ sh (w³±cznie z
  komentarzami).  KKaattaalloogg rroobboocczzyy nnaa ppoocczz±±ttkkuu kkaa¿¿ddeejj zz sseekkccjjii jjeesstt
  uussttaawwiiaannyy nnaa kkaattaalloogg gg³³óówwnnyy zz pplliikkaammii ¼¼rróódd³³oowwyymmii, o czym trzeba
  pamiêtaæ i w razie potrzeby przechodziæ do odpowiednich podkatalogów.

  66..66..  SSeekkccjjaa IInnssttaallll

  Tu równie¿ nie ma jakich¶ specjalnych makr. Sekcja ta powinna zawieraæ
  listê poleceñ potrzebnych do instalacji pakietu. Je¶li wykonujesz make
  install by zainstalowaæ pakiet, umie¶æ to tu.  Mo¿esz równie¿ nanie¶æ
  poprawki do makefile'a zanim wykonasz make install. Je¶li nie to
  umie¶æ tu sekwencjê poleceñ sh jakich potrzebujesz. Katalog roboczy,
  identycznie jak w poprzednim przypadku, jest ustawiany przed
  wykonaniem tych poleceñ na g³ówny katalog z plikami ¼ród³owymi.

  66..77..  OOppccjjoonnaallnnee sseekkccjjee pprree ii ppoosstt ddllaa sseekkccjjii IInnssttaallll//UUnniinnssttaallll

  Mo¿esz tu umie¶ciæ skrypty do wykonania przed i po
  instalacji/deinstalacji (tzn. sekcjami Install/Uninstall).  G³ówny
  powód to np. potrzeba wykonania komendy ldconfig po instalacji b±d¼
  usuwaniu pakietów zawieraj±cych biblioteki dzielone. Makra s±
  zdefiniowane jak poni¿ej:

  ·  %pre makro z poleceniami wykonywanymi przed sekcj± Install.

  ·  %post makro z poleceniami wykonywanymi po sekcji Install.

  ·  %preun makro z poleceniami wykonywanymi przed sekcj± Uninstall.

  ·  %postun makro z poleceniami wykonywanymi po sekcji Uninstall.

  Sekcje te mog± zawieraæ dowolne poprawne polecenia sh ( _n_i_e
  potrzebujesz wstawiaæ #!/bin/sh na pocz±tku).

  66..88..  SSeekkccjjaa FFiilleess

  W sekcji tej _m_u_s_i_s_z wypisaæ pliki jakie wchodz± w sk³ad pakietu. RPM
  nie potrafi okre¶liæ jakie pliki zostaj± zainstalowan na skutek np.
  make install.  Tego siê po prostu  _N_I_E _D_A rozs±dnie zrobiæ.  Owszem,
  by³a propozycja wykonywania polecenia find przed i po instalacji
  pakietu. Jednak w systemach wielou¿ytkownikowych nie jest to zbyt
  sensowne gdy¿ w tym samym czasie mog³o powstaæ wiele innych plików nie
  maj±cych najmniejszego zwi±zku z instalowanym pakietem.

  W tej sekcji dostêpne jest pare specjalnych makr.  S± one opisane
  poni¿ej:

  ·  %doc s³u¿y do zaznaczenia które pliki pakietu s± jego dokumentacj±.
     Dokumentacja ta zostanie umieszczona w katalogu:
     /usr/doc/$NAZWA-$WERSJA-$MODYFIKACJA.  Mo¿na zarówno podaæ nazwy
     kilku plików w linii zawieraj±cej to makro jak i podaæ te nazwy
     oddzielnie u¿ywaj±c makra dla ka¿dej z nich.

  ·  %config s³u¿y do zaznaczenia plików konfiguracyjnych w obrêbie
     pakietu. Chodzi tu o pliki typu: sendmail.cf, passwd, etc. W
     trakcie deinstalacji pliki te s± usuwane o ile nie by³y zmieniane.
     Je¶li by³y, to ich nazwa zostaje zmieniona poprzez dodanie koñcówki
     Analogicznie jak dla plików z dokumentacj± jedno makro mo¿e s³u¿yæ
     do zdefiniowania kilku takich plików.

  ·  %dir zaznacza dany katalog jako nale¿±cy do pakietu. Domy¶lnie,
     je¶li pojawi siê nazwa katalogu _B_E_Z  makra %dir, _W_S_Z_Y_S_T_K_O w tym
     katalogu jest w³±czane w liste plików i nastêpnie instalowane jako
     czê¶æ pakietu. To makro pozwala tego unikn±æ.

  ·  %files -f <filename> pozwala na w³±czenie listy plików znajduj±cej
     siê w jakim¶ pliku w obrêbie katalogu z plikami ¼ród³owymi.  Jest
     to wygodne gdy procedura instalacji buduje w³asn± listê plików
     któr± nastêpnie mo¿na w³±czyæ jedn± komend± bez podawania nazw tych
     plików.

  Najwiêksz± trudno¶ci± w li¶cie plików jest podawanie katalagów. Je¶li
  np. podasz przez pomy³kê /usr/bin, to Twój pakiet rpm bêdzie zawiera³
  _w_s_z_y_s_t_k_i_e pliki w katalogu /usr/bin w Twoim komputerze.

  66..99..  TTwwoorrzzeenniiee ppaakkiieettuu

  66..99..11..  KKaattaallooggii zz pplliikkaammii ¼¼rróódd³³oowwyymmii

  Jedn± z podstawowych rzeczy jest poprawnie skonfigurowane katalogów w
  których RPM bêdzie budowa³ pakiet.  Robi siê to poprzez plik
  /etc/rpmrc.  Wiêkszo¶æ osób u¿ywa po prostu /usr/src.

  Mo¿liwe, ¿e bêdziesz potrzebowa³ utworzyæ poni¿sze katalogi:

  ·  BUILD jest katalogiem w którym RPM buduje pakiet.  Próbne tworzenie
     pakietu mo¿esz wykonaæ w jakimkolwiek katalogu który tu podasz.

  ·  SOURCES jest katalogiem w którym powiniene¶ umie¶ciæ oryginalne
     pliki ¼ród³owe i pliki z poprawkami. Jest to miejsce do którego RPM
     bêdzie zagl±da³ domy¶lnie.

  ·  SPECS jest katalogiem w którym powinny siê znale¼æ wszystkie pliki
     specyfikuj±ce (spec).

  ·  RPMS RPM umie¶ci tu binarme pliki RPM po ich zbudowaniu.

  ·  SRPMS RPM umie¶ci to pliki RPM z plikami ¼ród³owymi.

  66..99..22..  PPrróóbbnnee ttwwoorrzzeenniiee ppaakkiieettuu

  Pierwsz± rzecz± do zroienia jest doprowadzenie plików ¼ród³owych do
  takiego stanu by kompilowa³y i/lub instalowa³y siê bez pomocy RPM-a.
  By to osi±gn±æ, rozpakuj ¼ród³a i zmieñ nazwê katalogu na $NAZWA.orig.
  Nastêpnie ponownie rozpakuj ¼ród³a i pracuj na nich.  Wejd¼ do ich
  katalogu i postêpuj zgodnie z instrukcjia ich instalacji/kompilacji.
  Je¶li bêdzie konieczna edycja jakich¶ plików to konieczne bêdzie
  wygenerowanie pliku z poprawkami (patch).  Je¶li doprowadzisz ¼ród³a
  do stanu w którym bêd± siê poprawnie instalowaæ/kompilowaæ - wyczy¶æ
  katalog ¼ród³owy.  Upewnij siê, ¿e wszystkie pliki stworzone w
  skrypcie konfiguracyjnym (configure) zosta³y usuniête.  Nastêpnie
  wyjd¼ z katalogu ¼ród³owego i wykonaj co¶ takiego:

               diff -uNr dirname.orig dirname > ../SOURCES/dirname-linux.patch

  (dirname w tym przyk³adzie to to samo co $NAZWA parê linii powy¿ej).
  Polecenie to stworzy plik z poprawkami jaki bêdzie móg³ byæ wykorzys­
  tany w pliku specyfikuj±cy.  Zauwa¿, ¿e ``linux'' w nazwie pliku z
  poprawkami jest jakim¶ wybranym identyfikatorem.  Zamiast tego mo¿na
  u¿yæ czego¶ bardziej precyzyjnego jak np. ``config'' lub ``bugs''
  (b³êdy) by opisaæ _d_l_a_c_z_e_g_o poprawki by³y potrzebne.  Przed u¿yciem
  pliku z poprawkami warto do niego zajrzeæ by siê upewniæ, ¿e przypad­
  kiem nie znalaz³o siê w nim co¶ niew³a¶ciwego jak np. pliki binarne.

  66..99..33..  TTwwoorrzzeenniiee lliissttyy pplliikkóóww

  Teraz, gdy ¼ród³a siê kompiluj± i instaluj± i wiadomo jak to robiæ to
  zrób to, skompiluj i zainstaluj.  Przyjrzyj siê wynikowi instalacji i
  stwórz w ten sposób listê plików do u¿ycia w pliku specyfikuj±cym.
  Zazwyczaj plik specyfikuj±cy powstaje równocze¶nie z opisywanymi tu
  krokami.  Po prostu tworzy siê go na pocz±tku wstawiaj±c to co jest
  znane i potem w miarê postêpu prac uzype³nia siê go o brakuj±ce
  kawa³ki.

  66..99..44..  TTwwoorrzzeenniiee ppaakkiieettuu RRPPMM

  Gdy plik specyfikuj±cy jest gotowy, mo¿na ju¿ próbowaæ tworzyæ nowy
  pakiet. Najwygodniej jest to zrobiæ poni¿szym poleceniem:

               rpm -ba foobar-1.0.spec

  Opcja -b ma parê interesuj±cyh podopcji:

  ·  p oznacza wykonanie sekcji prep pliku specyfikuj±cego.

  ·  l wykona parê ró¿nych testów na plikach %files.

  ·  c wykonaj sekcjê prep i kompiluj.  Jest to przydatne gdy jest siê
     niepewnym czy ¼ród³a w ogóle bêd± siê kompilowaæ/instalowaæ.
     Owszem, na pierwszy rzut oka mo¿e to wygl±daæ na zbêdne gdy¿ mo¿na
     dot±d pracowaæ ze ¼ród³ami a¿ bêd± siê kompilowaæ jednak gdy
     przyzwyczaisz siê do wykorzystania RPM-a to spotkasz siê z
     sytuacjami w którach ta opcja oka¿e siê przydatna.

  ·  i wykonaj prep, kompiluj i instaluj.

  ·  b prep, kompiluj, instaluj, i buduj jedynie pakiet binarny.

  ·  a zbuduj wszystko - zarówno pakiet ¼ród³owy jak i binarny.

     Jest te¿ parê dodatkowych podopcji do opcji -b:

  ·  --short-circuit przejdzie prosto do okre¶lonego etapu (mo¿e byæ
     u¿yte wy³±cznie z c oraz i)

  ·  --clean usuwa katalog ze ¼ród³ami stworzony w czasie budowania
     pakietu.

  ·  --keep-temps zachowa wszystkie pliki temporalne i skrypty które
     zosta³y umieszczone w /tmp. Jakie s± to pliki mo¿na siê dowiedzieæ
     wykorzystuj±c opcjê -v.

  ·  --test nie wykonuje ¿adnych rzeczywistych etapów choæ wykonuje
     keep-temps.

  66..1100..  TTeessttoowwaanniiee ppaakkiieettuu

  Po stworzeniu pakietu rpm ¼ród³owego i binarnego nale¿y je
  przetestowaæ. Najpro¶ciej i najlepiej jest wykorzystaæ do tego
  zupe³nie inny komputer ni¿ ten na którym pakiet by³ tworzony. W koñcu
  przy tworzeniu pakietu by³ on do¶æ czêsto instalowany i na komputerze
  na którym powstawa³ powinno byæ to zrobione do¶æ dobrze.

  Mo¿na te¿ próbowaæ rpm -u nazwapakietu.rpm na testowanym pakiecie ale
  mo¿e byæ to zdradliwe w sytuacji w której jakie¶ pliki zosta³y
  pominiête w li¶cie plików i nie zostan± wtedy usuniête.  Wtedy
  zainstalowany program bêdzie kompletny mimo tego, ¿e rpm bêdzie
  b³êdny. Pamiêtaj, ¿e poniewa¿ Ty ju¿ zrobi³e¶ rpm -ba package, to
  zdecydowana wiêkszo¶æ osób instaluj±cych Twój pakiet wykona jedynie
  rpm -i package. Upewnij siê, ¿e nie wykonujesz w sekcjach build lub
  install czego¶ co powinno byæ zrobione gdy instalowany jest wy³±cznie
  pakiet binarny.

  66..1111..  CCoo rroobbiiææ zz TTwwooiimmii nnoowwyymmii RRPPMM--aammii ??

  Gdy ju¿ stworzy³e¶ swój w³asny pakiet RPM (zak³adaj±c, ¿e nie ma ju¿
  takiego pakietu dostêpnego pod postaci± RPM) mo¿esz udostêpniæ wynik
  swojej pracy innym (zak³adaj±c ¿e to czego pakiet stworzy³e¶ mo¿e byæ
  tak udostêpniane).  By udostêpniæ, umie¶æ to na ftp.redhat.com
  <ftp://ftp.redhat.com>.

  66..1122..  CCoo tteerraazz??

  Prosimy sprawdziæ siê, ¿e nic nie zosta³o pominiête jeszcze raz
  czytaj±c rozdzia³y o "Testowaniu" i "Co robiæ z nowymi RPM-ami".
  Chcemy mieæ jako RPM wszystko co siê da ale chcemy, ¿eby by³y to dobre
  RPM-y.  Prosimy wiêc po¶wiêciæ trochê czasu na ich dok³adne
  przetestowanie i prosimy te¿ o umieszczenie ich w archiwum ftp tak, by
  ka¿dy móg³ z nich skorzystaæ.  A tak¿e, _p_r_o_s_i_m_y upewniæ siê, ¿e
  umieszczasz jedynie _b_e_z_p_³_a_t_n_e oprogramowanie.  Oprogramowanie
  komercyjne i shareware _n_i_e powinno byæ umieszczane w archiwum o ile
  nie zawieraj± klauzuli w ich prawach autorskich to dopuszczaj±cej.
  Dotyczy to np. Netscape, ssh, pgp, etc.

  77..  TTwwoorrzzeenniiee RRPPMM--óóww nnaa wwiieellee ppllaattffoorrmm..

  RPM mo¿e byæ wykorzystywany do tworzenia pakietów dla Intel i386,
  Digital Alpha pracuj±cych pod Linux, oraz Sparc. S± te¿ doniesienia o
  jego wykorzystaniu na platformach SGI i HP.  RPM ma parê cech które
  czyni± tworzenie pakietów na wiele platform prostszymi.  Pierwsz± z
  nich jest dyrektywa ``optflags'' w pliku /etc/rpmrc.  Mo¿e ona byæ
  wykorzystana do ustawienia odpowiednich opcji i flag, specyficznych
  dla architektury, potrzebnych do kompilacji b±d¼ instalacji.  Nastêpn±
  cech± u³atwiaj±c± tworzenie pakietów na wiele platform s± makra
  ``arch'' w pliku specyfikuj±cym.  Mog± one byæ wykorzystane do
  wykonania ró¿nych rzeczy zale¿nych od architektury na której pakiet
  jest instalowany. Nastêpn± tak± cech± jest dyrektywa ``Exclude'' w
  nag³ówku.

  77..11..  PPrrzzyykk³³aaddoowwyy pplliikk ssppeeccyyffiikkuujj±±ccyy ..ssppeecc

  Poni¿ej zamieszczona jest czê¶æ pliku specyfikuj±cego dla pakietu
  ``fileutils''.  Jest on przygotowany do instalacji na dwóch
  platformach: Alfach i Intelu.

       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*

  77..22..  DDyyrreekkttyywwaa ooppttffllaaggss

  W powy¿szym przyk³adzie przedstawione zosta³o u¿ycie dyrektywy
  ``optflags'' z /etc/rpmrc.  RPM_OPT_FLAGS przyjmuj± odpowiedni±
  warto¶æ w zale¿no¶ci od tego na jakiej platformie instalowany jest
  pakiet. Do pliku Makefile u¿ytego w pakiecie nale¿y nanie¶æ poprawki
  by korzysta³ z tej zmiennej zamiast standardowych opcji (np. -m486 lub
  -O2).  Mo¿esz siê zorientowaæ co powinno byæ zrobione poprzez
  zainstalowanie pakietu ¼ród³owego, jego rozpakowanie i przyjrzenie siê
  plikowi Makefile.  Nastêpnie nale¿y zajrzeæ do plików z poprawkami dla
  pliku Makefile i sprawdziæ jakie zmiany powinny byæ wprowadzone.

  77..33..  MMaakkrraa

  Makro %ifarch jest bardzo istotne dla tworzenia pakietów na wiele
  architektur.  W wiêkszo¶ci przypadków potrzebujesz nanie¶æ jedn± lub
  dwie poprawki specyficzne tylko dla jednej, konkretnej architektury. W
  takiej sytacji RPM pozwala na naniesienie poprawki wy³±cznie dla niej.

  W powy¿szym przypadku, pakiet fileutils ma poprawkê dla maszyn
  64-bitowych.  To naturalnie w chwili obecnej stosuje siê tylko do Alf.
  Tak wiêc dodajemy makro %ifarch nanosz±ce odpowiedni± poprawkê:

       %ifarch axp
       %patch1 -p1
       %endif

  To zapewni, ¿e poprawka nie bêdzie naniesiona na ¿adnej innej
  architekturze a wy³±cznie na alfach.

  77..44..  WWyy³³±±cczzaanniiee ppeewwnnyycchh ppllaattffoorrmm ww ppaakkiieettaacchh

  Mo¿na opiekowaæ siê ¼ród³owymi RPM-ami w jednym katalogu dla
  wszystkich platform. Uzyskuje siê to poprzez ``wy³±czenie'' (ang.
  exclude) pewnych pakietów z tworzenia ich dla pewnych architektur,
  tak, ¿e ci±gle mo¿liwym jest:

       rpm --rebuild /usr/src/SRPMS/*.rpm

  daj±ce w wyniku poprawne pakiety. Je¶li aplikacja nie zosta³a jeszcze
  do tej pory przeniesiona na dan± platformê to wystarczy dodaæ wiersz
  wygladaj±cy mniej wiêcej tak:

       ExcludeArch: axp

  do nag³ówka pliku specyfikuj±cego pakiet ¼ród³owy.  Nastêpnie prze­
  buduj pakiet na platformê na której ju¿ pracuje. W ten sposób uzyskuje
  siê pakiet, który kompiluje siê/tworzy siê np. na Intel-u podczas gdy
  mo¿e byæ ³atwo opuszczony na Alfie.

  77..55..  OOssttaattnniiee ppoopprraawwkkii

  Wykorzystanie RPM to tworzenia pakietów przeznaczonych na wiele
  platform jest zazwyczaj prostsze ni¿ doprowadzenie pakietu do stanu w
  którym dajê siê on na nich zainstalowaæ.  Jednak¿e w miarê jak
  powstaje wiêcej i wiêcej pakietów w postaci binarnej staje siê to
  coraz prostsze.  Je¶li przy tworzeniu pakietu zabrniesz w ¶lep±
  uliczkê to jak zwykle, rozwi±zaniem mo¿e byæ zajrzenie do kodu
  ¼ród³owego podobnego pakietu.

  88..  UUwwaaggaa oo pprraawwaacchh aauuttoorrsskkiicchh

  Poni¿szy dokument i jego zawarto¶æ s± chronione prawem autorskim.
  Rozpowszechnianie go i jego zawarto¶ci jest dozwolone tak d³ugo jak
  d³ugo jego pozostaj± one nie zmienione.  Innymi s³owy mo¿na go
  wy³±cznie przeformatowywaæ, drukowaæ i rozpowszechniaæ.