Rpmbuild

Z Fedora Wiki

(alias: srpm)

Spis treści

Rpmbuild

Wstęp

Zagadnieniem związanym z zarządzaniem pakietami jest obsługa pakietów źródłowych.
Mają one rozszerzenia *.src.rpm i w przeciwieństwie do "normalnych" paczek rpm nie instalują żadnych programów i plików w naszym systemie. Zawierają natomiast kody źródłowe programów oraz szczegółowe informacje na temat w jaki sposób źródła te mają być kompilowane, jakie programy i biblioteki są wymagane przez budowany pakiet, oraz w jaki sposób stworzyć gotowy do instalacji binarny pakiet rpm. Jeśli istnieje taka konieczność do pakietów źródłowych dołączane są również patche nakładane na źródła programów podczas budowy pakietu. Wszystkie te informacje zawarte są w pliku .spec.
Jeśli, np. nie ma paczki rpm jakiegoś programu przygotowanej pod architekturę naszego komputera, ale dysponujemy pakietem źródłowym, to nic nie stoi na przeszkodzie, aby ją samemu przygotować.
Należy zaznaczyć, że pakiety źródłowe pochodzące z innych dystrybucji bazujących na RPM, takich jak Mandriva, czy OpenSuse, w większości przypadków nie nadają się do rekompilacji na Fedorze. Wynika to z faktu odmiennego sposobu budowy tych systemów; w rzeczywistości poza faktem korzystania z rpm dystrybucje te niewiele łączy. Nie ma również gwarancji, że rekompilacja src.rpm pochodzących z wcześniejszych wersji Fedory zakończy się sukcesem. Może się zdarzyć, że z aktualną wersją Fedory dostarczono nowsze wersje programów lub bibliotek wymaganych do budowy określonego pakietu o funkcjonalności tak dalece zmienionej, że kompilacja, a co za tym idzie budowa paczki rpm będzie niemożliwa. Prawdopodobieństwo udaniej budowy pakietu rpm jest jednak o wiele większe niż w przypadku src.rpm pochodzących z innych dystrybucji.

Przygotowanie środowiska pracy

Na początek zainstalujemy rpmbuild, oraz odpowiednie narzędzia:
[root@X ~]# yum install rpm-build rpmdevtools
Domyślnym katalogiem dla pakietów źródłowych jest /usr/src/. W takim wypadku należałoby korzystać z konta roota. Ponieważ nie jest to wymagane, przygotujemy środowisko pracy tak, aby wszystkie czynności wykonywać jako zwykły użytkownik:
[user@X ~]# rpmdev-setuptree
Powyższe polecenie utworzyło w naszym katalogu domowym katalog rpmbuild, oraz podkatalogi: 

rpmbuild
  |-BUILD
  |-BUILDROOT
  |-RPMS
  |  |-i386
  |  |-noarch
  |-SOURCES
  |-SPECS
  |-SRPMS

Struktura ta będzie wykorzystywana przez rpmbuild na różnych etapach jego pracy:

Obsługa

Rpmbuild umożliwia budowę pakietu rpm w trzech trybach:

Rekompilacja src.rpm

Jeśli ściągnęliśmy pakiet źródłowy najprostszym rozwiązaniem jest jego rekompilacja. Ogólna składnia polecenia ma postać: 

rpmbuild {--rebuild|--recompile} pakiet_źródłowy

Należy podać pełną ścieżkę do pliku src.rpm, lub wcześniej przejść do katalogu w którym pakiet źródłowy się znajduje. Opcji --rebuild, --recompile można używać zamiennie.

Przykład: pobierzmy pakiet źródłowy programu unzip: 

wget http://download.fedora.redhat.com/pub/fedora/\
linux/releases/10/Fedora/source/SRPMS/unzip-5.52-9.fc9.src.rpm

Nie pozostaje już nic innego, jak zbudować paczkę rpm: 

[user@X ~]# rpmbuild --rebuild unzip-5.52-9.fc9.src.rpm

Jeśli wszystkie wymagane programy są zainstalowane w systemie rozpocznie się proces budowy rpm, jeśli jakiś pakietów brakuje zostaniemy o tym poinformowani, wystarczy je zainstalować yumem i ponowić polecenie rpmbuild. W przypadku pojawienia się błędów zostaniemy poinformowani co je powoduje. Jeśli wszystko poszło dobrze rpmbuild poinformuje nas gdzie zapisano gotowe do instalacji paczki: 

