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æ.