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 :)