File: RPM-HOWTO.pl.html

package info (click to toggle)
doc-linux-pl 2002.06.14-2
links: PTS
area: main
in suites: etch, etch-m68k, jessie, jessie-kfreebsd, lenny, squeeze, wheezy
size: 6,900 kB
ctags: 968
sloc: makefile: 66
file content (1161 lines) | stat: -rw-r--r-- 41,836 bytes
parent folder | download | duplicates (5)
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
 <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
<META HTTP-EQUIV="content-type" content="text/html; charset=iso-8859-2">
<TITLE>Menader Pakietw RedHat-a (RPM) - Jak To Zrobi</TITLE>


</HEAD>
<BODY>
<H1>Menader Pakietw RedHat-a (RPM) - Jak To Zrobi<BR></H1>

<H2>Autor: Donnie Barnes <BR>
<A HREF="mailto:djb@redhat.com">djb@redhat.com</A><BR>
V2.0, 8 Kwietnia 1997<BR>
<B>Wersja polska: Jacek Pliszka 
<A HREF="mailto:pliszka@fuw.edu.pl">pliszka@fuw.edu.pl</A><BR> </B> </H2>
<P><HR>
<EM>Niniejszy dokument jest tumaczeniem RPM-HOWTO
i w skrcie opisuje jak co zrobi uywajc rpm-a
czyli Menadera Pakietw RedHat-a (<B>R</B>edHat <B>P</B>ackage <B>M</B>anager).
Dokument ten zosta napisany w standardzie ISO-8859-2.
Orygina tumaczenia tego dokumentu znajduje si pod adresem
<A HREF="http://www.jtz.org.pl">http://www.jtz.org.pl</A>.
http://www.jtz.org.pl a take na
<A HREF="ftp://ftp.icm.edu.pl/pub/Linux/sunsite/docs/HOWTO/">ftp://ftp.icm.edu.pl/pub/Linux/sunsite/docs/HOWTO/</A>.</EM>
<HR>
<H2><A NAME="s1">1. Wprowadzenie</A></H2>

<P>Skrt RPM pochodzi od ang.  
<B>R</B>ed Hat <B>P</B>ackage <B>M</B>anager co oznacza 
w wolnym tumaczeniu menader pakietw RedHat-a.
Jednak pomimo tego, e w nazwie znajduje si Red Hat,
to w zamierzeniu jest on systemem otwartym,
dostpnym dla kadego. Umoliwia on spakowanie
zarwno kodu rdowego jak i programw binarnych
do zwartej postaci zawierajcej dodatkowo 
informacje istotne przy zarzdzaniu oprogramowaniem.
Umoliwia to atw instalacj, odwieanie oraz
usuwanie oprogramowania. Informacja o zainstalowanym
oprogramowaniu jest atwo dostpna jako e
RPM tworzy baz danych o wszystkich pakietach
zainstalowanych w naszym systemie.
Pozwala to na szybkie sprawdzenie czy dany pakiet
jest zainstalowany, a jeli tak to co zawiera,
jaka jest jego wersja, jakie pliki zostay przez niego
w systemie zainstalowane oraz jakich innych pakietw wymaga.
Pozwala te sprawdzi do jakiego pakietu naley dany plik.
<P>Przyp. tum. rpm jest obecnie uywany zarwno
do plikw w postaci rdowej jak i binarnej. W oryginale
autor odwouj si gwnie do tej pierwszej. Jednak poniewa
obecnie czciej uywa si pakietw w postaci binarnej
to pliki z ktrych powsta rpm a ktre maj by zainstalowane
rwnie bd nazywa plikami rdowymi za proces instalacji
bd kompilacji - instalacj.
<P>
<P>Firma Red Hat Software zachca inne firmy i grupy tworzce
oprogramowanie do bliszego zapoznania si z RPM 
i wykorzystania go przy tworzeniu wasnych pakietw.
Bdc do elastycznym i atwym w uyciu, RPM
pozwala budowa nawet bardzo obszerne zbiory pakietw.
Pomimo tego, e jest to system cakowicie otwarty i dostpny,
jego autorzy chtnie wysuchaj informacji
o bdach i ewentualnych poprawkach.
(Jednak przed zgoszeniem ``bdu'' naley, tak jak zawsze,
najpierw sprawdzi czy ma si najnowsz stabiln wersj,
przejrze dokumentacj oraz przeszuka archiwa
USENET i jeli i tam nie bdzie odpowiedzi - spyta
na odpowiedniej grupie dyskusyjnej np. pl.comp.os.linux
-przyp. tum.)
Uywanie i rozpowszechnianie RPM jest wolne od opat
i regulowane Publiczn Licencj GNU - GPL
(ang. GNU Public Licence).
<P>
<P>Bardziej szczegowa dokumentacja dotyczca RPM
jest zawarta w ksice Eda Bailey'a, <EM>Maximum RPM</EM>,
ktra mona cign bd zakupi
w 
<A HREF="http://www.redhat.com">www.redhat.com</A>.
<P>
<H2><A NAME="s2">2. Do czego suy RPM?</A></H2>

