Rpmbuild

Z Fedora Wiki
Skocz do: nawigacji, wyszukiwania

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

  • BUILD - katalog, do którego rozpakowane zostaną źródła programu, następnie zostanie on skompilowany według instrukcji zawartych w pliku spec,
  • BUILDROOT - docelowy katalog w którym instalowany jest skompilowany wcześniej program,
  • RPMS - tutaj umieszczone zostaną gotowe do instalacji binarne pakiety rpm. Trafią one do podkatalogów określających architekturę, w powyższym przykładzie jest to i386 i noarch (np. dla pakietów zawierających dokumentację, czy pliki pomocy),
  • SOURCES- znajdą się tutaj spakowane źródła programów oraz dołączone patche,
  • SPECS - umieszczone tutaj zostaną pliki .spec z informacjami jak pakiet przygotować,
  • SPRMS - jeśli wybierzemy opcję budowy pakietu źródłowego, zostanie on umieszczony w tym katalogu. Nie ma potrzeby umieszczania tutaj samodzielnie ściąganych pakietów źródłowych.

Obsługa


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

  • rekompilacja pakietu źródłowego (src.rpm),
  • budowa pakietu w oparciu o plik spec,
  • budowa pakietu na podstawie spakowanego źródła programu, tak zwanego tarballa,

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

  • -ba - budowa zarówno pakietu binarnego i źródłowego,
  • -bb - budowa wyłącznie pakietu binarnego,
  • -bs - budowa jedynie pakietu źródłowego,
  • -bp - wykonanie jedynie sekcji %prep pliku spec, co sprowadza się do rozpakowania źródeł programu i zastosowaniu ewentualnych patchy,
  • -bc - wykonanie sekcji %prep, oraz %build, czemu odpowiada wykonaniu polecenia make podczas kompilacji programu,
  • -bi - wykonanie skcji %install, której odpowiada polecenie make install podczas kompilacji programu (pliki nie są instalowane w systemie, tylko we wskazanym katalogu),
  • -bl - sprawdzenie, czy sekcja %files zawiera wszystkie pliki, które mają być spakietowane (jeśli tak by nie było budowa binarnej paczki zakończy się błędem).

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


