Najpierw zajmiemy się spakietowaniem tej dosyć znanej przeglądarki obrazków. W przypadku każdego nowego pakietu raczej nie da się uniknąć jednej ,,testowej'' kompilacji i instalacji, przeprowadzanej poza środowiskiem rpm. Chodzi o to, by poznać konkretny pakiet - wybrać flagi konfiguracyjne, sprawdzić czy nie wystąpią problemy, obejrzeć listę instalowanych plików.

OK, więc jakie czynności nas czekają:

1. Rozpakowanie źródeł :)

2. Konfiguracja. OK, robię ,,./configure --help'' i nie widzę żadnych specjalnych opcji. Decyduję się na użycie tylko dwóch opcji - ,,--prefix=/usr --disable-nls''. Normalka. Jedyne co może dziwić, to wyłączanie wsparcia dla NLS, chociaż gqview ma całkiem przyzwoite polskie tłumaczenie. Ale to tylko mój prywatny odchył. Cały proces ./configure przebiegł bez błędów. OK.

3. Kompilacja. ,,make''. Udało się bez błędów.

4. Próbna instalacja. Potrzebny mi będzie jakiś tymczasowy katalog... na takie (i inne) okazje mam ramdysk w /dev/shm (zlinkowany, w celu łatwiejszego dostępu, do /shm). Ty możesz użyć dowolnego katalogu, gdzieś w swoim $HOME lub w /tmp. Instaluje się tak samo, jak to potem będzie miało miejsce w specu, czyli poprzez $DESTDIR. 
make install DESTDIR=/shm
zadziałało u mnie bezbłędnie.

5. Ocena sytuacji. Wchodzę do /shm, zastaję tam następujące drzewko plików: 
usr/
 \-bin/
    |-gqview
    |
    |-man/
    |  \-man1/
    |      \-gqview.1
    \-share/
        \-gqview/
             \-README
OK, dzięki temu będę wiedział, jakie pozycje umieścić w sekcji %files. Wszystko jest OK, za wyjątkiem położenia manuali. Powinny leżeć w /usr/share/man, a nie w /usr/man. Ale to załatwię przy pisaniu pliku .spec.

6. Pisanie pliku .spec Tutaj polecam najpierw stworzenie sobie ,,szkieletu'', którego potem by można używać przy tworzeniu kolejnych speców. Taki ,,szkielet'' którego osobiście używam wygląda następująco: 
Summary:
Name:
Version:
Release: 1
License: GPL
Group:
Source: %{name}-%{version}.tar.gz
BuildRoot: /var/tmp/%{name}-%{version}

%description



%clean
rm -rf %{buildroot} %{_builddir}/%{name}-%{version}

%prep
%setup -q

%build
%configure
make

%install
rm -rf %{buildroot}
make install DESTDIR=%{buildroot}

%files
%defattr(0644,root,root,0755)

%attr(0755,root,root)%{_bindir}/*
%{_mandir}/man*/*.gz
Mała preambuła (częściowo pusta), moja odmiana sekcji %clean (usunie ,,fake root'' oraz rozpakowane źródła)), standardowe sekcje %prep, %build, %install. Sekcja %files z dwoma najczęściej powtarzającymi się wpisami - wychwycenie plików w %{_bindir} oraz manuali w %{_mandir}/man*. Wystarczy to skopiować jako ,,nowy plik .spec'' i pouzupełniać potrzebne elementy.

OK, więc weźmy się za uzupełnianie. Najpierw przykładowa preambuła: 
Summary: Przeglądarka plików graficznych.
Name: gqview
Version: 1.2.0
Release: 1
License: GPL
Group: Grafika
Source: %{name}-%{version}.tar.gz
BuildRoot: /var/tmp/%{name}-%{version}

%description
GQView to niewielka przeglądarka wykorzystująca GTK+, oferuje wszystkie tak
potrzebne "bajery" jak zoom, miniaturki, filtrowanie, czy zewnętrzne
edytory. A przy tym jest całkiem szybka.
Wystarczy po prostu dopisać do ,,szkieletu'' cechy zależne od konkretnego pakietu - wersja, nazwa, opisy itp. Lećmy dalej.

Sekcję %clean pozostawiam bez zmian, w sumie to raczej nigdy jej nie będę zmieniał - jest ,,uniwersalna''.
Sekcja %prep też pozostaje bez zmian.
Drobne zmiany w sekcji %build: 
%build
%configure --disable-nls
make
Jak widać, dodałem ,,--disable-nls''. Ale, ale - gdy konfigurowałem gqview przy kompilacji ,,testowej'', to użyłem również ,,--prefix=/usr'', no i miałem też coś zrobić z położeniem manuali... Więc dlaczego teraz wpisuję tylko --disable-nls? Bo makro %configure zawiera w sobie wszystkie przełączniki ustawiające katalogi w mechanizmach ./configure. Między innymi ustawia --prefix i --mandir, więc nie muszę się o to martwić.
Sekcję instalacyjną również pozostawiam bez zmian, pozostaje tylko sekcja %files. GQview po mojej testowej instalacji zainstalowało raptem 3 pliki - binarkę, manual oraz plik README w /usr/share/gqview. Moja sekcja %files na tę okoliczność wygląda tak: 
%files
%defattr(0644, root, root, 0755)
%attr(0755,root,root) %{_bindir}/*
%{_mandir}/man*/*.gz
%{_datadir}/gqview
Wychwytywanie binarek w %{_bindir} oraz manuali w %{_mandir} miałem już wklepane w szablonie, wystarczyło tylko dodać %{_datadir}/gqview (ta notacja, jak w poprzedniej części mówiłem, w odniesieniu do katalogu oznacza ,,załącz katalog i jego zawartość''). A makro %{_datadir} to nic innego, jak ,,standardowe'' /usr/share. OK, więc cały spec-file wygląda teraz tak: 
Summary: Przeglądarka plików graficznych.
Name: gqview
Version: 1.2.0
Release: 1
License: GPL
Group: Grafika
Source: %{name}-%{version}.tar.gz
BuildRoot: /var/tmp/%{name}-%{version}

