%prep
%setup

-n <nazwa>

Opcja ta jest konieczna... albo nie, zacznę inaczej. Weźmy sobie jakiś przykład, np. źródła programu ,,xplanet''. Przypuśćmy, że kod źródłowy zawarty jest w paczce xplanet-1.20.tar.gz. Więc w preambule umieściliśmy tagi ,,Name: xplanet'', ,,Version: 1.20'' oraz ,,Source: %{name}-%{version}.tar.gz'' (choć nic nie stoi na przeszkodzie by wpisać tu po prostu nazwę pliku - tyle że tak będzie wygodniej przy zmianie wersji itp. Jeśli jeszcze o tym nie wspomniałem, to zapis %{...} to standardowy sposób na odwoływanie się do wewnętrznych zmiennych/makr RPM-a). A plik xplanet-1.20.tar.gz zawiera katalog xplanet-1.20. W takim wypadku można spokojnie użyć makra %setup bez ozdóbek, nic złego się nie stanie. Ale załóżmy, że paczka ze źródłami nazywa się xplanet-1.20.tar.gz, ale zawiera katalog o nazwie ,,xplanet'', bez numerku wersji. I tu jest pierwszy problem do przeskoczenia. Bo makro %setup nie jest jakieś specjalnie inteligentne. Owszem, ono weźmie te źródła, rozpakuje, ale potem spróbuje wejść do katalogu %{name}-%{version}. A taki katalog nie będzie istniał i proces budowy się wyłoży. Bo %setup nie sprawdza tak naprawdę co rozpakowuje, ale oczekuje że po rozpakowaniu zastanie katalog o nazwie w formie nazwa-wersja, zgodnej z tagami Name: i Version:. A co jeśli jednak nazwa tak powstałego katalogu będzie inna? Przecież bez sensu by było zmieniać z tego powodu tagi Name:/Version:. I tutaj właśnie pojawia się opcja -n. Pozwala ona podać nazwę katalogu, do którego makro %setup ma próbować wejść po rozpakowaniu źródeł. Czyli w naszym hipotetycznym przykładzie z xplanet trzeba by użyć %setup -n xplanet. I po kłopocie! :)

-c

A tutaj mamy podobną sytuację. Załóżmy sobie, że paczka xplanet-1.20.tar.gz nie zawiera jednego katalogu ze źródłami, ale że po rozpakowaniu od razu wypakowuje wszystkie pliki źródłowe. Tak, jakby obciąć jeden katalog z podstawy nazw plików i zamiast ładnie rozpakować się do katalogu xplanet-1.20 od razu wypakowuje jego zawartość. Nie dość, że nie ma katalogu xplanet-1.20 do którego by się dało wejść, to jeszcze robi się straszny bałagan w katalogu BUILD. Także na to jest sposób - opcja -c oznacza, że rpm będzie miał do czynienia właśnie z taką niechlujną paczką i że plikom z paczki brakuje nadrzędnego katalogu - więc rpm go najpierw założy, a dopiero potem wypakuje do niego zawartość paczki, no i przejdzie do tego katalogu. Katalog będzie miał nazwę %{name}-%{version}, ale jeśli koniecznie się chce, to można użyć innej nazwy łącząc -c z opcją -n.

-D

Mówiłem już, że rpm przy rozpakowywaniu źródeł najpierw spróbuje usunąć stare drzewko rozpakowanych źródeł. I o ile jest to zwykle bardzo pożądane, to w niektórych przypadkach (np. przy wypakowywaniu do jednego katalogu kilku kompletów źródeł (pomyśl o tagach Source0:, Source1: itp!) jest to kłodą rzuconą pod nogi. No cóż, opcja -D każe rpm-owi przeskoczyć ten kawałek z usuwaniem starych źródeł.
Prosty przykład zastosowania z życia wzięty: glibc. Zwykle kompiluje się je z dodatkiem linuxthreads. Tyle, że to daje dwie paczki źródeł - najpierw trzeba rozpakować glibc, potem linuxthreads. I dopiero wtedy można kompilować.

-T

A to bardzo sympatyczna opcja. Wyłącza rozpakowywanie domyślnych źródeł :) Makro %setup wykona wszystkie swoje działania, z wyjątkiem rozpakowania paczki ze źródłami. Ma to swoje zastosowanie w połączeniu z opcją -b