Tip.png
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:


  • Name: - nazwa budowanego programu,
  • Version: - wersja programu,
  • Release: 1%{?dist}: - określa numer wydania programu, w tym przypadku jest to 1, {?dist} dołącza numer dysrtybucji, na której pakiet był budowany, jeśli będzie to Fedora 10 dołączone zostanie .f10,
  • Summary: - krótkie podsumowanie charakteryzujące dany pakiet,
  • Group: - określa do jakiej grupy dany program należy, np: Aplikacje/Multimedia,
  • License: - opis na jakiej licencji program jest wydany, np: GPLv3,
  • URL: - odnośnik do strony internetowej programu,
  • Source0: - wskazuje na położenie źródeł programu. Ponieważ źródła są umieszczane w katalogu SOURCES wystarczy podać nazwę, np: smplayer-0.6.7.tar.bz2,
  • BuildRoot: - określa docelowy katalog, w który instalowany będzie program podczas budowy pakietu,
  • BuildRequires: - lista pakietów wymaganych do poprawnej kompilacji programu. Podaje się nazwy pakietów, oraz jeśli zachodzi taka potrzeba, zaznacza się ich minimalną wersję, np: kdebase-workspace-devel >= 4.2. Kompilacja wymaga instalacji pakietów -devel,
  • Requires: - lista pakietów wymaganych do działania programu. Jeśli pakietu z tej listy nie będzie zainstalowanego w systemie instalacja binarnej paczki rpm zgłosi błąd niespełnionych zleżności. Również stosuje się wymaganie minimalnej wersji pakiteu, np: kdebase-workspace >= 4.2,
  • %description - opis programu,
  • %prep - sekcja odpowiadająca za przygotowanie źródeł do kompilacji, co zwykle oznacza rozpakowanie ich do katalogu BUILD i nałożenie patchy,
    • %setup -q - makro, które automatycznie przygotowuje źródła do kompilacji, opcja -q rozpakuje źródła programu bez wyświetlania nazw plików,
  • %build - sekcja budowy pakietów, której odpowiada wykonanie ./configure && make podczas kompilacji programu,
    • %configure - makro uruchamiające ./configure,
    • make %{?_smp_mflags} - makro kompilujące program używając polecenia make,
  • %install - sekcja instalacji skompilowanego pakietu. Program jest instalowany w do określonego katalogu, nie instaluje się go w systemie,
    • rm -rf $RPM_BUILD_ROOT - usunięcie wcześniejszej instalacji programu, jeśli taka była,
    • make install DESTDIR=$RPM_BUILD_ROOT - instalacja programu do katalogu określonego przez $RPM_BUILD_ROOT - czyli do katalogu BUILDROOT,
  • %clean - sekcja, odpowiadająca za oczyszczenie katalogu BUILDROOT,
  • %files - zawiera listę wszystkich plików, które mają być spakietowane, czyli dołączone do paczki rpm. Jeśli nie wszystkie pliki utworzone podczas kompilacji zostaną dołączone do tej sekcji budowa pakietu zakończy się błędem,
    • %defattr(-,root,root,-) - makro, które ustala domyślne prawa dostępu dla instalowanych plików i katalogów. Opcja w zaprezentowanym kształcie pozostawi takie atrybuty plików, jakie zostały określone w wyniku kompilacji programu,
    • %doc - makro umieszczające pliki README, LICENSE, itp. w dokumentacji programu,
  • %changelog - sekcja, w której umieszczane są opisy zmiany w programie, oraz w pakiecie rpm. Charakteryzuje się ona restrykcyjną składnią, np:
