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