<P>Na pocztku warto powiedzie co nieco o ``filozofii'' RPM.
Celem jego projektantw byo umoliwienie uycia
pierwotnych kodw rdowych. Zanim powsta RPM,
jego autorzy uywali RPP (przy czym podkrelaj,
e RPM <EM>nie</EM> nie jest na nim oparty ), w ktrym udostpniano
poprawione kody rdowe, konkretnie te, ktre byy
uywane do instalacji.
Teoretycznie mogoby to wystarczy, bo mona
byo zainstalowa pakiet rdowy RPP i skompilowa
go (poleceniem <CODE>make</CODE>) bez wikszych problemw.
Jednake nie byy to oryginalne rda i trudno
byo na pierwszy rzut oka powiedzie co w nich zostao zmienione.
Niezbdnym byo cignicie rwnie oryginalnych
rde.
RPM za zawiera oryginalne rda wraz z poprawkami
ktrych dokonano. W opinii autorw rozwizanie
to jest znacznie lepsze. Dlaczego?
<P>Z paru powodw. Po pierwsze, jeli pojawi si nowa
wersja programu to nie zaczynamy od zera. Niektre
poprawki, ktre byy dobre dla poprzedniej wersji,
mog by waciwe, najwyej po minimalnych zmianach 
i dla obecnej. By si o tym przekona,
wystarczy do nich zajrze.
Poza tym wszystkie domylne opcje potrzebne
do instalacji s w ten sposb atwo dostpne.
<P>
<P>
<P>Poza tym RPM zaprojektowano tak, aby umoliwi
sprawdzanie wielu istotnych informacji dotyczcych
zarwno pojedyczego, konkretnego pakietu jak
i ich zestawu
bd te wszystkich pakietw zainstalowanych w danym systemie.
Przykadem takiej informacji jest lista pakietw, ktrych
dany pakiet wymaga wraz z numerami wersji.
Moliwe jest rwnie sprawdzenie z jakiego pakietu
pochodzi konkretny plik oraz gdzie mona znale
jego wersj rdow.
Pliki RPM s ju wewntrznie spakowane, ale sprawdzanie
informacji dotyczcych konkretnego pakietu jest
proste i <EM>szybkie</EM> dziki specjalnemu binarnemu nagwkowi
ktry zawiera praktycznie wszystkie niezbdne informacje
o pakiecie. 
<P>
<P>Innym atutem RPM jest umiejtno weryfikacji  pakietw.
Jeli boisz si, e skasowae jaki wany plik,
to moesz to po prostu sprawdzi. RPM poinformuje Ci
o wykrytych nieprawidowociach. Jeli zajdzie
potrzeba, to moesz atwo odnowi zainstalowany pakiet
przy czym Twoje pliki konfiguracyjne zostan zachowane.
Oczywicie moesz te zainstalowa je od nowa.
<P>
<P>
<P>Autorzy chc podzikowa grupie ludzi od dystrybucji BOGUS
za wiele ich idei i pomysw ktre wykorzystano w RPM.
Gdy o ile RPM zosta napisany w caoci przez Red Hat Software,
to zasady jego dziaania s oparte na kodzie stworzonym
przez BOGUS (PM oraz PMS).
<P>
<H2><A NAME="s3">3. Informacje oglne</A></H2>

<P>
<H2>3.1 Skd wzi RPM?</H2>

<P>Najprostszym sposobem jest instalacja Linux-a Red Hat.
Jeli kto nie chce tego robi to moe uywa RPM
bez tego. W Polsce RPM jest dostpny np. pod adresem:
<A HREF="ftp://ftp.icm.edu.pl/pub/redhat/code/rpm">ftp.icm.edu.pl</A> - polskim mirrorze ftp.redhat.com.
<P>
<H2>3.2 Wymagania RPM </H2>

<P>Podstawowym wymaganiem RPM-a jest cpio o numerze wersji 2.4.2 
lub wyszym. Mimo e RPM jest pomylany do pracy
pod Linux-em to rwnie moe by przeniesiony na
inne systemy Unix. W rzeczywistoci udao si go ju
uruchomi pod SunOS, Solaris, AIX, Irix, AmigaOS
i wieloma innymi systemami.
Jednak naley pamita, e pakiety binarne stworzone
na rnych Unix-ach mog nie by ze sob zgodne.
<P>
<P>S to minimalne wymagania by zainstalowa RPM-y.
By tworzy RPM-y z kodu rdowego potrzebne
jest rwnie wszystko to co normalnie jest
wymagane przy tworzeniu pakietu np.
<CODE>gcc</CODE>, <CODE>make</CODE>, itd.
<P>
<H2><A NAME="s4">4. Uywanie RPM</A></H2>

<P>Najprostszym wykorzystaniem RPM jest instalacja
nowego pakietu:
<BLOCKQUOTE><CODE>
<PRE>
        rpm -i foobar-1.0-1.i386.rpm
</PRE>
</CODE></BLOCKQUOTE>

Rwnie proste jest jego odinstalowanie:
<BLOCKQUOTE><CODE>
<PRE>
        rpm -e foobar
</PRE>
</CODE></BLOCKQUOTE>
<P>Przykadem bardziej zoonego, ale <EM> bardzo</EM>
uytecznego polecenia jest instalacja pakietw
poprzez FTP. Jeli jeste podczony do sieci
i chcesz zainstalowa nowy pakiet, to wszystko
co musisz zrobi to poda nazw pliku jako poprawny URL, np.:
<BLOCKQUOTE><CODE>
<PRE>
        rpm -i ftp://ftp.pht.com/pub/linux/redhat/rh-2.0-beta/RPMS/foobar-1.0-1.i386.rpm
</PRE>
</CODE></BLOCKQUOTE>
<P>Chciabym podkreli, e w tym przypadku RPM 
sprawdzi bd zainstaluje pakiet poprzez FTP.
<P>Byy to w miar proste polecenia, lecz rpm moe by
uyty na wiele wicej sposobw jak mona si atwo
przekona piszc w linii komend 
<BLOCKQUOTE><CODE>
<PRE>
        rpm
</PRE>
</CODE></BLOCKQUOTE>

i naciskajc Enter:
<BLOCKQUOTE><CODE>
<PRE>
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 &lt;dir>]
       rpm {--install -i} [-v] [--hash -h] [--percent] [--force] [--test]
                        [--replacepkgs] [--replacefiles] [--root &lt;dir>]
                        [--excludedocs] [--includedocs] [--noscripts]
                        [--rcfile &lt;file>] [--ignorearch] [--dbpath &lt;dir>]
                        [--prefix &lt;dir>] [--ignoreos] [--nodeps]
                        [--ftpproxy &lt;host>] [--ftpport &lt;port>]
                        file1.rpm ... fileN.rpm
       rpm {--upgrade -U} [-v] [--hash -h] [--percent] [--force] [--test]
                        [--oldpackage] [--root &lt;dir>] [--noscripts]
                        [--excludedocs] [--includedocs] [--rcfile &lt;file>]
                        [--ignorearch]  [--dbpath &lt;dir>] [--prefix &lt;dir>] 
                        [--ftpproxy &lt;host>] [--ftpport &lt;port>]
                        [--ignoreos] [--nodeps] file1.rpm ... fileN.rpm
       rpm {--query -q} [-afpg] [-i] [-l] [-s] [-d] [-c] [-v] [-R]
                        [--scripts] [--root &lt;dir>] [--rcfile &lt;file>]
                        [--whatprovides] [--whatrequires] [--requires]
                        [--ftpuseport] [--ftpproxy &lt;host>] [--ftpport &lt;port>]
                        [--provides] [--dump] [--dbpath &lt;dir>] [targets]
       rpm {--verify -V -y} [-afpg] [--root &lt;dir>] [--rcfile &lt;file>]
                        [--dbpath &lt;dir>] [--nodeps] [--nofiles] [--noscripts]
                        [--nomd5] [targets]
       rpm {--setperms} [-afpg] [target]
       rpm {--setugids} [-afpg] [target]
       rpm {--erase -e} [--root &lt;dir>] [--noscripts] [--rcfile &lt;file>]
                        [--dbpath &lt;dir>] [--nodeps] [--allmatches]
                        package1 ... packageN
       rpm {-b|t}[plciba] [-v] [--short-circuit] [--clean] [--rcfile  &lt;file>]
                        [--sign] [--test] [--timecheck &lt;s>] specfile
       rpm {--rebuild} [--rcfile &lt;file>] [-v] source1.rpm ... sourceN.rpm
       rpm {--recompile} [--rcfile &lt;file>] [-v] source1.rpm ... sourceN.rpm
       rpm {--resign} [--rcfile &lt;file>] package1 package2 ... packageN
       rpm {--addsign} [--rcfile &lt;file>] package1 package2 ... packageN
       rpm {--checksig -K} [--nopgp] [--nomd5] [--rcfile &lt;file>]
                           package1 ... packageN
       rpm {--rebuilddb} [--rcfile &lt;file>] [--dbpath &lt;dir>]
       rpm {--querytags}
