Na system RPM składają się następujące komponenty:
Baza informacji o zainstalowanych pakietach
Przechowywana zwykle w /var/lib/rpm/, składa się z wielu plików w formacie Berkeley DB.

Aplikacje operujące na bazie danych
Różne programy które zmieniają bądź odpytują bazę danych. Instalują pakiety, usuwają pakiety, pobierają informacje o pojedynczych plikach lub pakietach etc.

Pakiety binarne
Najczęściej spotykane pakiety z rozszerzeniem .rpm. Zawierają gotowe do zainstalowania, spakowane pliki wraz z informacjami o ich typie i prawach dostępu, oraz nieco informacji o samym pakiecie - zależności pakietu, informacje o nim, kategorię do której należy i inne takie.

Pakiety źródłowe
Rzadziej spotykana forma pakietów rpm. Mają rozszerzenie .src.rpm i nie zawierają gotowych do zainstalowania plików. Ich przeznaczenie jest inne - są czymś w rodzaju ładnie opakowanego kodu źródłowego, który należy gdzieś rozpakować, skonfigurować oraz zainstalować. Wszystko to pod kontrolą automatu RPM i przy jak najmniejszym obciążania użytkownika. Przynajmniej w założeniach :)
Takie paczki zawierają w sobie spakowany kod źródłowy programu oraz ewentualne patche, które zostaną nałożone przed kompilacją. Źródła są następnie konfigurowane według określonego wzorca, kompilowane, a z wynikowych plików tworzone są binarne pakiety RPM gotowe do instalacji. Jest to czysty i wygodny sposób kompilowania programów, bowiem taki pakiet źródłowy zawiera oprócz ,,zwykłych'' zależności także listę pakietów potrzebnych przy kompilacji, a sam użytkownik zwykle potrzebny jest do dwóch tylko czynności - uruchomienia procesu przebudowy takiego pakietu i późniejszej instalacji pakietów wynikowych. Brzmi to bardzo miło w dosyć złożonym światku linuksowych kompilacji, tyle że jest w tym jeden hak - pakiet źródłowy musi być hiper-poprawnie skonstruowany i dopasowany dość ściśle do systemu, na którym ma być kompilowany. Co zwykle oznacza, że trzeba korzystać z pakietów źródłowych przygotowanych przez naszą dystrybucję. ,,Zwykłe'' źródła da się skompilować praktycznie na każdym średnio przystosowanym systemie, ale pakiety źródłowe RPM dodają tutaj warstewkę pośredniczącą - czyli mechanizm RPM właśnie - co zwiększa szanse na niepowodzenie. Jest to bezpośrednio powiązane ze wspomnianą już niezgodnością pakietów RPM pochodzących z różnych źródeł między sobą.

Oczywiście po zrozumieniu budowy i zasad działania pakietów RPM możliwe jest poprawienie dowolnego pakietu .src.rpm tak, aby dał się przebudować na dowolnym systemie...
I tutaj zaczynają się schody. Od czego należy zacząć? Hmm. Pierwszym krokiem będzie przygotowanie środowiska pracy. Potrzebny będzie katalog dedykowany budowaniu pakietów RPM, przyda się też porządny edytor do tworzenia specyfikacji pakietów (jak zwykle, Vim będzie dobrym wyborem :)

Najpierw należy wybrać sobie miejsce na katalog przeznaczony budowaniu pakietów RPM. Domyślnie tym katalogiem jest /usr/src/rpm, ale prawo zapisu do tego katalogu ma tylko root. I nie należy korzystać z tego katalogu (/usr/src/rpm) - pakiety RPM można bezproblemowo budować korzystając z uprawnień zwykłego użytkownika (tylko instalacja i pokrewne operacje wymagają praw superużytkownika). A więc skoro nie ma potrzeby korzystania z konta roota, to nie należy tego robić, prawda? Załóżmy, że na potrzeby rpm stworzyliśmy katalog ~/rpm. Teraz trzeba tylko jeszcze powiedzieć mechanizmom RPM, żeby z niego korzystały (zamiast próbować dobierać się do /usr/src/rpm).

A można zrobić to poprzez plik ~/.rpmmacros. Tutaj mała dygresja - RPM jest bardzo elastyczny jeśli idzie o jego ustawienia, większość z nich to zmienne (makra), które można przedefiniować. Makr tych jest całe zatrzęsienie, dodatkowo wielka ich część jest zdefiniowana poprzez inne makra, lub jest definiowana warunkowo, więc łatwo się w tym pogubić. A na dodatek nie ma jednego porządnego podręcznika opisującego standardowe makra wykorzystywane przez RPM. Dlatego trzeba sobie jakoś inaczej radzić. Najlepszym sposobem jest chyba szukanie tego, co chcemy zmienić w plikach /usr/lib/rpm/macros, /usr/lib/rpm/rpmrc oraz pokrewnych.

Obok pliku makr istnieje też plik innych ustawień, generalnie dotyczących architektury komputera docelowego. Plik zwie się /usr/lib/rpm/rpmrc, a jego ustawienia można ,,przykryć'' za pomocą pliku ~/.rpmrc. Jeśli jednak poczujesz się zagubiony w gąszczu tych wszystkich deklaracji, możesz skorzystać z polecenia rpm --showrc - wypluje ono aktualną listę wszystkich makr i ustawień, w takiej formie w jakiej by były one używane po przeparsowaniu przez rpm wszystkich plików konfiguracyjnych. Grepowanie wyjścia tego polecenia może bardzo szybko wskazać, które makro odpowiada za zachowanie które chcemy zmienić. Jeśli ,,ustawienie'' w swojej definicji ma postać mniej-więcej nazwa wartość, to można je zmienić wpisem w ~/.rpmmacros. Jeśli jednak wygląda ono raczej tak: nazwa: wartość (chodzi o ten dwukropek), to należy je zmieniać w ~/.rpmrc. Uff. Wróćmy jednak do konfiguracji RPM. Za główny katalog używany przez RPM przy budowaniu pakietów odpowiada makro %_topdir. Aby wskazać inny niż domyślny katalog, wystarczy w pliku ~/.rpmmacros przedefiniować to makro. A przy okazji można ustawić inne opcje, dotyczące np. podpisywania tworzonych przez nas pakietów naszym kluczem PGP czy inne takie drobnostki. Mały wycinek z mojego ~/.rpmmacros
%_topdir /home/grzegorz/rpm
%_tmppath /tmp
%packager Grzegorz Niewęgłowski
%vendor QuaTrin
Jak widać ustawiam tutaj ścieżkę do głównego katalogu rpm, katalogu tymczasowego, oraz ustawiam pola Packager: oraz Vendor: (widoczne np. w wyjściu rpm -qi) na wartości które lepiej odpowiadają mojemu środowisku :)

Te drobne poprawki pozwalają już na w miarę wygodne budowanie pakietów przy użyciu konta zwykłego użytkownika. A jak będzie wyglądać zawartość katalogu rpm? Będzie on miał w sobie dodatkowe podkatalogi. Będą to SRPMS, RPMS, SOURCES, SPECS i BUILD. SOURCES będzie przechowywał paczki ze źródłami programów. W SPECS znajdą swoją ostoję specyfikacje pakietów, czyli potocznie zwane ,,spece''. Do BUILD będą rozpakowywane źródła pobierane z SOURCES, tam też dokonywała się będzie kompilacja programów. A RPMS i SRPMS będą przechowywały powstałe w ostatniej fazie procesu produkcyjnego binarne i źródłowe pakiety RPM. Powinieneś pozakładać te podkatalogi. W razie wątpliwości skopiuj strukturę z /usr/src/rpm.