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:
/etc/rpmrc
jest obecny i skonfigurowany w Twoim systemie.Zazwyczaj RPM tworzy zarówno pakiety binarne jak i źródłowe.
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).
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
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:
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ś
ponownie uzyskać kody źródłowe 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
pli ź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 katalogu 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 sposób
stosowania prawa autorskiego do pakietu. 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 wyczerpujący
opis pakietu.
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:
-n name
ustawi nazwę roboczego katalogu na name
.
Domyślnie jest to $NAZWA-$WERSJA
.
Do innych możliwości należą $NAZWA
,
${NAZWA}${WERSJA}
,
czy jakąkolwiek inną używana przez główny plik tar.
(Proszę zauważyć, że zmienne ``$'' nie
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 zanim zacznie się rozpakowywanie
poprzez untar.-b #
wykona untar (rozpakuje) Source# zanim wejdzie do katalogu roboczego
(nie ma sensu łączenie tej opcji z -c
, a więc się tego nie robi).
Jest to przydatne wyłącznie w przypadku wielu plików
źródłowych.-a #
wykona untar (rozpakuje) Source# po 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
Nie usuwaj katalogu przed
rozpakowaniem.
Jest ona przydatna tylko wtedy, gdy ma się więcej niż
jedno makro konfiguracyjne.
Powinna być używana wyłącznie w makrach konfiguracyjnych
wyłącznie po 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 usunięcia z nazwy przed wykorzystaniem polecenia patch(1)-P
Domyślnie stosowana jest
Patch
(lub
Patch0
). Ta flaga wyłącza to zachowanie a więc wymusza
0
by głowne pliki źródłowe się rozpakowały. Opcja ta
jest przydatna w drugim (bądź dalszym) makrze
%patch
które wymaga innego niż pierwsze makro
numeru poprawki.%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ć.
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.
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.
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:
%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
( nie potrzebujesz wstawiać #!/bin/sh
na początku).
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:
%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
.rpmsave
.
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 BEZ makra %dir
, WSZYSTKO
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. Można też taką listę
stworzyć np. z pomocą komendy find. 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.
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 specyfikujace (spec).RPMS
RPM umieści tu binarme pliki RPM
po ich zbudowaniu.SRPMS
RPM umieści to pliki RPM z plikami źródłowymi.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.
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.
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
is a list check that does some checks on
%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.-b
:
--short-circuit
??? przejdzie prosto do
określonego etapu (może być użyte wyłącznie z c i 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. Można sprawdzić na bieżąco jakie to są
pliki wykrozystując opcję -v
.--test
nie wykonuje żadnych rzeczywistych
etapów choć wykonuje keep-temp.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.
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.
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.