-b <numer>

Opcja -b jest używana do rozpakowania określonej paczki ze źródłami - trzeba tego użyć w sytuacji, gdy zadeklarowało się więcej niż jeden tag ,,Sources:'' w preambule. Np. ,,%setup -b 2 spowoduje rozpakowanie źródeł oznaczonych wcześniej jako ,,Sources2:''. Ale tutaj mały haczyk - makro %setup rozpakuje zawsze także ,,domyślne'' źródła, określone w ,,Sources:'' lub ,,Sources0:'' (czyli po prostu ,,pierwsze'' źródła). Jest to najczęściej niepożądane przy używaniu opcji -b, dlatego też używa się tutaj zwykle połączenia -b ze wspomnianą już opcją -T. Np. %setup -T -b 0. Wystarczy zapamiętać, że -b łączy się zwykle z -T, bo inaczej %setup będzie zawsze próbował rozpakować ,,dodatkowo'' pierwsze źródła z listy.

-a <numer>

Opcja -a jest bardzo podobna do -b, jedyna różnica to to, że przed rozpakowaniem makro wejdzie do katalogu ze źródłami. Oczywiście ten katalog powinien wcześniej istnieć :) Eee, może przykład: wspominałem już o glibc i linuxthreads, o tym że zwykle te dwa pakiety trzeba rozpakować aby skompilować glibc. Glibc po rozpakowaniu tworzy katalog ,,glibc-wersja''. Linuxthreads po rozpakowaniu tworzy katalog ,,linuxthreads''. Gdyby je rozpakowywać ,,normalnie'', za pomocą opcji -b, to glibc i linuxthreads by wylądowały w oddzielnych podkatalogach w obrębie katalogu ~/rpm/BUILD. Ale do poprawnej kompilacji źródła linuxthreads muszą znaleźć się wewnątrz katalogu z glibc. I opcja -a by zrobiła dokładnie to - najpierw weszła do katalogu %{name}-%{version} (lub prawdopodobnie dowolnego innego podanego za pomocą opcji -n), a dopiero potem rozpakowała źródła o określonym numerze.
A, jeszcze coś - można połączyć -a numer z -c, a wtedy makro %setup stworzy katalog %{name}-%{version} przed próbą wejścia do niego. Tutaj zaczyna być widoczne, dlaczego te wszystkie opcje są tak rozdrobnione i pozornie nieprzydatne - trzeba je po prostu łączyć z sobą.

-q

A to ostatnia już opcja (chyba, że znowu o czymś zapomniałem ;).
Opcja -q to po prostu quiet mode, jeśli użyje się tej opcji to tar rozpakowujący paczkę ze źródłami nie będzie wypisywał nazw rozpakowywanych plików. Przydatna opcja, zwłaszcza w diagnostyce budowy pakietów, bo zasypywanie ekranu spisem plików wypakowanych z paczki źródłowej zwykle nie jest do niczego przydatne.

Patch0: jakiś_patch.diff
Patch1: inny_patch.diff
Patch2: ostatnia_łata.gz

-p <numer>

Ta opcja jest przekazywana bezpośrednio programowi ,,patch'' i powoduje obcięcie <numer> katalogów od nazw wszystkich patchowanych plików. Jako że jest to tak naprawdę bardzo popularna opcja programu ,,patch'' i związana raczej z samym nakładaniem łatek, bez powiązania z RPM, to nie będę więcej o tym pisał. Wystarczy zajrzeć do manuala programu ,,patch''. W każdym bądź razie: %patch0 -p 1 spowoduje zaaplikowanie pierwszego patcha i przekazanie opcji ,,-p 1'' programowi ,,patch''.