</PRE>
</CODE></BLOCKQUOTE>
<P>Wszystkie te opcje s opisane 
w podrczniku systemowym "man" dotyczcym RPM. 
<P>
<H2><A NAME="s5">5. A co tak <EM>naprawd</EM> mona zrobi z RPM?</A></H2>

<P>RPM jest bardzo wygodnym narzdziem i 
jak mona byo si przekona, ma sporo opcji.
Najlepsz metod zapoznania si z nimi s przykady.
<P>Pokazaem ju najprostsz instalacj i usuwanie pakietw,
czas na troch ciekawsze przykady:
<UL>
<LI> W praktyce instalujc pakiet
chce si usunc jego star wersj (opcja -U od ang. upgrade). Czsto chcemy
rwnie widzie postp instalacji (-h od ang. hash) oraz
dosta poszerzone komunikaty o bdach (-v od ang. verbose),
tak wic praktycznie najczciej pakiety instaluje si
poprzez:
<BLOCKQUOTE><CODE>
<PRE>
        rpm -Uhv foobar-1.0-1.i386.rpm
</PRE>
</CODE></BLOCKQUOTE>
</LI>
<LI>Powiedzmy, e skasowae przypadkiem jakie pliki,
niestety, nie znasz nawet ich nazw.
Jeli wic chcesz zweryfikowa cay system i
sprawdzi czego moe brakowa, zrb tak:
<BLOCKQUOTE><CODE>
<PRE>
rpm -Va
</PRE>
</CODE></BLOCKQUOTE>

(od ang. Verify all)</LI>
<LI>Powiedzmy, e natkne si na plik, ktrego nie znasz.
eby sprawdzi do jakiego pakietu naley, zrb:
<BLOCKQUOTE><CODE>
<PRE>
rpm -qf /usr/X11R6/bin/xjewel
</PRE>
</CODE></BLOCKQUOTE>

(od ang. query file).
W wyniku otrzymasz nazw pakietu:
<BLOCKQUOTE><CODE>
<PRE>
xjewel-1.6-1
</PRE>
</CODE></BLOCKQUOTE>

</LI>
<LI>Natkne si na jaki plik RPM i chciaby sprawdzi
co jest w rodku. Zrb tak:
<BLOCKQUOTE><CODE>
<PRE>
rpm -qpi koules-1.2-2.i386.rpm
</PRE>
</CODE></BLOCKQUOTE>

Wywietli Ci si co takiego:
<BLOCKQUOTE><CODE>
<PRE>
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.
</PRE>
</CODE></BLOCKQUOTE>

(od ang. query package info).</LI>
<LI>A teraz chciaby sprawdzi jakie pliki wchodz w skad 
tego pakietu:
<BLOCKQUOTE><CODE>
<PRE>
rpm -qpl koules-1.2-2.i386.rpm
</PRE>
</CODE></BLOCKQUOTE>

W wyniku otrzymasz ich list:
<BLOCKQUOTE><CODE>
<PRE>
/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
</PRE>
</CODE></BLOCKQUOTE>

(od ang. query package list)</LI>
<LI> Chcesz wywietli list pakietw zainstalowanych
w Twoim systemie? Nic prostszego:
<BLOCKQUOTE><CODE>
<PRE>
rpm -qa
</PRE>
</CODE></BLOCKQUOTE>

(od ang. query all).</LI>
<LI> Chcesz sprawdzi czy pakiet jest kompletny,
nie przekamany i mam poprawny podpis PGP?
<BLOCKQUOTE><CODE>
<PRE>
rpm -K -vv pakiet.rpm
</PRE>
</CODE></BLOCKQUOTE>
</LI>
</UL>
<P>To byo tylko par przykadw, wicej znajdziesz np. w man-ie. 
Na pewno wpadniesz na ciekawsze w miar jak bdziesz lepiej 
poznawa RPM.
<P>
<H2><A NAME="s6">6. Tworzenie rpm-w.</A></H2>

<P>Tworzenie rpm-w jest do proste,
szczeglnie jeli oprogramowanie ktre chcesz
w nie woy poprawnie si instaluje.
<P>Procedura tworzenia RPM-w wyglda tak:
<UL>
<LI>Upewnij si, e plik <CODE>/etc/rpmrc</CODE> 
jest obecny i poprawnie skonfigurowany w Twoim systemie.</LI>
<LI>Doprowad to tego, e pliki rdowe dla ktrych
tworzysz rpm poprawnie si instaluj.</LI>
<LI>Przygotuj list poprawek jakich musiae
dokona by kod kompilowa si poprawnie.</LI>
<LI>Przygotuj plik specyfikujcy (.spec) dla Twojego pakietu.</LI>
<LI>Upewnij si, e wszystko jest na swoim miejscu.</LI>
<LI>Zbuduj pakiet uywajc rpm.</LI>
</UL>
<P>Zazwyczaj RPM tworzy zarwno pakiety binarne jak i rdowe.
<P>
<H2>6.1 Plik rpmrc </H2>

<P>W chwili obecnej, jedyny sposb konfiguracji RPM-a
jest dostpny poprzez plik <CODE>/etc/rpmrc</CODE>.  
Przykadowy plik wyglda tak:
<BLOCKQUOTE><CODE>
<PRE>
require_vendor: 1
distribution: Moja wasna dystrybucja!
require_distribution: 1
topdir: /usr/src/me
vendor: Kubusoft
packager: Pakujcy RPM w Kubusoft &lt;pakiety@kubusoft.com.pl>

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

