Poprzednia NastΩpna Spis Tre╢ci

6. Tworzenie rpm-≤w.

Tworzenie rpm-≤w jest do╢µ proste, szczeg≤lnie je╢li oprogramowanie kt≤re chcesz tam w│o┐yµ poprawnie siΩ instaluje.

Procedura tworzenia RPM-≤w wygl▒da tak:

Zazwyczaj RPM tworzy zar≤wno pakiety binarne jak i ╝r≤d│owe.

6.1 Plik rpmrc

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 to 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 czyli nazwΩ dystrybucji. Mo┐esz j▒ zdefiniowaµ tutaj, b▒d╝ p≤╝niej, w nag│≤wku pliku spec. ==================== 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).

6.2 Plik specyfikacji

Niniejszy rozdzia│ zawiera opis pliku specyfikuj▒cego pakiet. Pliki takie 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 ty wygl▒daµ mniej wiΩcej tak: nazwa pakietu-kreska-numer wersji-kreska-release number-kropka-spec.

A tak wygl▒da przyk│adowy plik specyfikacyjny (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

6.3 Nag│≤wek

Nag│≤wek zawiera kilka standardowych p≤l kt≤re powinny byµ wype│nione.

Pola nag│≤wka powinny byµ wype│nione w poni┐szy spos≤b:

6.4 Sekcja Prep

Jest to druga czΩ╢µ pliku specyfikuj▒cego. U┐ywa siΩ jej do przygotowania ╝r≤de│ do kompilacji. 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:

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:

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

6.5 Sekcja Build

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). Katalog roboczy na pocz▒tku ka┐dej z sekcji jest ustawiany na katalog g│≤wny z plikami ╝r≤d│owymi, o czym trzeba pamiΩtaµ i w razie potrzeby przechodziµ do odpowiednich podkatalog≤w.

6.6 Sekcja Install

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.

6.7 Opcjonalne sekcje pre i post dla sekcji Install/Uninstall

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 instlacji b▒d╝ usuwaniu pakiet≤w zaiweraj▒cych biblioteki dzielone. Makra s▒ zdefiniowane jak poni┐ej:

Sekcje te mog▒ zawieraµ dowolne poprawne polecenia sh ( nie potrzebujesz wstawiaµ #!/bin/sh na pocz▒tku).

6.8 Sekcja Files

W sekcji tej musisz 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 NIE DA 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:

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│ wszystkie pliki w katalogu /usr/bin w Twoim komputerze.

6.9 Tworzenie pakietu

Katalogi z plikami ╝r≤d│owymi

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:

Pr≤bne tworzenie pakietu

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µ wykorzystany w pliku specyfikacyjnym. 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µ dlaczego poprawki by│y potrzebne. Przed u┐yciem pliku z poprawkami warto do niego zajrzeµ by siΩ upewniµ, ┐e przypadkiem nie znalaz│o siΩ w nim co╢ niew│a╢ciwego jak np. pliki binarne.

Tworzenie listy plik≤w

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.

Tworzenie pakietu RPM

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:

Jest te┐ parΩ dodatkowych opcji ??? (modifiers) do opcji -b:

6.10 Testowanie pakietu

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│ powinien byµ do╢µ dobrze zainstalowany.

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▒cyhc 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.

6.11 Co robiµ z Twoimi nowymi RPM-ami ?

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.

6.12 Co teraz?

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 i 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, prosimy upewniµ siΩ, ┐e umieszczasz jedynie bezp│atne oprogramowanie. Oprogramowanie komercyjne i shareware nie powinno byµ umieszczane w archiwum o ile nie zawieraj▒ klauzuli w ich prawach autorskich to dopuszczaj▒cej. Dotyczy to np. Netscape, ssh, pgp, etc.

Poprzednia NastΩpna Spis Tre╢ci