[user@X ~]# [...]
Zapisano: /home/user/rpmbuild/RPMS/i386/unzip-5.52-9.fc10.i386.rpm
Zapisano: /home/user/rpmbuild/RPMS/i386/unzip-debuginfo-5.52-9.fc10.i386.rpm
[...]

Jak widać pakiet został zbudowany na maszynie x86 i w związku z tym umieszczono go w podkatalogu i386.
Plik unzip-debuginfo-5.52-9.fc10.i386.rpm służy do debbugowania programu unzip i jeśli nie jesteśmy programistami chcącymi uzyskać informacje diagnostyczne możemy go spokojnie usunąć. W Fedorze 11 pakiety debuginfo nie są domyślnie tworzone. Proszę zwrócić uwagę, że w numerze wydania pojawiło się fc10, co wskazuje na budowę pakietu na Fedorze 10.

Budowa pakietu w oparciu o plik spec.

Innym sposobem budowy pakietów jest wskazanie poleceniu rpmbuild pliku spec, zawierającemu szczegółowe informacje na temat jak dany pakiet zbudować. Jest to podstawowy tryb w przypadku tworzenia własnych pakietów. Może się również zdarzyć, że chcemy wnieść poprawki, np: do listy zależności pakietu budowanego z src.rpm. W obu przypadkach konieczna jest edycja pliku spec, a następnie budowa wskazanego w nim pakietu. Źródła programu muszą znajdować się w katalogu SOURCES.

Składnia polecenia ma postać: 

rpmbuild {-ba|-bb|-bp|-bc|-bi|-bl|-bs} PLIK_SPEC

Poszczególne opcje oznaczają:

Opcje -bp, -bc, -bi, -bl stosuje się w celach diagnostycznych przed budową właściwego pakietu, najczęściej wykorzystywane są dwie pierwsze.
Jeśli chcemy edytować plik spec posiadanego pakietu źródłowego musimy go wcześniej zainstalować: 

[user@X ~]# rpm -ivh xxx.src.rpm

Proszę zwrócić uwagę, że polecenie wykonywane jest jako zwykły użytkownik. Po zakończeniu instalacji w katalogu SPECS umieszczony zostanie pliki spec pochodzący z zainstalowanego pakietu, w katalogu SOURCES znajdą się źródła programu, oraz ewentualne patche.

Przykład: Zainstalujmy pobrany wcześniej pakiet źródłowy programu unzip: 

[user@X ~]# rpm -ivh unzip-5.52-9.fc9.src.rpm

Możemy teraz przyjrzeć się plikowi unzip.spec i np. wprowadzić poprawki. Jeśli chcemy zbudować zarówno pakiet binarny, jak i źródłowy wydamy polecenie: 

[user@X ~]# cd /home/user/rpmbuild/SPECS
[user@X ~]# rpmbuild -ba unzip.spec

W wyniku powyższego polecenia zbudowane zostały pakiety unzip-5.52-9.fc10.i386.rpm, unzip-debuginfo-5.52-9.fc10.i386.rpm (o ile nie zainstalowaliśmy F11) - analogicznie jak w przypadku rekompilacji unzip-5.52-9.fc9.src.rpm. Dodatkowo w katalogu SOURCES utworzony został pakiet źródłowy unzip-5.52-9.fc10.src.rpm

Budowa pakietu w oparciu o "tarballa"

Trzecim sposobem budowy pakietów jest kompilacja w oparciu o spakowany kod źródłowy programu. Metoda ta wymaga aby do spakowanych źródeł dołączony był również plik spec. Ze względu, między innymi na różnorodności dystrybucji oraz faktu, że nie wszystkie one bazują na rpm twórcy programów prawie nigdy nie załączają odpowiednich plików spec. Z tego powodu jest to rzadko stosowana metoda. Jeśli ściągnęliśmy kod źródłowy programu raczej będziemy musieli sami stworzyć odpowiedni plik spec.
Składnia polecenia ma postać: 

rpmbuild {-ta|-tb|-tp|-tc|-ti|-tl|-ts} TARBALL

Poszczególne opcje są analogiczne do poprzedniego sposobu budowy pakietów, z tą różnicą, że opcję -b zastępuje -t. Tak więc -ta oznacza budowę zarówno pakietu binarnego jak i źródłowego, -tb tylko binarnego itd.

Podstawowy opis plików spec

Info
Przedstawione w tym rozdziale informacje należy traktować jako krótkie wprowadzenie do budowy plików spec. Więcej informacji np. max-rpm, rpm-tutorial

Przyjrzyjmy się szkieletowi pliku spec, w którym umieszczone są wszystkie informacje potrzebne do budowy pakietu rpm. 