signature: pgp
pgp_name: Pakujcy RPM w Kubusoft
pgp_path: /home/pakiety/.pgp

tmppath: /usr/tmp
</PRE>
</CODE></BLOCKQUOTE>
<P>Wiersz <CODE>require_vendor</CODE> zmusza RPM-a do szukania
wiersza z nazw producenta pakietw (vendor). 
Ta moe pochodzi z pliku <CODE>/etc/rpmrc</CODE> 
lub z nagwka pliku .spec.  
By wyczy t opcj, zmie liczb na <CODE>0</CODE>.  
Analogicznie jest w przypadku wierszy
<CODE>require_distribution</CODE> oraz
<CODE>require_group</CODE>.
<P>Nastpnym wiersz zawiera  <CODE>distribution</CODE>
i okrela nazw dystrybucji.  
Moesz j zdefiniowa tutaj, bd pniej,
w nagwku pliku specyfikujcego.
Tworzc pakiet dla konkretnej dystrybucji warto zadba
by wiersz ten zawiera poprawn informacj,
nawet pomimo tego, e nie jest wymagany.
Tyczy si to rwnie wiersza <CODE>vendor</CODE> (producent),
cho nazwa moe by zupenie dowolna
(np. Joe's Software, Rock Music Emporium).
<P>RPM pozwala rwnie tworzy pakiety dla rnych platform
sprztowych.
Plik <CODE>rpmrc</CODE> moe zawiera zmienn ``optflags''
wykorzystywan przy building budowaniu tych elementw pakietu,
ktre wymagaj opcji zalenych od platformy.
Dokadniejszy opis tej zmiennej pojawi si w jednym
z nastpnych rodziaw.
<P>Nie s to oczywicie wszystkie etykiety/makra.
Jest ich wicej. By si im przyjrze sprbuj komendy:
<BLOCKQUOTE><CODE>
<PRE>
rpm --showrc
</PRE>
</CODE></BLOCKQUOTE>

ktra powinna wypisa wszystkie moliwe etykiety
wraz z ich wartociami (o ile s ustawione).
<P>
<H2>6.2 Plik specyfikujcy .spec</H2>

<P>Niniejszy rozdzia zawiera opis pliku specyfikujcego dla
pakietu. Plik taki s niezbdne by stworzy pakiet.
Zawiera on opis oprogramowania wraz z instrukcjami
instalacyjnymi oraz list wszystkich plikw binarnych
przez niego instalowanych.
<P>Plik specyfikujcy warto jest nazwa zgodnie z konwencj.
Powinno to wyglda mniej wicej tak:
nazwa pakietu-kreska-numer wersji-kreska-numer modyfikacji-kropka-spec.
<P>A tak wyglda przykadowy plik specyfikujcy (eject-3.0-1.spec):
<BLOCKQUOTE><CODE>
<PRE>
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
</PRE>
</CODE></BLOCKQUOTE>
<P>
<H2>6.3 Nagwek</H2>

<P>Nagwek pliku .spec zawiera kilka standardowych pl ktre powinny by wypenione. Oto znaczenie poszczeglnych pl:
<P>
<UL>
<LI><CODE>Summary:</CODE> Jest to jednowierszowy,
skrcony opis pakietu. </LI>
<LI><CODE>Name:</CODE> To pole zawiera nazw pliku rpm.
cile jest to string bdcy t czci nazwy pliku 
rpm ktra odpowiada nazwie pakietu.</LI>
<LI><CODE>Version:</CODE> To pole zawiera wersj pliku rpm.
cile jest to string bdcy t czci nazwy pliku
rpm ktra odpowiada wersji pakietu.</LI>
<LI><CODE>Release:</CODE> To pole zawiera numer modyfikacji 
pliku rpm. Jest to liczba mwica z ktr
modyfikacj (podwersj) obecnej wersji pakietu
mamy do czynienia (tzn. jeli dokonany w pakiecie
tylko minimalnych poprawek bdw to wypuszczamy
pakiet w tej samej wersji ale z numerem modyfikacji
wikszym o jeden).</LI>
<LI><CODE>Icon:</CODE> To pole zawiera nazw pliku z ikon
przeznaczon do wykorzystania przez narzdzia
instalacyjne wyszego poziomu 
(np. ``glint'' RedHat-a). Plik ten powinien by
zapisany w formacie GIF i znajdowa si w
katalogu SOURCES.</LI>
<LI><CODE>Source:</CODE> This wiersz zawiera nazw
pliku rdowego z ktrego jest budowany dany rpm. 
Jest to pomocne w sytuacji gdy chce si kiedy
zajrze do odpowiednich kodw rdowych 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 plikw rdowych po 
ich cigniciu).  Mona poda wicej ni jeden
plik rdowy piszc w poniszy sposb:
<BLOCKQUOTE><CODE>
<PRE>
Source0: blah-0.tar.gz
Source1: blah-1.tar.gz
Source2: fooblah.tar.gz
</PRE>
</CODE></BLOCKQUOTE>

Te pliki powinny si znale w katalogu <CODE>SOURCES</CODE>. 
(Struktura tego katalogu jest opisana w rozdziale
"Katalogi z plikami rdowymi".)</LI>
<LI><CODE>Patch:</CODE> To pole zawiera miejsce w ktrym
bdzie mona znale poprawki(patch) jeli
zainstnieje potrzeba ich ponownego cignicia.
Uwaga:  Nazwa tego pliku musi odpowiada nazwie pliku
jaki jest uyty do naniesienia Twoich poprawek.
Mona te poda wiele plikw z poprawkami analogicznie
do wielu plikw rdowych:
<BLOCKQUOTE><CODE>
<PRE>
Patch0: blah-0.patch
Patch1: blah-1.patch
Patch2: fooblah.patch
</PRE>
</CODE></BLOCKQUOTE>

Te pliki powinny si znale w katalogu <CODE>SOURCES</CODE>.</LI>
<LI><CODE>Copyright:</CODE> Ten wiersz opisuje do jakiej
kategorii ze wzgldu na prawo autorskie naley
dane oprogramowanie. Najlepiej
wykorzysta jedn z dobrze zdefiniowanych kategorii:
GPL, BSD, MIT, public domain, distributable, 
lub commercial.</LI>
<LI><CODE>BuildRoot:</CODE> Ten wiersz pozwala zdefiniowa
gwny katalog (``root'') dla tworzenia i instalacji pakietu.
Mona to wykorzysta np. do testowania instalacji pakietu
zanim si go zainstaluje w docelowym miejscu.</LI>
<LI><CODE>Group:</CODE> Ten wiersz suy do tego, by
programy instalacyjne wyszego poziomu (wspomniany 
``glint'') wiedziay w jakim miejscu ich hierarchicznej
struktury grup pakietw umieci dany pakiet. 
W chwili obecnej drzewo grup pakietw wyglda
mniej wicej tak:
<BLOCKQUOTE><CODE>
<PRE>
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
</PRE>
</CODE></BLOCKQUOTE>