%description
GQView to niewielka przeglądarka wykorzystująca GTK+, oferuje wszystkie tak
potrzebne "bajery" jak zoom, miniaturki, filtrowanie, czy zewnętrzne
edytory. A przy tym jest całkiem szybka.


%clean
rm -rf %{buildroot} %{_builddir}/%{name}-%{version}

%prep
%setup -q

%build
%configure --disable-nls
make

%install
rm -rf %{buildroot}
make install DESTDIR=%{buildroot}

%files
%defattr(0644, root, root, 0755)
%attr(0755,root,root) %{_bindir}/*
%{_mandir}/man*/*.gz
%{_datadir}/gqview
Teraz wystarczy to gdzieś zapisać, np. w ~/rpm/SPECS/gqview.spec

7. Wywołanie rpmbuild. Po tym, jak mamy już w ~/rpm/SPECS napisanego speca, można sprawdzić czy to zadziała. Do katalogu ~/rpm/SOURCES trzeba skopiować źródła gqview-1.2.0.tar.gz, a potem wywołać rpmbuild. Zapewne będziesz teraz przebywał w ~/rpm/SPECS, więc wystarczy jeśli wpiszesz 
rpmbuild -bb gqview.spec
...jeśli wszystko poszło dobrze, to zobaczysz przesuwające się po ekranie komunikaty, a po jakimś czasie rpmbuild zakończy pracę - z sukcesem, miejmy nadzieję. Jeśli wszystko poszło dobrze, to w katalogu ~/rpm/RPMS, w podkatalogu architektury twojej maszyny, znajdziesz gotowy do instalacji, własny pakiet gqview-1.2.0-1.xxx.rpm. Teraz, gdy już wiesz że spec działa, możesz chcieć stworzyć sobie źródłowy pakiet .src.rpm - wystarczy wpisać 
rpmbuild -bs gqview.spec
a po chwilce w katalogu ~/rpm/SRPMS znajdziesz odpowiedni pakiet. Pakiet źródłowy w wygodny sposób łączy w sobie kod źródłowy z twoim plikiem .spec, co jeszcze bardziej uprości ewentualne przyszłe rekompilacje.

Po budowaniu warto po sobie posprzątać. Moja wersja makra %clean zajęła się usunięciem ,,fake root'' (/var/tmp/gqview-1.2.0) oraz rozpakowanych źródeł gqview (~/rpm/BUILD/gqview-1.2.0). Jedyne co pozostało, to paczka ze spakowanymi źródłami w ~/rpm/SOURCES. Możesz usunąć ją ręcznie, możesz też wywołać 
rpmbuild --rmsource gqview.spec
a wtedy rpmbuild przeskanuje plik .spec, samodzielnie ,,wywęszy'' gdzie powinny leżeć źródła i usunie je. Przełącznika ,,--rmsource'' można było użyć już przy budowaniu pakietu - wtedy po udanym skonstruowaniu pakietu rpm usunie źródła, a ty nie będziesz musiał już palcem kiwnąć. Jeśli kompilacja lub budowa samego pakietu się nie powiodła, to rpmbuild oczywiście nie usunie źródeł :)

OK, to by było pierwsze, mam nadzieję że udane, budowanie pakietu rpm. Nie jest to może pakiet nadający się do szerokiej dystrybucji, ale na potrzeby domowe jest jak najbardziej OK. Teraz małe wyjaśnienie: taki sposób instalacji oprogramowania wydaje się być koszmarnie niewygodny i czasochłonny. I faktycznie, tworzenie pierwszego pliku .spec dla jakiegoś programu zawsze zabierze więcej czasu, niż zwykła kompilacja i instalacja. Ale za to gdy nadejdzie ewentualny upgrade będziesz miał łatwiej - gdy ukaże się np. gqview-1.2.1, to wystarczy że skopiujesz paczkę gqview-1.2.1.tar.gz do ~/rpm/SOURCES, a w pliku ~/rpm/SPECS/gqview.spec zmienisz wersję w tagu Version:, po czym uruchomisz 
rpmbuild -bb gqview.spec
I to zapewne wystarczy - rpm rozpakuje źródła, skonfiguruje, skompiluje, zbuduje paczkę, a tobie pozostanie zrobić 
rpm -Uvh nowa_paczka_z_gqview.rpm
Wysiłek włożony w skonstruowanie specfile zwróci się przy okazji najbliższej aktualizacji lub rekompilacji. Dobrze napisany plik .spec, tzn. taki, w którym sekcja %files będzie się w pewnym stopniu dostosowywać do pojawiania się nowych plików/znikania starych (co czasem dzieje się wraz z rozwojem programów) - taki plik spec będzie sobie dobrze radził z przyjmowaniem nowych wersji programu - ty będziesz tylko zmieniał numerek wersji w jednym tagu i wywoływał rpmbuild. Od czasu do czasu co najwyżej będziesz musiał skorygować listę %files, jeśli instalowany program bardziej się zmieni (z doświadczenia wiem, że to nieczęsto będziesz spotykał).