Pliki .spec oferują szerokie pole do popisu gdy idzie o automatyzację, ale czasem konieczna jest współpraca paczki z osobą paczkującą. Inaczej mówiąc: stworzenie jakiegoś interfejsu, który pozwoli pakującemu mieć wpływ na proces budowania pakietu i to polegający na czymś innym niż ręczna edycja speca. Sprowadza się to do jednego mechanizmu: instrukcji warunkowych, pozwalających uzależnić część pliku .spec od istnienia lub wartości jakiejś zmiennej czy też makra. Znajduje to czasem zastosowanie, najczęściej chyba właśnie w tzw. budowaniu warunkowym. Polega ono w uproszczeniu na tym, że plik .spec oferuje kilka wariantów, zwykle polegających na wybraniu jakichś opcji ./configure, które wpływają na wynikową paczkę binarną.

Ale zacznę od podstaw: jak w pliku .spec sprawdzić, czy jakieś makro jest zdefiniowane i podjąć akcję? Załatwia to konstrukcja %{?...:...}:

%{?_debug:echo Debug selected}

Zaraz po znaku zapytania podaje się nazwę makra, potem dwukropek, a po dwukropku akcję jaką chce się podjąć. "Akcja" to niezbyt właściwe słowo, bo może to być dowolna linia pliku .spec, w dowolnej lokacji. Jeśli warunek (sprawdzane makro) nie jest spełniony, to cała linia jest ignorowana przez rpmbuild - po prostu nie istnieje. Warunki można negować:

%{!?_debug:echo Debug selected} 

Najczęściej łączy się to z opcjami --with i --without rpmbuild. Opcje te pozwalają w wygodny sposób zdefiniować przy wywołaniu rpmbuild pewne makra, np. wywołanie

rpmbuild --with SDL --without sound

spowoduje zdefiniowanie dwóch makr: _with_SDL i _without_sound. A w pliku .spec można sprawdzać, czy makra te są dostępne i jakoś na nie zareagować. Np. ustawiając opcje %configure:

%configure \
--disable-dependency-tracking %{?_with_SDL:--with-sdl} \
%{!?_without_sound:--enable-esd} --disable-debug

proste i funkcjonalne. Jeśli jakaś opcja ./configure wpływa na listę generowanych plików, to można oczywiście i w sekcji %files uzależnić te pliki od wartości odpowiedniego makra. To samo dotyczy zależności, jeśli ktoś używa zależności od nazw pakietów to może sobie wpisać w preambułę coś w rodzaju

Requires: %{!?_without_sound:esd} %{?_with_SDL:SDL >= 1.2.5}

Temat ten jest bardzo rozległy, ale podstawy już nakreśliłem. Ot, jedna konstrukcja do sprawdzania warunków. Może teraz kilka luźnych uwag: po pierwsze, opcje --with i --without się nawzajem nie negują. To znaczy, że definiując równocześnie "--with sdl --without sdl" tak naprawdę dojdzie do definicji dwóch makr. Należy więc rozsądnie konstruować pliki .spec. Po drugie, wiersz z instrukcją sprawdzająca warunki nie może być łamany, nie jest możliwe wykonanie bloczku instrukcji w jednym warunku - na jeden warunek może przypaść tylko jeden wiersz "akcji". Jeśli masz więcej linijek podpadających pod jeden warunek to musisz po prostu każdą linijkę uwarunkować osobną konstrukcją %{?...:...}. Po trzecie, aktualne wartości wszystkich makr można poznać podając opcję "--showrc" do rpm lub rpmbuild. Nie jest wtedy wykonywana żadna akcja, ale rpm pokaże listę makr która by obowiązywała przy tej akcji.

Standardowy RPM nie oferuje wygodnego sposobu na podejrzenie jakie opcje --with/--without są akceptowane przez pakiet. W dystrybucji PLD wprowadzono jednak modyfikację polegającą na dodaniu opcji --bcond, która to opcja w użyciu z jakimś plikiem .spec pokaże listę dostępnych --with/--without. Modyfikację tę, bardzo użyteczną, można zreplikować na dowolnym systemie RPM bez potrzeby rekompilacji. Bazuje ona na mechanizmie "popt" - jest to system, który pozwala definiować nowe opcje dla jakiegoś polecenia bez jego rekompilacji. W przypadku PLD stworzono nową opcję i podpięto pod nią skrypt, który wyciąga z pliku .spec charakterystyczne zmienne a potem prezentuje je, po obróbce, użytkownikowi. W PLD wprowadzono też bardzo sympatyczne ujednolicenie, dodatkową warstwę dla makr budowania warunkowego. Ich nazwy są tam tłumaczone z postaci _without_foo/_with_foo na bcond_off_foo/bcond_on_foo. Zainteresowanych odsyłam do repozytoriów CVS. Ja prywatnie z tego nie korzystam, ale też nie przywiązuję wielkiej wagi do warunkowego budowania pakietów. Moje potrzeby zaspokajają całkowicie te standardowe mechanizmy, choć ich PLD-owska wariacja jest wygodniejsza.