</LI>
<LI><CODE>%description</CODE>  Nie jest to element nagwka 
w cisym tego sowa znaczeniu ale jego opis powinien si znale
wraz z opisem nagwka. Dla kadego pakietu lub subpakietu
potrzebne jest jedno takie pole zawierajce przejrzysty
i zrozumiay opis pakietu.
</LI>
</UL>
<P>
<H2>6.4 Sekcja Prep</H2>

<P>Jest to druga cz pliku specyfikujcego.
Uywa si jej do przygotowania rde do kompilacji/instalacji.
W niej powinny znajdowa si wszystkie czynnoci
niezbdne by nanie poprawki do rde i doprowadzi
je do stanu w ktrym bdzie mona wyda komend <CODE>make</CODE>.
<P>Jedn rzecz naley podkreli:  
Kada z tych czci jest tak naprawd tylko miejscem
do umieszczenia odpowiednich skryptw.  
Moesz po prostu napisa skrypt w <CODE>sh</CODE> 
a nastpnie umieci go po znaczniku <CODE>%prep</CODE>
by rozpakowa i wprowadzi poprawki do swoich programw. 
By to uatwi powstay specjalne makra.
<P>Pierwszym z nich jest makro <CODE>%setup</CODE>.  
W swojej najprostszej formie 
(bez dodatkowych opcji w linii polece), 
rozpakowywuje ona rda i zmienia biecy katalog
na katalog zawierajcy rda. 
Poza tym ma jednak dodatkowe opcje:
<UL>
<LI><CODE>-n name</CODE> ustawi nazw roboczego katalogu na <CODE>name</CODE>.
Domylnie jest to <CODE>$NAZWA-$WERSJA</CODE>.  
Do innych moliwoci nale <CODE>$NAZWA</CODE>, 
<CODE>${NAZWA}${WERSJA}</CODE>,
czy jakakolwiek inna uywana przez gwny plik tar. 
(Prosz zauway, e zmienne ``$'' <EM>nie</EM>  
s faktycznymi zmiennymi dostpnymi wewntrz pliku
specyfikujcego. W rzeczywistoci s one tutaj uyte
w miejsce przykadowej nazwy. W pakiecie naley uy
rzeczywistej nazwy i wersji, a nie zmiennej.)</LI>
<LI><CODE>-c</CODE> utworzy i wejdzie do 
wymienionego katalogu <EM>zanim</EM> zacznie si rozpakowywanie 
poprzez untar.</LI>
<LI><CODE>-b #</CODE> wykona untar (rozpakuje) Source# <EM>zanim</EM> wejdzie do katalogu roboczego 
(nie ma sensu czenie tej opcji z <CODE>-c</CODE>, a wic si tego nie robi).  
Jest to przydatne w przypadku wielu plikw 
rdowych.</LI>
<LI><CODE>-a #</CODE> wykona untar (rozpakuje) Source# <EM>po</EM> wejciu do katalogu.</LI>
<LI><CODE>-T</CODE> Ta opcja zmienia domyln procedur
rozpakowywania  (untar) rde i wymaga <CODE>-b 0</CODE> lub 
<CODE>-a 0</CODE> by gwny plik rdowy zosta rozpakowany (untar).
Komenda ta jest potrzebna gdy uywany jest wicej ni jeden
komplet plikw rdowych.</LI>
<LI><CODE>-D</CODE> <EM>Nie</EM> usuwaj katalogu przed 
rozpakowaniem.
Jest ona przydatna tylko wtedy, gdy ma si wicej ni
jedno makro konfiguracyjne.
Powinna by uywana <EM>wycznie</EM> w makrach konfiguracyjnych
wycznie <EM>po</EM> wykonaniu pierwszego z nich 
(ale nigdy wwntrz pierwszego z nich).</LI>
</UL>
<P>Nastpne dostpne makra znajduj si w makrze <CODE>%patch</CODE>.  
Makro te pomaga zautomatyzowa proces nanoszenie poprawek
do rde.
Moliwe s liczne opcje opisane poniej:
<UL>
<LI><CODE>#</CODE> zastosuje Patch# 
jako plik z poprawkami.</LI>
<LI><CODE>-p #</CODE> podaje liczb katalogw 
do odrzucenia z nazwy przed wykorzystaniem polecenia patch(1)</LI>
<LI><CODE>-P</CODE> Domylnie stosowana jest 
<CODE>Patch</CODE> (lub
<CODE>Patch0</CODE>).  Ta flaga wycza to zachowanie a wic wymaga
dodatkowo <CODE>0</CODE> by gwne pliki rdowe zostay
rozpakowane. Opcja ta 
jest przydatna w drugim (bd dalszym) makrze
<CODE>%patch</CODE> ktre wymaga innego ni pierwsze makro
numeru poprawki.</LI>
<LI> Mona te napisa <CODE>%patch#</CODE> 
zamiast : <CODE>%patch # -P</CODE></LI>
</UL>
<P>To s wszystkie makra jakich potrzebujesz. Po ich poprawnym
napisaniu mona wykona dowolne inne komendy konfiguracyjne
poprzez stworzenie odpowiednich fragmentw skryptw w <CODE>sh</CODE>. 
Wszystko co zostanie umieszczone a do makra <CODE>%build</CODE> 
(omawianego w nastpnym rozdziale) bdzie wykonane przez <CODE>sh</CODE>.
Przykady powyej mog sugerowa rzeczy jakie chciaby
tam umieci.
<P>
<H2>6.5 Sekcja Build</H2>

<P>Dla tej sekcji nie ma jakich specjalnych makr.
Powinno si w niej umieszcza dowolne polecenia
potrzebne do stworzenia pakietu po rozpakowaniu
rde, naniesieniu poprawek i przejciu do katalogu
roboczego. Jest to po prostu nastpny zbir polece
przekazany do <CODE>sh</CODE>, wic mona tu uywa
dowolnych poprawnych polece <CODE>sh</CODE> (wcznie z komentarzami).
<B>Katalog roboczy na pocztku kadej z sekcji jest 
ustawiany na katalog gwny z plikami rdowymi</B>,
o czym trzeba pamita i w razie potrzeby przechodzi
do odpowiednich podkatalogw.
<P>
<H2>6.6 Sekcja Install</H2>

