Wykonywanie poprzedniej sekcji, %build, trochę potrwa. Źródła będą się kompilować, kompilować, a od czasu do czasu włączy się też linker. Po poprawnym wykonaniu całej kompilacji zwykle trzeba to, co zostało skompilowane, zainstalować. Także tutaj nie będzie inaczej. Jedyna różnica dotyczy "miejsca przeznaczenia" w którym wylądują pliki. Przy normalnym "make install" pliki mają zostać umieszczone bezpośrednio w systemie, czyli np. w /usr/bin, /usr/lib, /etc itp. W przypadku rpm nie wchodzi to w rachubę, bo celem jest stworzenie pakietu, a nie zainstalowanie. Pliki lądują zwyczajowo w "fake root", który często będzie znajdował się w /tmp albo w /var/tmp. Zwykle w /var/tmp/%{name}-%{version}. Katalog "fake root" jest dostępny zawsze poprzez zmienną $RPM_BUILD_ROOT, co upraszcza pisanie plików .spec

Nie jest jednak tak, że to rpm w jakiś magiczny sposób przechwytuje próby zapisu do /bin i przekierowuje je do $RPM_BUILD_ROOT/bin, nie, tak zaawansowane to to nie jest. To sam proces instalacyjny (czyli zwykle "make install" musi dać się zmusić do zapisywania plików w $RPM_BUILD_ROOT/usr/lib zamiast w /usr/lib. W przypadku programów bazujących na mechanizmach autoconf/automake zwykle wystarczy podać w wywołaniu "make install" definicję zmiennej $DESTDIR wskazującą na "miejsce przeznaczenia" - make doda zawartość $DESTDIR jako prefix do wszystkich ścieżek instalowanych plików, więc główne drzewko systemowe da się przesunąć do jakiegoś katalogu. I jest to po prostu pewna cecha plików Makefile zbudowanych przy pomocy skryptu ./configure, rpm nie ma z tym nic wspólnego. Programy, w których plik Makefile nie jest tworzony przez ./configure ale został napisany przez autora oprogramowania nie muszą oczywiście trzymać się tej zasady, zmienna $DESTDIR może nie mieć dla nich żadnego znaczenia. Mogą używać też jakiejś innej zmiennej, albo w ogóle nie brać pod uwagę możliwości przekierowania instalacji. I wtedy trzeba będzie, niestety, samemu zaingerować w pliki Makefile. Ale o tych skrajnych przypadkach później. W 80% przypadków wystarczy taka sekcja %install:

%install
make install DESTDIR=$RPM_BUILD_ROOT

I tutaj jeszcze jedno słówko o dodatkowym makrze - %makeinstall. Mam w sumie mieszane uczucia jeśli idzie o to makro. Jego definicja powoduje wywołanie "make install" i przekazanie szeregu zmiennych które mają na celu przekierowanie instalacji do %{buildroot} (to zwykle to samo, co $RPM_BUILD_ROOT, tylko wyrażone za pomocą makra rpm, a nie zmiennej środowiskowej). Tyle że nie uważam tego za dobry pomysł. Po pierwsze, jest to przekazywanie zmiennych w stylu "libdir=...", "includedir=.." - a więc jest to skończona lista zmiennych. Jeśli jakaś Makefile używa jednak jeszcze jednej zmiennej, która nie została tutaj uwzględniona, albo po prostu inaczej się nazywa, to całe to makro %makeinstall można sobie podarować, bo po prostu się nie sprawdzi. A po drugie, nie ma żadnego "nakazu" by Makefile używały przy instalacji katalogów definiowanych przez zmienne "libdir" itp. Nawet jeśli są to tak ładnie zdefiniowane Makefile tworzone przez ./configure. Więc naprawdę nie wiem, po co takie makro stworzono, skoro zwykle zadziała ono tylko w jakimś podzbiorze Makefile które by i tak "posłuchały" po prostu zmiennej $DESTDIR. Dlatego raczej odradzam używania %makeinstall, zwykłe make install DESTDIR=$RPM_BUILD_ROOT też powinno zadziałać i to w większej nawet ilości przypadków. Ale wspomnieć o %makeinstall trzeba. Więc wspomniałem. I na tym poprzestanę - bo używać tego makra nie mam po prostu zamiaru :)