[user@X ~]# rpmdev-newspec nowy.spec

Utworzony został plik nowy.spec zawierający: 

Name:           
Version:        
Release:        1%{?dist}
Summary:        

Group:          
License:        
URL:            
Source0:        
BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

BuildRequires:  
Requires:       

%description

%prep
%setup -q

%build
%configure
make %{?_smp_mflags}

%install
rm -rf $RPM_BUILD_ROOT
make install DESTDIR=$RPM_BUILD_ROOT

%clean
rm -rf $RPM_BUILD_ROOT

%files
%defattr(-,root,root,-)
%doc

%changelog>

Opis opcji: 

%changelog
* Sat Mar 21 2009 Imię Nazwisko <adres@email> 
- Updated to 0.5

Po znaku * umieszcza się nazwę dnia tygodnia i miesiąca, używając oznaczeń w języku angielskim, następnie podaje się datę, dane personalne, oraz adres email. W następnej linii po znaku - podaje się opis zmian.

W plikach spec często spotyka się sekcje:

Powyższe sekcje nie są wykonywane w czasie tworzenia pakietów, lecz ich instalacji/usunięcia. Domyślnym interpreterem skryptów jest /bin/sh. Stosuje się składnię zgodną z wykorzystaną powłoką.


Makra

Rpmbuild korzysta z szeregu makr, które ułatwiają tworzenie pliku spec. Są one zdefiniowanie, między innymi w pliku /usr/lib/rpm/macros , część z nich możemy wyświetlić za pomocą polecenia: 

[user@X ~]# rpm --showrc


Przykładowe makra

Powyższe dwa makra często stosowane są do określania źródła programu w sekcji Source, dzięki czemu, jeśli pojawi się nowa wersja programu, wystarczy zmienić jego wersję w sekcji Version, a rpmbuild dostosuje automatycznie budowę pakietu do nowej wersji. Stosuje się je również w dalszej części pliku spec.

Przykład

Stasks

STasks to plazmoid mogący zastąpić menadżera zadań KDE4. Można go pobrać ze strony kde-look (w czasie pisania tego artykuły aktualna była wersja 0.5.1).
Budowę paczki rozpoczniemy od kompilacji programu. Jeśli nie mamy jeszcze zainstalowanych odpowiednich narzędzi to instalujemy je yumem. Dodatkowo potrzebujemy zainstalować pakiety wymagane przy kompilacji plazmodiów KDE4: 

[root@X ~]# yum install kdebase-workspace-devel qt-devel kde-filesystem

Rozpakowujemy pobrane archiwum i przechodzimy w konsoli do powstałego katalogu. Zgodnie z instrukcją zawartą w pliku INSTALL należy utworzyć katalog build, następnie przejść do niego i wykonać polecenia: 

[user@X ~]# mkdir build
[user@X ~]# cd build
[user@X ~]# cmake ../ -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix`
[user@X ~]# make

Program jest gotowy do instalacji, chcemy jednak zbudować własny pakiet rpm, dlatego wykonamy jedynie próbną instalację, np: 

[user@X ~]# mkdir ~/install_temp
[user@X ~]# make install DESTDIR="~/install_temp"

W katalogu domowym został utworzony katalog install_temp, następnie zostały w nim zainstalowane pliki kompilowanego programu: 

~/install_temp/usr/lib/kde4/plasma_applet_stasks.so
~/install_temp/usr/share/kde4/services/plasma-applet-stasks.desktop

W przypadku próbnej instalacji katalog install_temp traktowany jest jako katalog główny /. Oznacza to, że plik plasma_applet_stasks.so powinien zostać zainstalowany do /usr/lib/kde4/, a plasma-applet-stasks.desktop do /usr/share/kde4/services/. Informacje te będą potrzebne przy pisaniu pliku spec. Programy budowane przy pomocy cmake dostarczają informacji o instalowanych plikach - po wykonaniu próbnej instalacji w katalogu build utworzony został plik install_manifest.txt zawierający listę wszystkich instalowanych plików. Jest to przydatne szczególnie jeśli liczba takich plików jest duża.

Możemy przystąpić do utworzenia pliku spec. Źródła programu przenosimy do katalogu SOURCES. Pliki pobrane z kde-look mają dodane kilka cyfr przed właściwą nazwą programu - należy je wcześniej usunąć i pozostawić jedynie przykładowe stask-0.5.1.tar.gz.
Tworzymy plik w katalogu SPECS: 

[user@X ~]# rpmdev-newspec ~/rpmbuild/SPECS/stasks.spec