<P>Tu rwnie nie ma jakich specjalnych makr. Sekcja
ta powinna zawiera list polece potrzebnych 
do instalacji pakietu. Jeli wykonujesz
<CODE>make install</CODE> by zainstalowa pakiet, umie to tu.  
Moesz rwnie nanie poprawki do makefile'a zanim
wykonasz <CODE>make install</CODE>. Jeli nie to umie tu sekwencj
polece <CODE>sh</CODE> jakich potrzebujesz. Katalog roboczy,
identycznie jak w poprzednim przypadku, jest ustawiany
przed wykonaniem tych polece na gwny katalog z plikami 
rdowymi.
<P>
<H2>6.7 Opcjonalne sekcje pre i post dla sekcji Install/Uninstall</H2>

<P>Moesz tu umieci skrypty do wykonania przed i po
instalacji/deinstalacji (tzn. sekcjami Install/Uninstall).
Gwny powd to np. potrzeba wykonania komendy <CODE>ldconfig</CODE> 
po instalacji bd usuwaniu pakietw zawierajcych biblioteki
dzielone. Makra s zdefiniowane jak poniej:
<UL>
<LI><CODE>%pre</CODE> 
makro z poleceniami wykonywanymi przed sekcj Install.</LI>
<LI><CODE>%post</CODE> 
makro z poleceniami wykonywanymi po sekcji Install.</LI>
<LI><CODE>%preun</CODE> 
makro z poleceniami wykonywanymi przed sekcj Uninstall.</LI>
<LI><CODE>%postun</CODE> 
makro z poleceniami wykonywanymi po sekcji Uninstall.</LI>
</UL>
<P>Sekcje te mog zawiera dowolne poprawne polecenia <CODE>sh</CODE>
( <EM>nie</EM> potrzebujesz wstawia <CODE>#!/bin/sh</CODE>
na pocztku).
<P>
<H2>6.8 Sekcja Files</H2>

<P>W sekcji tej <EM>musisz</EM> wypisa pliki jakie wchodz
w skad pakietu. RPM nie potrafi okreli jakie pliki
zostaj zainstalowan na skutek np. <CODE>make install</CODE>.  
Tego si po prostu  <EM>NIE DA</EM> rozsdnie zrobi.
Owszem, bya propozycja wykonywania polecenia <CODE>find</CODE> 
przed i po instalacji pakietu. Jednak w systemach
wielouytkownikowych nie jest to zbyt sensowne gdy
w tym samym czasie mogo powsta wiele innych plikw nie
majcych najmniejszego zwizku z instalowanym pakietem.
<P>W tej sekcji dostpne jest pare specjalnych makr.
S one opisane poniej:
<UL>
<LI><CODE>%doc</CODE> suy do zaznaczenia ktre pliki
pakietu s jego dokumentacj. Dokumentacja ta zostanie
umieszczona w katalogu:  
<CODE>/usr/doc/$NAZWA-$WERSJA-$MODYFIKACJA</CODE>.
Mona zarwno poda nazwy kilku plikw w linii zawierajcej
to makro jak i poda te nazwy oddzielnie uywajc makra
dla kadej z nich.</LI>
<LI><CODE>%config</CODE> suy do zaznaczenia plikw
konfiguracyjnych w obrbie pakietu. Chodzi tu o pliki typu:
sendmail.cf, passwd, etc. W trakcie deinstalacji pliki
te s usuwane o ile nie byy zmieniane. Jeli byy,
to ich nazwa zostaje zmieniona poprzez dodanie kocwki
<CODE>.rpmsave</CODE>.
Analogicznie jak dla plikw z dokumentacj jedno makro
moe suy do zdefiniowania kilku takich plikw.</LI>
<LI><CODE>%dir</CODE> zaznacza dany katalog jako 
nalecy do pakietu. Domylnie, jeli pojawi si
nazwa katalogu <EM>BEZ</EM>  makra <CODE>%dir</CODE>, <EM>WSZYSTKO</EM>
w tym katalogu jest wczane w liste plikw i nastpnie instalowane jako cz pakietu. To makro pozwala tego unikn.</LI>
<LI><CODE>%files -f &lt;filename&gt;</CODE> pozwala
na wczenie listy plikw znajdujcej si w jakim
pliku w obrbie katalogu z plikami rdowymi.
Jest to wygodne gdy procedura instalacji buduje
wasn list plikw ktr nastpnie mona wczy jedn komend
bez podawania nazw tych plikw.</LI>
</UL>
<P> Najwiksz trudnoci w licie plikw jest podawanie
katalagw. Jeli np. podasz przez pomyk  
<CODE>/usr/bin</CODE>, to Twj pakiet rpm bdzie zawiera
<EM>wszystkie</EM> pliki w katalogu <CODE>/usr/bin</CODE> 
w Twoim komputerze. 
<P>
<H2>6.9 Tworzenie pakietu</H2>

<P>
<H3>Katalogi z plikami rdowymi</H3>

<P>Jedn z podstawowych rzeczy jest poprawnie skonfigurowane
katalogw w ktrych RPM bdzie budowa pakiet.
Robi si to poprzez plik <CODE>/etc/rpmrc</CODE>. 
Wikszo osb uywa po prostu <CODE>/usr/src</CODE>.
<P>Moliwe, e bdziesz potrzebowa utworzy ponisze katalogi:
<UL>
<LI><CODE>BUILD</CODE> jest katalogiem w ktrym RPM buduje pakiet.
Prbne tworzenie pakietu moesz wykona w jakimkolwiek
katalogu ktry tu podasz.</LI>
<LI><CODE>SOURCES</CODE> jest katalogiem w ktrym powiniene umieci 
oryginalne pliki rdowe i pliki z poprawkami. Jest to miejsce
do ktrego RPM bdzie zaglda domylnie.</LI>
<LI><CODE>SPECS</CODE> jest katalogiem w ktrym powinny si znale
wszystkie pliki specyfikujce (spec).</LI>
<LI><CODE>RPMS</CODE> RPM umieci tu binarme pliki RPM
po ich zbudowaniu.</LI>
<LI><CODE>SRPMS</CODE> RPM umieci to pliki RPM z plikami rdowymi.</LI>
</UL>
<P>
<H3>Prbne tworzenie pakietu</H3>

