Jednym z podstawowych zajęć developerów jest tworzenie pakietów. PLD jest oparta o format pakietów RPM, których tworzenie jest stosunkowo proste, a znacznie ułatwia pracę administratora.
Kolejne etapy tworzenia pakietu to:
Zanim zaczniemy tworzyć pakiet musimy jakoś zdobyć program, który chcemy spakować. Przede wszystkim należy zobaczyć czy już go ktoś nie (z)robi(ł). Jeżeli nie znajdziemy gotowego pakietu powinniśmy zdobyć możliwie najnowszą wersję (tylko bez przesady ;) źródeł - najlepiej ze strony autora programu. Jeżeli uda nam się znaleźć program w postaci src.rpm to dobrze jest ściągnąć taką wersję i dodatkowo nowsze źródła (o ile są). Dzięki temu mamy już w ręku gotowy i (teoretycznie) działający pakiet. Wprowadzanie zmian jest o wiele łatwiejsze niż pisanie od nowa (choć nie zawsze). Poza tym jest szansa, że autor RPMa stworzył już jakieś łatki, albo dodał tłumaczenia w jakimś języku. Generalnie należy więc poszukać najpierw gotowego pakietu, a dopiero jeśli takiego nie znajdziemy - ściągnąć ,,gołe'' źródła.
O ile napisanie pliku spec jest stosunkowo proste, to doprowadzenie źródeł do poprawnej kompilacji okazuje się niekiedy bardzo trudne. Jeżeli źródła programu, które mamy nie kompilują się poprawnie, albo plik Makefile do nich dołączony jest niedobry powinniśmy stworzyć łatkę (ang. patch). W tym celu należy rozpakować źródła w dwóch katalogach, do jednego z nich wprowadzić potrzebne zmiany, a następnie wykonać poniższe polecenie.
diff -urN katalog.z.oryginłem katalog.z.poprawionym.oryginałem > źródła-powód.patch |
Aby uprościć konfigurowanie menażerów okien wymyślono pliki desktop, w których zawarte są podstawowe informacje na temat programu. Przykładowy plik desktop wygląda następująco:
[Desktop Entry] Name=Mutt Comment=The Mutt Mail User Agent Comment[pl]=Mutt - program pocztowy Icon=mail2.xpm Exec=mutt Terminal=1 Type=Application |
Jak widać są tu zawarte takie informacje jak: nazwa programu, krótki opis programu w różnych językach (zazwyczaj to samo co w polu Summary pliku spec), nazwa pliku z ikoną, komenda uruchamiająca program, oraz grupa, do której progam można zaliczyć. Jeśli program ma być uruchamiany w oknie terminala, pole Terminal ma wartość 1, w przeciwnym wypadku - 0.
Podstawą pakietów RPM są pliki spec. Uzupełniają one lub zastępują tradycyjne pliki Makefile.
Na plik spec składają się następujące sekcje:
Preambuła służy do określenia podstawowych właściwości pakietu jak nazwa, wersja czy programy wymagane do instalacji. W preambule mogą (gwiazdka oznacza, że muszą) występować następujące pola:
Pole Summary zawiera krótki opis programu po angielsku. W kolejnych liniach można ten opis tłumaczyć na inne języki używając jako argumentu dwuliterowego skrótu języka. Pakiety dla PLD powinny mieć conajmniej dwa pola Summary:
Summary: Short description
Summary(pl): Krótki opis
Pole Name określa nazwę programu.
Pole Version określa wersję programu.
Pole Release określa rewizję pakietu. Jeżeli wprowadzisz jakieś istotne zmiany do SPECa powinieneś zwiększyć wartość tego pola o 1. Pierwsza wersja pakietu powinna mieć rewizję 1 (nie 0).
Pole Group określa do jakiej grupy należy program. Pole to jest wykorzystywane główie przez graficzne front-end'y do RPMa (np. gnorpm) do układania pakietów w kategoriach tematycznych. Podobnie jak pole Summary tak i Group może mieć jako argument dwuliterowy skrót języka. Pakiety dla PLD powinny mieć conajmniej dwa pola Group:
Group: Some/Group
Group(pl): Jakaś/Grupa
Listę istniejących grup możesz znaleźć w dokumentacji RPMa
Pole Copyright lub License określa na jakiej licencji jest dostępny dany program. Najczęściej jest to:
License: GPL
Nazwy License używamy jeśli chodzi o jedną z następujących licencji: GPL, LGPL, BSD. Po prostu używanie słowa Copyright w odniesieniu do tych licencji jest nieadekwatne.
W tym polu możemy podać osobę zajmującą się programem (ang. maintainer). Najczęściej jest to po prostu autor programu.
Pole Packager zawiera dane osoby, która stworzyła pakiet. Jeżeli pakujesz program powinieneś umieścić tu swoje imię, nazwisko i adres e-mail. W pakietach PLD pole to jest wypełniane automatycznie przy budowaniu pakietu wystawianego potem na serwer FTP.
Pole Distribution określa dystrybucję, do której należy dany pakiet. W pakietach PLD pole to jest wypełniane automatycznie.
Serial to przestarzała nazwa dla pola Epoch. Pole Epoch ma największe znaczenie w numerze wersji pakietu, gdyż schemat numeracji wygląda następująco: Epoch:Version-Release. Pola tego używanmy głównie w sytuacji, gdy autor programu zmienia zasady numeracji wersji. Na przykład program w3m był kiedyś numerowany datą wydania (np. 19991130), a teraz jest numerowany tradycyjnie - np. 0.1.6. Z tego powodu w specu dla w3m możemy znaleźć "Epoch: 1", dzięki któremu wersja 0.1.6 jest nowsza niż 19991130, a co za tym idzie można wykonać bezbolesne uaktualnienie.
Pole URL powinno zawierać adres strony domowej programu.
Pole Source określa nazwę pliku ze źródłami programu. W miarę możliwości należy nazwę pliku podać wraz z pełną ścieżką do głównego serwera FTP programu. Pól Source może być kilka:
Source0: ftp://ftp.serwer.com/pub/katalog/%{name}-%{version}.tar.gz
Source1: %{name}.desktop
Pakiety dla PLD powinny używać Source jeżeli źródło jest jedno i Source0 jeżeli źródeł jest więcej, ale jest to uwarunkowane wyłącznie względami estetycznymi.
Pole Patch określa nazwę pliku z poprawkami do programu. Często po ściągnięciu źródeł okazuje się, że nie chcą się one skompilować, albo wymagają uprawnień root'a do instalacji. W takich wypadkach powinniśmy poprawić źródła programu i stworzyć odpowiednią łatkę (ang. patch). Kiedy już to zrobimy musimy podać nazwę tej łatki w polu Patch:
Patch: %{name}-make.patch
Pakiety dla PLD powinny używać Patch jeżeli jest jedna łatka i Patch0 jeżeli jest ich więcej, ale jest to uwarunkowane wyłącznie względami estetycznymi.
Pole Icon określa nazwę pliku z ikoną programu. Pole to jest wykorzystywane głównie przez front-end'y do RPMa (np. gnorpm) do umieszczania ikonek obok nazw programów.
W polu BuildRequires należy wymienić pakiety, które są niezbędne do poprawnej kompilacji pakietu. Zazwyczaj są to pakiety zawierające biblioteki lub pliki nagłówkowe (*-devel). Np. w vim.spec możemy zobaczyć:
BuildRequires: ncurses-devel
BuildRequires: ncurses-static
BuildRequires: gpm-devel
BuildRequires: Xaw3d-devel
BuildRequires: lesstif-devel
BuildRequires: gtk+-devel
BuildRequires: glib-devel
Pole Prereq ma znaczenie przy instalacji większej ilości pakietów jednocześnie. Pakiety zawarte w tym polu są przesuwane na początek kolejki i instalowane wcześniej.
Pole Requires zawiera nazwy pakietów, które są wymagane do instalacji danego pakietu. Nie trzeba tu umieszczać nazw podstawowych bibliotek jak np. glibc, gdyż to RPM zrobi automatycznie (wykonując polecenie 'ldd' dla każdego pliku binarnego w pakiecie). W polu tym można też określić w jakiej wersji pakiet ten jest wymagany. Na przykład pakiet util-linux wymaga pakietu pam w wersji 0.66 lub wyższej:
Requires: pam >= 0.66
Używać można następujących znaków arytmetycznych dla określenia wymaganej wersji: =, >, <, >=, <=. W PLD począwszy od rpm-2.5.6-5 zmieniony jest nieco skrypt find-requires, którym RPM automatycznie wyszukuje zależności, co powoduje, że wpisów do pola Requires należy dokonywać wyłącznie w sytuacjach, gdy wymagana jest konkretna wersja pakietu.
Pole Provides określa jakie usługi udostępnia pakiet. Na przykład pakiety sendmail i zmailer udostępniają demona smtp:
Provides: smtpdaemon
Dzięki temu niezależnie od tego, który z nich jest zainstalowany to pakiety wymagające demona smtp (np. mutt) będą mogły być instalowane.
Pole Autoreqprov pozwala zablokować opcję automatycznego wyszukiwania wymagań (Requires) i udostępnianych przez pakiet usług (Provides):
Autoreqprov: no
Pole BuildArch pozwala określić dla jakiej architektury pakiet ma być robiony. Najczęściej używa się go, żeby zaznaczyć, że dany pakiet jest niezależny od platformy (np. dokumentacja):
BuildArch: noarch
Pole BuildRoot pozwala określić katalog roboczy przy budowaniu pakietu. Dzięki temu prawie wszystkie pakiety można budować z konta zwykłego użytkownika. Pakiety dla PLD powinny mieć następującą wartość pola BuildRoot:
BuildRoot: /tmp/%{name}-%{version}-root
Pole ExclusiveArch pozwala określić na jakich architekturach pakiet może być budowany.
Pole ExclusiveOS pozwala określić na jakich systemach operacyjnych pakiet może być budowany (RPM istnieje także dla innych systemów niż Linux).
Pole ExcludeArch pozwala określić na jakich architekturach pakiet nie może być budowany.
Pole ExcludeOS pozwala określić na jakich systemach operacyjnych pakiet nie może być budowany.
Makro %description jest specyficzną częścią preambuły. Służy do umieszczenia dłuższego opisu pakietu. Jak każde makro rozpoczyna się od znaku procenta ('%'). W odróżnieniu od pozostałych części preambuły %description może zajmować więcej niż jedną linię. Parametrem tego makra może być -l, a wartością tego parametru -- dwuliterowy skrót języka. Pakiety dla PLD powinny mieć conajmniej dwa makra %description (jedno dla języka angielskiego i jedno dla polskiego):
%description
Longer package description.
%description -l pl
Dłuższy opis pakietu.
W sekcji %prep źródła programu są przygotowywane do kompilacji. Cała sekcja, podobnie jak %build, %install, %pre(un) i %post(un) jest po prostu skryptem shell'a. Żeby uprościć najczęściej wykonywane operacje w tej sekcji istnieją dwa makra:
Makro %setup służy do rozpakowania źródeł i przejścia do ich głównego katalogu. Może mieć następujące parametry:
Parametr -a jest potrzebny kiedy musimy rozpakować większą ilość plików ze źródłami. Jako wartość tego parametru podajemy numer źródła.
Parametr -c jest potrzebny w spakowanych źródłach pliki nie są umieszczone w żadnym katalogu i rozpakowują się domyślnie do katalogu BUILD. Jako wartość tego parametru podajemy nazwę podkatalogu, do jakiego mają się rozpakować źródła, czyli na ogół %{name}-%{version}.
Po rozpakowaniu źródeł RPM usiłuje przejść do katalogu %{name}-%{version} zakładając, że tak się nazywa główny katalog rozpakowanych źródeł. Niektóre programy jednak po rozpakowaniu mają inną nazwę i należy o tym poinformować RPMa podając jako wartość parametru -n faktyczną nazwę tego katalogu. Na przykład główny katalog ze źródłami programu fetchpop nazywa się %{name}%{version} (bez myślnika), dlatego w pliku fetchpop.spec możemy znaleźć:
%setup -n %{name}%{version}
Parametr -q (od ang. quiet) powoduje, że w trakcie rozpakowywania źródeł przy budowaniu pakietu na ekranie nie pojawiają się komunikaty o rozpakowywanych plikach. Pakiety dla PLD powinny stosować parametr -q.
Makro %patch ułatwia nakładanie łatek na źródła. Ma następujące parametry:
Przy wywołaniu makra należy zamiast N wstaiwć numer łatki (lub nic, jeżeli pierwszej łatce nie nadaliśmy numeru 0). Jeżeli w preambule zadeklarowaliśmy istnienie dwóch łatek:
Patch0: %{name}-make.patch
Patch1: %{name}-secure.patch
to, aby je zaaplikować należy w sekcji %prep wpisać następujące linijki:
%patch0 -p1
%patch1 -p1
Parametr -p spełnia taką samą rolę jak w standardowym poleceniu UNIXowym patch - man patch :->.
Sekcja %build opisuje proces kompilacji źródeł. Jeżeli do źródeł jest dołączony dobry plik Makefile to cała treść tej sekcji sprowadza się zazwyczaj do ustawienia odpowiednich flag dla kompilatora, skonfigurowania źródeł i wywołania polecenia 'make':
%build ./configure \ --enable-something \ make |
Jak widać w pierwszej linii ustawiane są flagi dla kompilatora. Wykorzystana została tutaj zmienna $RPM_OPT_FLAGS, której wartość można sobie ustawić w pliku .rpmmacros. Dzięki temu program kompilowany jest z takimi parametrami z jakimi chce tego użytkownik. Dalej widzimy wywołanie polecenia ./configure z parametrem --enable-something. Polecenie to występuje w źródłach prawie wszystkich większych programów i służy do skonfigurowania źródeł przed kompilacją. Zazwyczaj można też w źródłach znaleźć plik README lub INSTALL, w którym opisane są wszystkie możliwe parametry dla ./configure. W ten sposób zazwyczaj włącza/wyłącza się dodatkowe cechy programu. Na końcu widzimy wywołanie polecenia make, które odwali całą brudną robotę związaną z kompilacją programu.
Jeżeli do źródeł nie został dołączony plik Makefile to w sekcji %build należy umieścić odpowiednie wywołania kompilatora.
Warto również nadmienić, iż w PLD istnieje makro dla RPMa o nazwie %configure, które dodaje odpowiednie parametry (takie jak --prefix=%{_prefix}) do właściwego skryptu configure tak więc bardzo często wystarczy:
%build %configure |
Sekcja %install opisuje proces instalacji pakietu. Podobnie jak poprzednie sekcje jest to skrypt shell'a. O ile do źródeł dołączony został porządny plik Makefile to zamiast opisu instalacji można wywołać make install, ale czasem należy wykonać tu pełny opis. Oto przykładowa sekcja %install pochodząca z pakietu eject:
%install
rm -rf $RPM_BUILD_ROOT
install -d $RPM_BUILD_ROOT{%{_bindir},%{_mandir}/man1}
install eject $RPM_BUILD_ROOT%{_bindir}/eject
install eject.1 $RPM_BUILD_ROOT%{_mandir}/man1/eject.1
gzip -9nf $RPM_BUILD_ROOT%{_mandir}/man1/* \
README ChangeLog
|
Jak widać sekcja ta jest podzielona optycznie na trzy części. Nie jest to przypadek -- po prostu w %install możemy wyróżnić trzy etapy:
Tworzenie struktury katalogów
Aby pakiet można było zbudować z konta zwykłego użytkownika tworzona jest odpowiednia struktura katalogów w uprzednio skasowanym katalogu roboczym.
Kopiowanie plików
W drugiej części realizowana jest najważniejsza część instalacji czyli rozrzucanie plików po stworzonej przed chwilą strukturze katalogów. Pliki wykonywalne nie powinny stripowane.
Kompresowanie dokumentacji
Ostatnia część to kompresowanie wszelkiej dokumentacji czyli stron man, dokumentów info i plików takich jak README czy ChangeLog. Pakiety dla PLD powinny kompresować dokumentację za pomocą polecenia gzip -9nf.
W tej sekcji należy także zainstalować (zrobiony uprzednio) plik desktop. Zakładając, że plik ten jest naszym Source1 musimy wykonać następującą instrukcję:
install %{SOURCE1} $RPM_BUILD_ROOT/usr/X11R6/share/applnk/Networking/Mail
|
Sekcje %pre, %preun, %post i %postun są to skrypty wykonywane odpowienio: przed instalacją, przed deinstalacją, po instalacji i po deinstalacji. Domyślnym interpreterem tych skryptów jest /bin/sh, ale można to zmienić podając parametr -p interpreter. Ta metoda jest o tyle dobra, że interpreter jest automatycznie dodawany do listy Prereq pakietu. Skrypty %post i %postun są najczęściej wykorzystywane do uruchomienia polecenia 'ldconfig' w pakietach, które zawierają jakieś biblioteki dzielone. Skrypty te mogą też wyświetlać jakieś komunikaty w czasie instalacji. Jeżeli wykonujemy upgrade jakiegoś pakietu to kolejność wykonywania skryptów jest nastepująca:
%preun (odinstalowywany pakiet)
%postun (odinstalowywany pakiet)
%pre (instalowany pakiet (nowa wersja))
%post (instalowany pakiet (nowa wersja))
Sekcja %verifyscript jest skryptem wykonywanym w trakcie weryfikacji pakietu. Domyślnym interpreterem jest /bin/sh, ale można to zmienić podając jako parametr -p interpreter. Dzięki temu skryptowi możemy dodać nowe sprawdzenia, które będą wykonywane oprócz standardowych sprawdzeń wykonywanych przez RPM.
Sekcja %clean służy do usunięcia plików i katalogów tymczasowych. Zazwyczaj sprowadza się ona do jednego polecenia:
%clean rm -rf $RPM_BUILD_ROOT |
Sekcja %clean nie jest wymagana przez RPM, ale jest wymagana przez PLD.
Sekcja %files służy do określenia jakie pliki mają wchodzić w skład pakietu, jakie mają mieć uprawnienia, właścicieli, grupy itp. W sekcji tej mogą występować następujące makra:
Makro %defattr służy do określenia domyślnych właścicieli/grup i praw dostępu dla plików i katalogów. Makro to powinno (przynajmniej w pakietach dla PLD) znajdować się na samym początku sekcji %files i wyglądać następująco:
%defattr(644,root,root,755)
Oznacza to, że domyślnie wszystkie pliki i katalogi będą miały właściciela root i grupę root oraz domyślne uprawnienia - 644 dla plików i 755 dla katalogów.
Makro %attr służy do ustawienia plikowi/katalogowi innych praw dostępu niż to zostało określone makrem %defattr. Jeżeli mamy na przykład w pakiecie pliki binarne to musimy im nadać prawa 755. Robimy to w następujący sposób:
%attr(755,root,root) %{_bindir}/*
W ten sposób wszystkie pliki pakietu, które znajdą się w %{_bindir} będą miały prawa dostępu 755. Innym przykładem użycia makra %attr jest zmiana grupy:
%attr(644,root,floppy) /dev/fd*
Makro %doc służy do zaznaczenia, że dane pliki są dokumentacją programu. Pliki poprzedzone makrem %doc będą się znajdować w katalogu /usr/share/doc/%{name}-%{version} i nie będą instalowane jeżeli przy instalacji pakietu dodamy opcję --excludedocs. Makrem tym powinny być oznaczone pliki typu README czy ChangeLog oraz wszelka dokumentacja. Nie powinno się tu jednak wymieniać pliku zawierającego treść licencji (zazwyczaj COPYING) jeżeli jest to jedna z powszechnie stosowanych licencji jak (L)GPL czy BSD.
Makro %dir służy do zaznaczenia, że dany katalog należy do pakietu, ale pliki w nim zawarte już nie. Jeżeli chcemy, żeby cały katalog wraz z zawartością należał do pakietu to po prostu piszemy:
/nasz/katalog
Jeżeli natomiast chcemy, by zawartość katalogu należała do pakietu, ale sam katalog nie - wtedy piszemy:
/nasz/katalog/*
Makro %config pozwala zaznaczyć, że dany plik jest plikiem konfiguracyjnym programu i ma być inaczej traktowany. Plik oznaczony tym makrem nie jest usuwany przy deinstalacji pakietu. Makro %config może mieć dodatkowe parametry:
Parametr noreplace powoduje, że plik nie będzie podmieniany na nową wersję w trakcie instalowania nowej wersji pakietu, a odpowiadający mu plik z nowej wersji będzie zachowany jako plik.newrpm.
Parametr missingok oznacza, że plik może zostać skasowany i jego brak nie będzie zgłaszany w trakcie weryfikacji pakietu. Przykład:
%config(noreplace) %verify(not size md5 mtime) /etc/Muttrc
Za pomocą makra %verify możemy określić jakie właściwości pliku mają być sprawdzane w trakcie weryfikacji pakietu. Możliwe właściwości to:
Sprawdzana ma być suma kontrolna md5 pliku.
Sprawdzana ma być wielkość pliku.
Sprawdzane ma być czy plik jest linkiem i do jakiej lokalizacji wskazuje.
Sprawdzany ma być właściciel pliku.
Sprawdzana ma być grupa pliku.
Sprawdzany ma być czas ostatniej modyfikacji pliku.
Sprawdzane mają być prawa dostępu do pliku.
Przed tymi parametrami można wstawić parametr not, który spowoduje, że nabiorą one przeciwnego znaczenia.
Makrem %ghost możemy zaznaczyć, że w pliku będą przechowywane logi, a co za tym idzie plik będzie zmieniał swoją wielkość, sumę kontrolną, czas ostatniej modyfikacji jak również może być linkiem do innej lokalizacji i nie powinien być zamazywany przy instalacji nowej wersji pakietu. Jak nietrudno się domyślić makro %ghost jest po prostu skróconym zapisem kombinacji makr %config i %verify z odpowiednimi parametrami, a mianowicie:
%config(noreplace) %verify(not md5 mtime link size) < plik >
Sekcja %changelog służy do uwieczniania historii pakietu. Wystarczy w mniej umieścić:
%define date %(echo `LC_ALL="C" date +"%a %b %d %Y"`)
%changelog
* %{date} PLD Team
All below listed persons can be reached on <cvs_login>@pld.org.pl
Log: |
(przed i po 'Log:' należy wstawić znak '$' (dolara). Nie mogliśmy tutaj wstawić tego znaku gdyż CVS automatycznie zmodyfikowałby tę stronę.) Wpisy w %changelog będą aktualizować się automatycznie po wprowadzeniu danego pliku do CVSu. Pakiety dla PLD powinny mieć sekcję %changelog na samym końcu pliku spec.
W plikach spec możemy korzystać ze sporej ilości makr zdefiniowanych w plikach /usr/lib/rpm/macros oraz /usr/lib/rpm/macros.pld. Zamiast wpisywać ścieżki na sztywno:
%install
rm -rf $RPM_BUILD_ROOT
install -d $RPM_BUILD_ROOT/usr/{bin,man/man{1,2,3,5}}
... |
używamy dostępnych makr:
%install
rm -rf $RPM_BUILD_ROOT
install -d $RPM_BUILD_ROOT%{_bindir}
install -d $RPM_BUILD_ROOT%{_mandir}/man{1,2,3,5}
... |
Zaletą tego rozwiązania jest to, że w przypadku zmiany położenia katalogów systemowych (np. w związku ze zmianą standardu FSSTND na FHS2.0) wystarczy jedynie zmienić definicje makr w pliku /usr/lib/rpm/macros i przekompilować pakiety. Nie jest konieczna żadna zmiana plików spec!
Coraz więcej programów korzysta z gettexta, aby wyświetlać komunikaty w różnych językach. Żeby pakiet zawierał wszystkie pliki z tłumaczeniami i instalował je we właściwych katalogach wystarczy na końcu sekcji %install umieścić polecenie:
%find_lang %{name}
%files -f %{name}.lang
Żeby uniknąć monotonnego powtarzania różnych czynności należy tworzyć skrypty, które oszczędzą czasu Tobie i innym. Jednym z takich skryptów jest, napisany w języku awk, adapter. Skrypt ten pozwala w szybki sposób przenosić pliki spec z innych dystrybucji. Adapter wykonuje następujące czynności:
- dodaje słowa kluczowe CVSa
- tłumaczy pola Group
- formatuje szerokość kolumny tekstu w opisach do około 80 znaków
- zastępuje makrami podane wprost nazwy katalogów
- ustawia parametry typowych makr i programów
- usuwa zbędne linie
- formatuje preambułę
Kiedy w katalogu SOURCES mamy już źródła, łatki i plik desktop, a w SPECS mamy gotowego spec'a możemy (spróbować) zbudować pakiet. Do tego celu służy polecenie `rpm -ba pakiet.spec`. Jeżeli pakiet nie zbuduje się poprawnie można wykonywać tylko fragmenty budowania pakietu, by zobaczyć, w którym miejscu pojawiają się problemy. W tym celu zamiast -ba możemy użyć następujących parametrów:
Wykonaj tylko sekcję %prep.
Wykonaj %prep, sprawdzenie listy plików i sekcję %build.
Wykonaj %prep, sprawdzenie listy plików, %build i %install.
Za pomocą tej opcji można sprawdzić czy po wykonaniu sekcji %install w katalogu $RPM_BUILD_ROOT istnieją pliki wymienione w sekcji %files.
Wykonaj wszystkie sekcje i stwórz pakiet binarny.
Wykonaj wszystkie sekcje i stwórz pakiet binarny oraz pakiet źródłowy.
Testując pakiet należy przede wszyskim:
Sprawdzić czy pakiet da się zbudować z konta zwykłego użytkownika. Jest dosłownie kilka pakietów, które trzeba budować z konta użytkownika root.
Sprawdzić czy pliki są w odpowiednich katalogach i mają odpowiednie prawa dostępu, właściciela i grupę.
Sprawdzić czy pliki binarne nie mają ustawionego parametru SUID/SGID. Jeżeli mają należy się zastanowić czy jest to konieczne (bo prawie na pewno nie jest).
Po ukończeniu prac nad pakietem należy dodać go do CVS. Dobrze jest też poinformować na pld-list, że nowy pakiet jest dostępny. Można także dodać pakiet do CVS przed ukończeniem prac, ale należy wtedy w komentarzu umieścić informację o tym, że pakiet nie jest jeszcze dokończony.