Otwieramy plik stasks.spec w ulubionym edytorze tekstu. Mamy jedynie wpisaną nazwę, uzupełniamy następne pola.

Plik spec jest gotowy: 

Summary: KDE4 plasmoid
Name: stasks
Version: 0.5.1
Release: 1%{?dist}
License: GPL
Group: User Interface/Desktops
URL: http://www.kde-look.org/content/show.php/STasks?content=99739
Source0: %{name}-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

BuildRequires: cmake, qt-devel, gcc-c++, kde-filesystem 
BuildRequires: kdebase-workspace-devel >= 4.2.0
Requires: kdebase-workspace >= 4.2.0

%description
Replacement of KDE4 Task manager.

%description -l pl
Stask to zawierający ciekawe elementy plazmoid, który może zostać użyty zamiast
menedżera zadań KDE4. 

%prep
%setup -q

%build
mkdir build
cd build
%{cmake_kde4} ..
make %{?_smp_mflags}

%install
%{__rm} -rf %{buildroot}
cd build
make install DESTDIR="%{buildroot}"

%clean
%{__rm} -rf %{buildroot}

%files
%defattr(-,root,root,-)
%{_libdir}/kde4/plasma_applet_stasks.so
%{_datadir}/kde4/services/plasma-applet-stasks.desktop

%changelog
* Sat Apr 18 2009 Imie Nazwisko <moj@majl> -0.5.1
- First release

Wystarczy teraz w katalogu SPEC wykonać polecenie rpmbuild -ba stasks.spec i rozpocząć proces budowy pakietów (w tym przypadku rpm i src.rpm).
Jeśli pojawi się nowa wersja programu prawdopodobnie wystarczy zmienić numer w sekcji version, umieścić źródła w katalogu SOURCES (usuwając zbędne cyfry w nazwie pliku) i uruchomić rpmbuild. Jeśli wraz z nową wersją program wzbogaci się o nowe pliki (np. wsparcie dla różnych języków) budowa rpm zakończy się niepowodzeniem z powodu braku wszystkich plików w sekcji %files. Należałoby wtedy znów wstępnie skompilować program i sprawdzić jakie nowe pliki są instalowane. Można temu częściowo zapobiec zastępując sekcję plików: 

%files
%defattr(-,root,root,-)
%{_libdir}/
%{_datadir}/
Zapis ten uwzględnia wszystkie pliki i podkatalogi instalowane przez program do katalogów /usr/share/ i /usr/lib/. Oczywiście, gdyby program wzbogacił się o plik instalowany do /usr/bin (mało prawdopodobne w przypadku plasmoidu) otrzymamy błąd budowy pakietu.

Tworzenie katalogu build jest często podawanym sposobem przy kompilacji programów wykorzystujących cmake. Nie jest to jednak konieczne. Jeśli nie chcemy go tworzyć odpowiednie sekcje pliku spec wyglądają następująco: 

%build
%{cmake_kde4} .
make %{?_smp_mflags}

%install
%{__rm} -rf %{buildroot}
make install DESTDIR="%{buildroot}"
Zostały usunięte wszystkie polecenia dotyczące tworzenia i przechodzenia do katalogu build. Dodatkowo makro %{cmake_kde4} . zawiera jedną kropkę, informującą że pliki do konfiguracyjne programu znajdują się w bieżącym katalogu (dwie informowały, że odpowiednie pliki znajdują się w katalogu nadrzędnym). Analogicznie możemy postąpić przy wstępnej kompilacji programu zastępując cmake ../ (polecenie wykonane w katalogu build) przez cmake ./ (polecenie wykonane bezpośrednio w katalogu powstałym po rozpakowaniu źródeł).
Wygląda na to, że katalog build jest zbędny. W przypadku wpisów do pliku spec jest to prawda - nie interesuje nas w jakim katalogu źródła są kompilowane, w przypadku samodzielnej kompilacji pozwala on na utrzymanie porządku w źródłach programu - jeśli zajdzie potrzeba ponownej kompilacji "czystej wersji" programu wystarczy wyczyścić jego zawartość i ponowić wszystkie kroki.

Jeśli powtarzamy proces budowania pakietu dla aktualnej wersji programu (być może poprawiamy plik spec) należy zwiększyć numer wydania w odpowiedniej sekcji, np: 

Release: 2%{?dist}
Dzięki temu możliwa będzie aktualizacja pakietu za pomocą polecenia rpm -Uvh.

Inne źródła pomocy, polecane strony

Linki do stron internetowych zamieszczono w artykule Zarządzanie_pakietami

Źródło „http://wiki.fedora.pl/wiki/Rpmbuild”