<P>Pierwsz rzecz do zroienia jest doprowadzenie plikw rdowych
do takiego stanu by kompiloway i/lub instaloway si
bez pomocy RPM-a. By to osign, rozpakuj rda 
i zmie nazw katalogu na $NAZWA.orig.
Nastpnie ponownie rozpakuj rda i pracuj na nich.
Wejd do ich katalogu i postpuj zgodnie z instrukcjia
ich instalacji/kompilacji. Jeli bdzie konieczna edycja
jakich plikw to konieczne bdzie wygenerowanie
pliku z poprawkami (patch).
Jeli doprowadzisz rda do stanu w ktrym bd si
poprawnie instalowa/kompilowa - wyczy katalog rdowy.
Upewnij si, e wszystkie pliki stworzone w skrypcie
konfiguracyjnym (<CODE>configure</CODE>) zostay usunite.  
Nastpnie wyjd z katalogu rdowego i wykonaj co
takiego:
<BLOCKQUOTE><CODE>
<PRE>
        diff -uNr dirname.orig dirname > ../SOURCES/dirname-linux.patch
</PRE>
</CODE></BLOCKQUOTE>

(dirname w tym przykadzie to to samo co $NAZWA
par linii powyej).
Polecenie to stworzy plik z poprawkami jaki bdzie
mg by wykorzystany w pliku specyfikujcy.
Zauwa, e ``linux'' w nazwie pliku z poprawkami
jest jakim wybranym identyfikatorem.
Zamiast tego mona uy czego bardziej precyzyjnego
jak np. ``config'' lub ``bugs'' (bdy) by opisa <EM>dlaczego</EM> 
poprawki byy potrzebne.
Przed uyciem pliku z poprawkami warto do niego zajrze
by si upewni, e przypadkiem nie znalazo si w nim co
niewaciwego jak np. pliki binarne.
<P>
<H3>Tworzenie listy plikw</H3>

<P>Teraz, gdy rda si kompiluj i instaluj i wiadomo
jak to robi to zrb to, skompiluj i zainstaluj.
Przyjrzyj si wynikowi instalacji i stwrz w ten
sposb list plikw do uycia w pliku specyfikujcym.
Zazwyczaj plik specyfikujcy powstaje rwnoczenie
z opisywanymi tu krokami.
Po prostu tworzy si go na pocztku wstawiajc to co jest znane
i potem w miar postpu prac uzypenia si go o brakujce 
kawaki. 
<P>
<H3>Tworzenie pakietu RPM</H3>

<P>Gdy plik specyfikujcy jest gotowy, mona ju
prbowa tworzy nowy pakiet. Najwygodniej jest
to zrobi poniszym poleceniem:
<P>
<BLOCKQUOTE><CODE>
<PRE>
        rpm -ba foobar-1.0.spec
</PRE>
</CODE></BLOCKQUOTE>
<P>Opcja <CODE>-b</CODE> ma par interesujcyh podopcji:
<UL>
<LI><CODE>p</CODE> oznacza wykonanie sekcji <CODE>prep</CODE> pliku
specyfikujcego. </LI>
<LI><CODE>l</CODE> wykona par rnych testw na plikach
<CODE>%files</CODE>. </LI>
<LI><CODE>c</CODE> wykonaj sekcj <CODE>prep</CODE> i kompiluj.
Jest to przydatne gdy jest si niepewnym czy rda
w ogle bd si kompilowa/instalowa. Owszem,
na pierwszy rzut oka moe to wyglda na zbdne
gdy mona dotd pracowa ze rdami a bd si
kompilowa jednak gdy przyzwyczaisz si
do wykorzystania RPM-a to spotkasz si z sytuacjami w
ktrach ta opcja okae si przydatna.</LI>
<LI><CODE>i</CODE> wykonaj prep, kompiluj i instaluj.</LI>
<LI><CODE>b</CODE> prep, kompiluj, instaluj, i buduj jedynie
pakiet binarny. </LI>
<LI><CODE>a</CODE> zbuduj wszystko - zarwno pakiet rdowy jak i binarny.</LI>
</UL>

Jest te par dodatkowych podopcji do
opcji <CODE>-b</CODE>:  
<UL>
<LI><CODE>--short-circuit</CODE> przejdzie prosto do
okrelonego etapu (moe by uyte wycznie z c oraz i)</LI>
<LI><CODE>--clean</CODE> usuwa katalog ze rdami stworzony
w czasie budowania pakietu.</LI>
<LI><CODE>--keep-temps</CODE> zachowa wszystkie pliki
temporalne i skrypty ktre zostay umieszczone
w /tmp. Jakie s to pliki mona si dowiedzie
wykorzystujc opcj <CODE>-v</CODE>.</LI>
<LI><CODE>--test</CODE> nie wykonuje adnych rzeczywistych
etapw cho wykonuje keep-temps.</LI>
</UL>
<P>
<H2>6.10 Testowanie pakietu</H2>

<P>Po stworzeniu pakietu rpm rdowego i binarnego naley je
przetestowa. Najprociej i najlepiej jest wykorzysta
do tego zupenie inny komputer ni ten na ktrym
pakiet by tworzony. W kocu przy tworzeniu pakietu
by on do czsto instalowany i na komputerze na ktrym
powstawa powinno by to zrobione do dobrze.
<P>Mona te prbowa <CODE>rpm -u nazwapakietu.rpm</CODE> 
na testowanym pakiecie ale moe by to zdradliwe w sytuacji
w ktrej jakie pliki zostay pominite w licie plikw
i nie zostan wtedy usunite.
Wtedy zainstalowany program bdzie kompletny mimo tego,
e rpm bdzie bdny. Pamitaj, e poniewa Ty ju
zrobie <CODE>rpm -ba package</CODE>, to zdecydowana wikszo
osb instalujcych Twj pakiet wykona jedynie
<CODE>rpm -i package</CODE>. Upewnij si, e nie wykonujesz
w sekcjach <CODE>build</CODE> lub <CODE>install</CODE> 
czego co powinno by zrobione gdy instalowany
jest wycznie pakiet binarny.
<P>
<P>
<H2>6.11 Co robi z Twoimi nowymi RPM-ami ?</H2>

<P>Gdy ju stworzye swj wasny pakiet RPM (zakadajc,
e nie ma ju takiego pakietu dostpnego pod postaci
RPM) moesz udostpni wynik swojej pracy innym
(zakadajc e to czego pakiet stworzye moe by
tak udostpniane).
By udostpni, umie to na 
<A HREF="ftp://ftp.redhat.com">ftp.redhat.com</A>.
<P>
<H2>6.12 Co teraz?</H2>

