Teraz, po dosyć ogólnym wprowadzeniu, mogę przejść do strony praktycznej. Czyli jak wygląda budowanie pakietu.
Zanim przejdziemy jednak do sprawy, trzeba się upewnić że rpm jest poprawnie skonfigurowany. Najpierw plik ~/.rpmrc. U mnie wygląda on tak:
optflags: i686 -march=pentium2 -Os -fomit-frame-pointer -s -pipe -DNDEBUG -DG_DISABLE_ASSERT -z combreloc

buildarchtranslate: i686: i686
buildarchtranslate: i586: i686
buildarchtranslate: i486: i686
buildarchtranslate: i386: i686
Pierwsza linijka ustawia zmienną/makro ,,optflags'' na standardowe flagi optymalizacji w moim systemie. W zasadzie to te ustawienia nie będą zbyt często dochodziły do głosu, bo najnowszy RPM i tak daje pierwszeństwo środowiskowym zmiennym $CFLAGS/$CXXFLAGS. Tak że to ustawienie zapewne pozostanie w większości przypadków ,,ciche'', ale na wszelki wypadek... wiadomo. Składnia jest dosyć interesująca, bo RPM pozwala na ustawienie kilku zestawów flag, różnych dla różnych architektur. Architektura to pierwsze słowo po ,,optflags:'', a dopiero potem lecą flagi. Jak widać, u mnie architektura to i686 (rpm nie rozróżnia ,,odmian'' i686 w stylu ,,pentium2'', ,,k6'' itp.). Gdybym chciał zdefiniować różne flagi dla różnych architektur, to mogłoby to wyglądać np. tak:
optflags: i686 -march=pentium2 -Os -fomit-frame-pointer -s -pipe -DNDEBUG -DG_DISABLE_ASSERT -z combreloc
optflags: i586 -march=k5 -Os -fomit-frame-pointer -s -pipe -DNDEBUG -DG_DISABLE_ASSERT -z combreloc
RPM potem dobiera sobie właściwy zestaw flag w zależności od ustawionej BuildArch. Chyba, że użyje się wykrętu jakim jest ,,buildarchtranslate''. Ten cały bloczek tych poleceń ma u mnie jedno zadanie - niezależnie od wybranej architektury (od i386 po i686) RPM i tak sięgnie po ustawienia dia i686. Nie, to nie jest potrzebne, wystarczy ustawić sobie flagi dla swojej architektury, ale daje pewność że, niezależnie od sytuacji, rpm nie spróbuje budować pod inną architekturę. Z wyjątkiem architektury ,,noarch'' :)

Dobra, teraz plik ~/.rpmmacros. Moja zawartość:
%_tmppath /tmp
%_mandir %{_prefix}/share/man
%_infodir %{_prefix}/share/info

%packager Grzegorz Niewęgłowski
%vendor QuaTrin
%distribution QuaTrin
%_topdir /home/grzegorz/rpm
%_defaultdocdir %{_datadir}/doc
%_sysconfdir /etc
%_localstatedir /var
%_libexecdir %{_prefix}/lib
Najpierw zmieniam ustawienie %{_tmppath}. Domyślne to /var/tmp, ale ja wymuszam /tmp. Nie, nie ma to specjalnych przesłanek, po prostu tak jest wygodniej na moim systemie.

Potem zmieniam definicje %{_mandir} i %{_infodir}, bo rpm domyślnie ustawia te zmienne niezgodnie z FHS (bez katalogu share). Te ustawienia nie będą poprawne, jeśli %{_prefix} zostanie ustawiony na /usr/local - ale to już zależy od tego, czy ktoś woli instalować do /usr/local, czy do /usr. Na systemach domowych to tylko kwestia kosmetyki, a głównym powodem dla którego ludzie na maszynach domowych instalują coś w /usr/local to fakt, że łatwiej im to potem ręcznie usunąć. W przypadku pakietów RPM ten argument nie ma jednak znaczenia, bo to RPM dba o porządek, więc oprogramowanie może lądować w /usr.

Potem ustawiam jeszcze dane o moim systemie i o mnie, a na koniec ustawiam %{_topdir} oraz %{_defaultdocdir}. To ostatnie to domyślny katalog na dokumentację, w tym przypadku znowu trzeba wymusić zgodność z FHS, bo RPM domyślnie chce używać %{_prefix}/doc, a według FHS katalog doc powinien jednak leżeć wewnątrz podkatalogu share, a nie bezpośrednio w /usr.

Na koniec pozostaje tylko przedefiniować %{_sysconfdir} oraz %{_localstatedir} tak, by były bardziej ,,politycznie poprawne'' (wytyczne Filesystem Hierarchy Standard).

Interesujące może też być ustawienie %{_libexecdir} - domyślnie makro to wskazuje na /usr/libexec, ale jest to niezgodne z FHS, który nie przewiduje w ogóle istnienia takiego katalogu. Dlatego %{_libexecdir} zwykle będzie wskazywać na %{_prefix}/lib
Z tak zmodyfikowanymi plikami nasz system RPM jest gotów do akcji. Fajno.
OK, więc do dzieła. Co by tutaj wziąć na tapetę... o, mam.