%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:

  • %pre - skrypty wykonywane przed instalacją pakietu,
  • %post - skrypty wykonywane po instalacji paczki rpm,
  • %preun - skrypty wykonywane przed deinstalacją,
  • %postun - skrypty wykonywane po deinstalacji pakietu.

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


  • %{name} - makro korzystające z nazwy programu umieszczonej w sekcji Name,
  • %{version} - wersja programu zamieszczona w sekcji Version,

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.

  • {?dist} - dodaje oznaczenie dystrybucji, np: f9, f10, itp.
  • %{release} - makro pobierające numer wydania z sekcji Release,
  • %setup - makro przygotowujące źródła do kompilacji,
  • %patch0 - nałożenie patcha na źródła programy, w przypadku, jeśli patchy jest więcej niż jeden, stosuje się %patch1, %patch2, itd.
  • %defattr - ustala prawa dla plików i katalogów instalowanych przez tworzony pakiet,
  • %{_bindir} - określa katalog w którym instalowane będą programy, z reguły /usr/bin,
  • %{_libdir} - katalog, gdzie instalowane są biblioteki programu, najczęściej /usr/lib/, /usr/lib64,
  • %{_datadir} - katalog, gdzie instalowane są pliki wykorzystywane przez programy nie zależnie od architektury, np. ikony, domyślnie jest to /usr/share/,
  • %{_mandir} - położenie plików zawierających manuale, dostępne za pomocą polecenia man nazwa_programu, domyślnie jest to /usr/share/man

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.

  • Name: stasks - nazwa programu
  • Version: 0.5.1 - aktualna wersja programu,
  • 1%{?dist} - numer wydania, w tym przypadku 1 - zostawiamy jak jest,
  • Summary: KDE4 plasmoid - krótki opis pakietu,
  • Group: User Interface/Desktops - opis do jakiej grupy programów stasks należy,
  • License: GPL - opis licencji na której program został wydany, informacje o licencji powinny być dostępne na stronie projektu,
  • URL: http://www.kde-look.org/content/show.php/STasks?content=99739 - adres internetowy projektu,
  • Source0: %{name}-%{version}.tar.gz - opis gdzie znajdują się źródła programu.
    Użyto makr %{name}-%{version}, według tego co wpisaliśmy w polach Name, Version rpmbuild będzie szukać pliku stask-0.5.1-tar.gz. Źródła programy należy umieścić w 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.
  • BuildRoot: - zostawiamy bez zmian,
  • BuildRequires: - cmake, gcc-c++, qt-devel, kdebase-workspace-devel >= 4.2.0, kde-filesystem - lista pakietów potrzebnych do budowy programu. Są to narzędzia potrzebne do kompilacji źródeł programu, dodatkowo w przypadku kdebase-workspace-devel >= 4.2.0 umieszczamy wymaganie minimalnej wersji pakietu. Pakiet kde-filesystem zawiera dodatkowe makra które wykorzystamy w dalszej części pliku spec.
  • Requires: kdebase-workspace >= 4.2.0 - pakietu wymagane przy instalacji budowanej paczki. Ponieważ stasks nie będzie działał wraz z KDE 4.1 tutaj również wpisuje się minimalną wersję wymaganego pakietu.
  • %description - szczegółowy opis programu, może zawierać wiele linii. Najczęściej opis podaje się w języku angielskim, jeśli chcemy umieścić opisy w wielu językach można dodatkowo użyć, np: %description -l pl - opis w języku polskim,
  • %prep - przygotowanie pakietu do kompilacji,
    • %setup -q - wypakowanie źródeł programu, można pozostawić bez zmian,
  • %build - kompilacja źródeł programu, (ponieważ kompilacja programu korzysta z cmake wpis %configure należy usunąć),
    • mkdir build
    • cd build - zgodnie z instrukcjami tworzymy katalog build i przechodzimy do niego,
    • %{cmake_kde4} .. - makro odpowiadające za konfigurację źródeł. Etap ten odpowiada wykonaniu polecenia cmake ../ -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix` w czasie kompilacji programu ze źródeł. Makro to zawiera dodatkowe opcje konfiguracji.
    • make %{?_smp_mflags} - odpowiednik polecenia make - zostawiamy bez zmian,
  • %install - instalacja programu, analogiczna do make install DESTDIR="~/install_temp"
    • cd build - jeśli tworzyliśmu katalog build musimy do niego przejść
    • make install DESTDIR=$RPM_BUILD_ROOT - bez zmian,
  • %clean - oczyszczanie katalogów wykorzystanych przez rpmbuild - zostawiamy bez zmian,
  • %files - sekcja zawierająca wszystkie pliki, które muszą zostać zainstalowane przez rpmbuild,
    • %defattr(-,root,root,-) - ustalenie domyślnych uprawnień dla instalowanych plików, można zostawić bez zmian.
      Należy teraz umieścić listę plików instalowanych przez paczkę. Można tutaj po porostu skopiować zawartość pliku install_manifest.txt. Wiemy jednak że katalog /usr/lib definiuje makro %{_libdir} natomiast /usr/share - %{_datadir}, dlatego lista plików może wyglądać tak:
    • %{_libdir}/kde4/plasma_applet_stasks.so
    • %{_datadir}/kde4/services/plasma-applet-stasks.desktop
      Można również użyć makr %{_kde4_libdir} (/usr/lib), %{_kde4_datadir} (/usr/share), są one identyczne do wcześniejszych.
    • %doc - jeśli nie ma dodatkowej dokumentacji wpis można usunąć,
  • %changelog - opis zmian, np:
    • * Sat Apr 18 2009 Imię Nazwisko <moj@majl> -0.5.1
    • - Pierwszy pakiet RPM

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

Osobiste
Przestrzenie nazw

Warianty
Działania
Wiki
Nawigacja
Inne
Narzędzia