<P>Prosimy sprawdzi si, e nic nie zostao pominite jeszcze
raz czytajc rozdziay o "Testowaniu"
i "Co robi z nowymi RPM-ami".
Chcemy mie jako RPM wszystko co si da ale chcemy,
eby byy to dobre RPM-y.
Prosimy wic powici troch czasu na ich dokadne 
przetestowanie i prosimy te o umieszczenie ich
w archiwum ftp tak, by kady mg z nich skorzysta.
A take, <EM>prosimy</EM> upewni si, e umieszczasz jedynie
<EM>bezpatne</EM> oprogramowanie.
Oprogramowanie komercyjne i shareware <EM>nie</EM>
powinno by umieszczane w archiwum o ile nie zawieraj
klauzuli w ich prawach autorskich to dopuszczajcej.
Dotyczy to np. Netscape, ssh, pgp, etc.
<P>
<H2><A NAME="s7">7. Tworzenie RPM-w na wiele platform.</A></H2>

<P>RPM moe by wykorzystywany do tworzenia pakietw
dla Intel i386, Digital Alpha pracujcych pod Linux,  
oraz Sparc. S te doniesienia o jego wykorzystaniu
na platformach SGI i HP.
RPM ma par cech ktre czyni tworzenie pakietw na
wiele platform prostszymi.
Pierwsz z nich jest dyrektywa ``optflags'' 
w pliku <CODE>/etc/rpmrc</CODE>.
Moe ona by wykorzystana do ustawienia odpowiednich
opcji i flag, specyficznych dla architektury,
potrzebnych do kompilacji bd instalacji.
Nastpn cech uatwiajc tworzenie pakietw na wiele
platform s makra ``arch'' w pliku specyfikujcym.
Mog one by wykorzystane do wykonania rnych
rzeczy zalenych od architektury na ktrej pakiet
jest instalowany. Nastpn tak cech jest
dyrektywa ``Exclude'' w nagwku.  
<P>
<H2>7.1 Przykadowy plik specyfikujcy .spec</H2>

<P>Poniej zamieszczona jest cz pliku specyfikujcego
dla pakietu ``fileutils''.
Jest on przygotowany do instalacji na dwch 
platformach: Alfach i Intelu.
<BLOCKQUOTE><CODE>
<PRE>
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*

.
.
.
</PRE>
</CODE></BLOCKQUOTE>
<P>
<H2>7.2 Dyrektywa optflags</H2>

<P>W powyszym przykadzie przedstawione zostao uycie
dyrektywy ``optflags'' z <CODE>/etc/rpmrc</CODE>.  
<CODE>RPM_OPT_FLAGS</CODE> przyjmuj odpowiedni warto 
w zalenoci od tego na jakiej platformie instalowany
jest pakiet. Do pliku Makefile uytego w pakiecie 
naley nanie poprawki by korzysta z tej zmiennej
zamiast standardowych opcji (np. <CODE>-m486</CODE> lub <CODE>-O2</CODE>).
Moesz si zorientowa co powinno by zrobione
poprzez zainstalowanie pakietu rdowego,
jego rozpakowanie i przyjrzenie si plikowi Makefile.
Nastpnie naley zajrze do plikw z poprawkami
dla pliku Makefile i sprawdzi jakie zmiany powinny by 
wprowadzone.
<P>
<H2>7.3 Makra</H2>

<P>Makro <CODE>%ifarch</CODE> jest bardzo istotne dla tworzenia
pakietw na wiele architektur.
W wikszoci przypadkw potrzebujesz nanie jedn
lub dwie poprawki specyficzne tylko dla jednej, konkretnej
architektury. W takiej sytacji RPM pozwala na 
naniesienie poprawki wycznie dla niej.
<P>
<P>W powyszym przypadku, pakiet fileutils ma poprawk
dla maszyn 64-bitowych.
To naturalnie w chwili obecnej stosuje si tylko do Alf.
Tak wic dodajemy makro <CODE>%ifarch</CODE> 
nanoszce odpowiedni poprawk:
<BLOCKQUOTE><CODE>
<PRE>
%ifarch axp
%patch1 -p1
%endif
</PRE>
</CODE></BLOCKQUOTE>

To zapewni, e poprawka nie bdzie naniesiona
na adnej innej architekturze a wycznie na alfach.
<P>
<H2>7.4 Wyczanie pewnych platform w pakietach</H2>

<P>Mona opiekowa si rdowymi RPM-ami w jednym
katalogu dla wszystkich platform. Uzyskuje si to poprzez
``wyczenie'' (ang. exclude) pewnych pakietw
z tworzenia ich dla pewnych architektur, tak, e cigle
moliwym jest:
<BLOCKQUOTE><CODE>
<PRE>
rpm --rebuild /usr/src/SRPMS/*.rpm
</PRE>
</CODE></BLOCKQUOTE>

dajce w wyniku poprawne pakiety. Jeli aplikacja nie zostaa 
jeszcze do tej pory przeniesiona na dan platform to wystarczy
doda wiersz wygladajcy mniej wicej tak:
<BLOCKQUOTE><CODE>
<PRE>
ExcludeArch: axp
</PRE>
</CODE></BLOCKQUOTE>

do nagwka pliku specyfikujcego pakiet rdowy.
Nastpnie przebuduj pakiet na platform na ktrej
ju pracuje. W ten sposb uzyskuje si pakiet,
ktry kompiluje si/tworzy si np. na Intel-u
podczas gdy moe by atwo opuszczony na Alfie.
<P>
<H2>7.5 Ostatnie poprawki</H2>

<P>Wykorzystanie RPM to tworzenia pakietw przeznaczonych
na wiele platform jest zazwyczaj prostsze ni doprowadzenie
pakietu do stanu w ktrym daj si on na nich zainstalowa.
Jednake w miar jak powstaje wicej i wicej pakietw w 
postaci binarnej staje si to coraz prostsze.
Jeli przy tworzeniu pakietu zabrniesz w lep uliczk
to jak zwykle, rozwizaniem moe by zajrzenie
do kodu rdowego podobnego pakietu. 
<P>
<H2><A NAME="s8">8. Uwaga o prawach autorskich</A></H2>

<P>Poniszy dokument i jego zawarto s chronione prawem autorskim.
Rozpowszechnianie go i jego zawartoci jest dozwolone
tak dugo jak dugo jego pozostaj one nie zmienione.
Innymi sowy mona go wycznie przeformatowywa, drukowa
i rozpowszechnia.
<P>
</BODY>
</HTML>