Zarządzanie pakietami

Z Fedora Wiki
Skocz do: nawigacji, wyszukiwania

Spis treści

Yum

Yum to system zarządzania pakietami. Jest to w Fedorze podstawowe narzędzie do instalacji, deinstalacji oraz aktualizacji oprogramowania. Pozwala na zminimalizowanie problemu piekła zależności, które jest tak widoczne podczas ręcznej instalacji plików RPM.

Yumex

Początkującym napewno łatwiej będzie wyszukiwać i instalować oprogramowanie korzystając z graficznej nakładki yumex.

yum install yumex

Pamiętaj tylko, że podczas działania yumex nie możesz kożystać z yum (bo to w istocie ten sam program), blokada ustaje po zakończeniu działania jednego. Z tego samego powodu nie możesz jednocześnie istalować oprogramowanie w dwóch terminalach na raz.

Konfiguracja

Echo-bug-48px.png
Szablon się ciut zmienił. Dokumentacja tego szablonu

yum.conf


Główny plik konfiguracyjny yuma to /etc/yum.conf Domyślny w Fedorze 10 plik yum.conf ma postać:
[main]
cachedir=/var/cache/yum
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
exactarch=1
obsoletes=1
gpgcheck=1
plugins=1
installonly_limit=3

# PUT YOUR REPOS HERE OR IN separate files named file.repo
# in /etc/yum.repos.d

Sekcja main odpowiada za ustawienia globalne. Może istnieć tylko jedna taka sekcja w całej konfiguracji.

Opis opcji

O ile nie zostało to zaznaczone, opcje yuma przyjmują wartość 1 - prawda, oraz 0 - fałsz, co odpowiada włączeniu, bądź wyłączeniu określonej funkcji.

  • cachedir — katalog, w którym zapisywane są ściągane paczki i metadane. Należy zadbać o wystarczającą ilość wolnego miejsca na partycji, gdzie jest ulokowany dany katalog.
  • keepcache — określa, czy po instalacji yum ma usuwać pobrane pakiety (0), czy też pozostawić je w katalogu określonym w cachedir (1).
  • debuglevel — określa ilość wyświetlanych informacji w przypadku wystąpienia błędów w programie. Wartości mieszczą się w przedziale 0-10 (domyślna - 2).
  • logfile - położenie pliku yum.log, zawierającego min. informacje o pakietach, które zostały zainstalowane, zaktualizowane, bądź usunięte przez yuma.
  • exactarch — określa, czy aktualizowane będą tylko pakiety o zgodnej architekturze, np. przy włączonej funkcji yum nie zainstaluje pakietu i686 jako aktualizacji pakietu i386.
  • obsoletes — funkcja włącza przetwarzanie przestarzałych pakietów podczas aktualizacji, bądź upgradu systemu.
  • gpgcheck — sprawdzanie sygnatur GPG instalowanych paczek. Szanujące się repozytoria podpisują cyfrowo swoje RPM-y. Pozwala to na jednoznaczne określenie pochodzenia danej paczki paczki i wykluczenie możliwości instalacji programu pochodzącego z nieznajomego (niezaufanego) źródła. Ze względów bezpieczeństwa usilnie zalecane jest włączenie tej opcji. Można wtedy bez obaw korzystać z mirrorów, bo żadna fałszywa paczka (np. z trojanem) nie zostanie zainstalowana (o ewentualnym problemie z niezgodnymi podpisami zostaniemy poinformowani).
  • plugins — włącza obsługę wtyczek przez yuma.
  • installonly_limit — określa liczbę wersji jądra systemu (ang. kernel) utrzymywanych w systemie. Domyślna wartość 3 oznacza, że zainstalowane będą maksymalnie 3 jądra. Jeśli podczas aktualizacji systemu będzie instalowane kolejne, najstarsze zostanie usunięte. Zainstalowane jądra będą widoczne w menu gruba, dając możliwość uruchomienia Fedory na wybranym z nich. Zaleca się ustalenie wartości installonly_limit na minimum 2. Daje to możliwość sprawdzenia, czy na nowym jądrze cały sprzęt działa poprawnie i powrotu do poprzedniej wersji, jeśli wystąpią problemy.


yum.repos.d


Katalog /etc/yum.repos.d/ służy do przechowywania informacji o dostępnych repozytoriach. Teoretycznie można dodawać wszystkie wpisy do pliku yum.conf, ale ze względu na przejrzystość i łatwość późniejszej administracji lepiej jest to robić w omawianym katalogu.

Przetwarzane są tylko pliki z rozszerzeniem .repo. W każdym takim pliku może znajdować się opis jednego lub większej ilości repozytoriów. Rozpatrzmy dalsze pozważania na poniższym przykładzie (standardowy plik /etc/yum.repos.d/fedora-updates.repo):

[updates]
name=Fedora $releasever - $basearch - Updates
failovermethod=priority
#baseurl=http://download.fedoraproject.org/pub/fedora/linux/updates/$releasever/$basearch/
mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f$releasever&arch=$basearch
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$basearch
  • [nazwa] — nazwa repozytorium. Nazwa ta musi byc unikalna (w naszym przykładzie jest to updates). Jest ona wyświetlana na ekranie podczas normalnej pracy z yumem.
  • name — nazwa opisowa repozytorium
  • failovermethod — określa sposób w jaki yum będzie wybierał serwery:
    • failovermethod=priority — według kolejności, zaczynając od pierwszego (wartość domyślna)
    • failovermethod=roundrobin — losowo
  • baseurl — URL do repozytorium. Ścieżka wskazująca położenie katalogu repodata. Obsługiwane są protokoły typu http://, ftp:// oraz file:// (adres lokalny). Możliwe jest podanie kilku adresów do jednego repozytorium (bardzo przydatne, gdyż niektóre mirrory czasami padają): baseurl=url://serwer1/ścieżka/do/repozytorium/ url://serwer2/ścieżka/do/repozytorium/ url://serwer3/ścieżka/do/repozytorium/
  • mirrorlist — ścieżka do pliku z listą serwerów lustrzanych dla danego repozytorium
  • enabled — włącza/wyłącza repozytorium
  • gpgcheck — opcja identyczna jak w pliku yum.conf


Inne przydatne opcje:

  • exclude — lista paczek, które nie będą brane pod uwagę w operacjach wykonywanych przez yuma. Użyteczne w przypadku korzystania z niekompatybilnych repozytoriów. Można w ten sposób nakazać yumowi wykluczenie określonych RPM-ów z danego repo. Dozwolone jest korzystanie ze znaków globalnych takich jak * lub ?. Nazwy paczek powinny być oddzielone spacjami. Przykład użycia: exclude=mplayer* libpng mutt alsa-*
  • includepkgs — lista “widzianych” przez yuma paczek w danym repozytorium. Przeciwieństwo opcji exclude. Pozwala na korzystanie z tylko określonych programów w danym repo. Przykładowo, jeśli wiemy, że w repozytorium development jest nowy kernel, który rozwiązuje wystepujący u nas problem, a jednocześnie nie chcemy aktualizować całego systemu do wersji niestabilnej, wystarczy, że w pliku /etc/yum.repos.d/fedora-devel.repo dopiszemy: includepkgs=kernel. Składnia jest taka sama jek w przypadku opcji exclude). Należy jeszcze pamiętać o włączeniu repozytorium (opcja enabled).


repozytoria


Standardowo po zainstalowaniu systemu mamy włączone dwa repozytoria:

  • fedora — pakiety, które są dostępne na płytach instalacyjnych
  • updates — wszelakie aktualizacje programów z repozytorium fedora

Oprócz wyżej wymienionych dostępne są również:

  • updates-testing — testowe wydania programów, które po niedługim czasie zostaną wydane w fedora-updates
  • rawhide — niestabilne, rozwojowe paczki, które znajdą się w przyszłej Fedorze. Jest to także główne repozytorium z aktualizacjami dla wszystkich testowych wydań Fedory.

Dodatkowe repozytoria.

W repozytoriach fedora i fedora-updates znajduje się wyłącznie wolne oprogramowanie. Brak jest również min. kodeków audio-wideo objętych ochroną patentową (głównie w USA), oraz binarnych sterowników o zamkniętym kodzie źródłowym. W celu dodania powyższych funkcjonalności do Fedory należ skorzystać z dodatkowych repozytoriów:

  • rpmusion — jest to główne źródło programów multimedialnych, oraz zamkniętych sterowników, takich jak sterowniki do kart graficznych Nvidia i Ati. Zawiera również wsparcie dla kart Wifi aktualnie nie wspieranych przez jądro systemu.

Instalacja rpmfusion sprowadza się do wydania polecenia:

su -c 'rpm -Uvh http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm\
 http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm'

Rpmfusion, wraz z domyślnymi repozytoriami fedory, dostarcza większość programów potrzebnych do codziennego korzystania z systemu. Zainstaluj koniecznie !

  • adobe — zawiera pakiety Adobe Flash Player, oraz Reader dla systemu Linuks. Można je zainstalować za pomocą polecenia (architektura x86):
su -c 'http://linuxdownload.adobe.com/adobe-release/adobe-release-i386-1.0-1.noarch.rpm'

Instalacja flasha dla architektury x64 jest opisana w poradniku

  • compiz-fusion — repozytorium popularnego programu compiz-fusion, zawierającego wiele ciekawych efektów pulpitu.

W celu instalacji repozytorium należy wykonać polecenie:

su -c 'rpm -Uvh http://www.linux-ati-drivers.homecall.co.uk/compiz-fusion-release-1-6.noarch.rpm'
  • google — repozytorium zawierające popularny program picasa. Picasa 3 znajduje się w repozytorium [google-testing].

Aby dodać to repozytorium należy utworzyć plik google.repo i wpisać do niego:

[google]
name=Google - i386
baseurl=http://dl.google.com/linux/rpm/stable/i386
enabled=1
gpgcheck=1
gpgkey=https://dl-ssl.google.com/linux/linux_signing_key.pub 

[google-testing]
name=Google Testing - i386
baseurl=http://dl.google.com/linux/rpm/testing/i386
enabled=1
gpgcheck=1
gpgkey=https://dl-ssl.google.com/linux/linux_signing_key.pub

Plik należy skopiować do katalogu /etc/yum.repos.d

  • kde — zawiera najnowsze wydania środowiska graficznego KDE. W celu jego instalacji należy skopiować znajdujący się na stronie projektu plik kde.repo do katalogu /etc/yum.repos.d. Najnowsze pakiety znajdują się w repozytorium [kde-testing], które jest domyślnie wyłączone.
Echo-bug-48px.png
Szablon się ciut zmienił. Dokumentacja tego szablonu

Obsługa

Echo-bug-48px.png
Szablon się ciut zmienił. Dokumentacja tego szablonu

Aktualizacja


Pierwszą czynnością po instalacji systemu, jaką wykonuje większość użytkowników Fedory jest aktualizacja systemu. Wynika to z faktu, iż po wydaniu nowej wersji zostają wypuszczane łaty naprawiające problemy bezpieczeństwa. Dodatkowo, w aktualizacjach znajduje się wiele programów z poprawioną funkcjonalnością i usuniętymi denerwującymi błędami.

Aktualizacja systemu

Do aktualizacji całego system służy poniższe polecenie:

yum update

Dostępne aktualizacje

Czasami chcemy tylko sprawdzić czy są dostępne jakieś nowe paczki. Służy do tego polecenie:

yum check-update

Aktualizacja poszczególnych programów

Czasami przydatna okazuje się możliwość aktualizacja poszczególnych programów, np. podczas upgradu dystrybucji. Nie zawsze mamy wystarczającą ilość wolnego miejsca na dysku lub chcemy podzielić cały proces aktualizacji na mniejsze części:

 yum update [nazwa_programu1] [nazwa_programu2] [...]

Tak więc, jeśli chcielibyśmy zaktualizować tylko program hexedit oraz wszystkie, których nazwa zaczyna się od słowa kde, powinniśmy wpisać jako root:

yum update hexedit kde\*

Przed znakiem * występuje znak backslash — bez niego powłoka systemowa próbowałaby zastąpić ciąg kde* nazwami plików występującymi w danym katalogu. W specyficznych sytuacjach polecenie bez backslasha wywołałoby efekt inny od zamierzonego.

Opcja --skip-broken

Może się zdarzyć, że yum nie był w stanie poprawnie rozwiązać zależności. Przyczyną mogą być niezaktualizowane wszystkie pliki na serwerze (prawdopodobnie taka aktualizacja jest właśnie wykonywana), samodzielna instalacja programów pochodzących z innych źródeł niż repozytoria Fedory, itp. Wyjściem z tej sytuacji jest opcja --skip-broken, która wykluczy z aktualizacji pakiety stwarzające problem :

yum update --skip-broken

Jeśli problem dotyczył serwerów, z reguły wystarczy trochę odczekać i ponowić pełny proces aktualizacji.

Instalacja oprogramowania


Do instalacji programów służy polecenie:

yum install nazwa_programu1 [nazwa_programu2] [...]

Yum sprawdzi, czy podane przez nas programy znajdują się w repozytoriach i następnie je zainstaluje. Zainstalowane zostaną także wszystkie pakiety, które są wymagane do poprawnej pracy instalowanych programów. W związku z tym liczba instalowanych programów może być znacznie większa od ilości podanych przez nas programów.


Jeśli chcemy, aby yum sprawdził zależności samodzielnie ściągniętych programów, zastosujemy opcję localinstall, np:

[root@X ~]# yum localinstall /home/user/rpmbuild/RPMS/i386/qnapi-0.1.6.rc2-1.i386.rpm

Należy podać pełną ścieżkę dostępu wraz z nazwą pakietu. Inną możliwością jest wcześniejsze przejście do katalogu w którym znajduje się pakiet, w takim przypadku wystarczy sama nazwa pakietu. W większości przypadków pakiety ściągane z internetu nie posiadają cyfrowego podpisu, dlatego też często stosuje się również opcję --nogpgcheck:

[root@X ~]# cd /home/user/rpmbuild/RPMS/i386
yum localinstall --nogpgcheck qnapi-0.1.6.rc2-1.i386.rpm


Reinstalacja oprogramowania


Czasem zachodzi potrzeba ponownej instalacji pakietu, np: gdy usunęliśmy ważny plik dostarczany przez ten pakiet. Oczywiście można taki pakiet usunąć i zainstalować go ponownie, lecz ze względu na zależności może nie być to takie proste.
Lepiej jest skorzystać z opcji reinstall, np:

[root@X ~]# yum reinstall binutils
(...)
=============================================================================================
 Pakiet             Architektura   Wersja                          Repozytorium        Rozmiar                                                                                            
=============================================================================================
Instalowanie:                                                                                
 binutils           i386           2.18.50.0.9-8.fc10              updates             3.1 M 
Usuwanie:
 binutils           i386           2.18.50.0.9-8.fc10              installed           7.7 M

Podsumowanie transakcji
=============================================================================================
Instalowanie       1 pakietów
Aktualizowanie     0 pakietów
Usuwanie           1 pakietów

Całkowity rozmiar pobierania: 3.1 M
W porządku? [t/N]:
Pakiety które wymagają binutils pozostaną nienaruszone. Wyjątkiem jest tu kernel, który może być instalowany wielokrotnie w systemie i jego reinstalacja zostanie pominięta.

Usuwanie zainstalowanych programów


Do usuwania zainstalowanych programów służy polecenie:

yum remove nazwa_programu1 [nazwa_programu2] [...]

Zamiast remove można użyć polecenia erase.

Zanim potwierdzi się ostatecznie chęć usunięcia programu, warto się zastanowić czy nie usuwamy ważnych, systemowych paczek, ponieważ analogicznie do instalacji, usunięte zostaną wszystkie pakiety, które do prawidłowego działania wymagały usuwanych przez nasz programów. Należy dokładnie przejrzeć wszystkie usuwane zależności.

Lista dostępnych programów


Do wyświetlania listy wszystkich dostępnych programów służy polecenie:

yum list

lub

yum list all

Wynik takiego polecenia nie będzie jednak nam zbytnio przydatny, gdyż ciężko będzie nam znaleźć określony program wśród kilku tysięcy innych aplikacji ;-) Powyższe polecenie może się raczej przydać tylko do policzenia ilości dostępnych paczek (podpowiedź: należy skorzystać z programu wc).

By zawęzić poszukiwania, należy dodać do polecenie jakiś fragment nazwy programu. Przykładowo, jeśli chcielibyśmy zobaczyć jakie są dostępne paczki z lame w nazwie, należałoby wykonać coś takiego:

[root@X ~]# yum list \*lame\*
Wczytane wtyczki: refresh-packagekit
Zainstalowane pakiety
lame.i386                                        3.98.2-2.fc10                                       installed
lame-devel.i386                                  3.98.2-2.fc10                                       installed
lame-libs.i386                                   3.98.2-2.fc10                                       installed
twolame-libs.i386                                0.3.12-3.fc10                                       installed
Dostępne pakiety
lame-mp3x.i386                                   3.98.2-2.fc10                                       rpmfusion-free
msv-relames.i386                                 1:1.2-0.2.20050722.3.4.fc10                         fedora
msv-relames-javadoc.i386                         1:1.2-0.2.20050722.3.4.fc10                         fedora
twolame.i386                                     0.3.12-3.fc10                                       rpmfusion-free
twolame-devel.i386                               0.3.12-3.fc10                                       rpmfusion-free
Tak jak w przypadku innych opcji, tak i tutaj można stosować znaki globalne. Należy tylko pamiętać o backslashach.

W pewnych specyficznych sytuacjach może przydać się również poniższe polecenie

 yum list extras

Wyświetla ono zainstalowane w systemie paczki, których nie ma w dostępnych repozytoriach.

Wyszukiwanie programów po opisie


Często się zdarza, że nie znamy dokładnej nazwy programu, ale wiemy co dany program robi. Z pomocą przychodzi nam wtedy poniższe polecenie:

yum search ciąg_znaków

Yum przeszukuje wtedy wszystkie opisy programów. Zapytania należy stawiać w języku angielskim.

Jeśli chcemy przykładowo znaleźć program do wypalania płyt, możemy wpisać:

yum search burn


Wyszukiwanie paczek zawierających określone pliki


Jeśli chcemy wyszukać pakiet zawierający określony plik, bądź bibliotekę skorzystamy z opcji:
yum provides nazwa_pliku
Przykładowo, szukamy pakietów zawierających libasound.so.2:
[root@X ~]# yum provides libasound.so.2
alsa-lib-1.0.18-6.rc3.fc10.i386 : The Advanced Linux Sound Architecture (ALSA) library
Repozytorium: fedora
Dopasowano z:
Inne        : libasound.so.2

alsa-lib-1.0.19-2.fc10.i386 : The Advanced Linux Sound Architecture (ALSA) library
Repozytorium: updates
Dopasowano z:
Inne        : libasound.so.2

alsa-lib-1.0.19-2.fc10.i386 : The Advanced Linux Sound Architecture (ALSA) library
Repozytorium: installed
Dopasowano z:
Inne        : Wyniki dostarczania: libasound.so.2

Jak widać, biblioteka libasound.so.2 jest dostarczana przez pakiet alsa-lib, jest ona dostarczana wraz z Fedorą (repozytorium fedora), dostępna jest aktualizacja pakietu (updates), która jest już zainstalowana w systemie (installed).

Zamiast provides można użyć whatprovides.

Uzyskiwanie opisu danego programu


Gdy chcemy poznać opis jakiegoś programu, np. przed jego zainstalowaniem, używamy poniższego polecenia:

yum info nazwa_programu1 [nazwa_programu2] [...]
Przykład:
[root@X ~]# yum info k3b
Zainstalowane pakiety
Nazwa              : k3b
Architektura       : i386
Wersja             : 1.0.5
Wydanie            : 6.fc10
Rozmiar            : 25 M
Repozytorium       : installed
Podsumowanie       : CD/DVD burning application for KDE
URL                : http://www.k3b.org
Licencja           : GPLv2+
Opis               : K3b provides a comfortable user interface to perform most CD/DVD
                   : burning tasks. While the experienced user can take influence in all
                   : steps of the burning process the beginner may find comfort in the
                   : automatic settings and the reasonable k3b defaults which allow a quick
                   : start


Operacje na grupach programów


Operacje na poszczególnych paczkach są fajne, ale co zrobić, gdy chcemy zainstalować całe KDE, Gnome lub wsparcie dla danego języka? Yum pozwala operować na takich grupach paczek - należy skorzystać wtedy z poleceń takich jak grouplist, groupinfo, groupinstall, groupremove czy groupupdate.

yum grouplist

Listę dostępnych grup uzyskujemy wpisując poniższe polecenie:

yum grouplist

Możliwe jest również wyświetlenie grup ukrytych:

yum grouplist hidden

yum groupinfo

Mając już listę grup, wypadałoby sprawdzić co taka grupa dostarcza:

yum groupinfo "nazwa_grupy1" ["nazwa_grupy2"] [...]

yum groupinstall

By zainstalować jakąś grupę, w terminalu wpisujemu:

yum groupinstall "nazwa_grupy1" ["nazwa_grupy2"] [...]

Przykładowo, jeśli chcielibyśmy zainstalować programy związane z bazami danych MySQL oraz PostgreSQL, należałoby wydać poniższe polecenie:

yum groupinstall "MySQL Database" "PostgreSQL Database"

yum groupremove

Możliwe jest też usunięcie całej grupy oprogramowania:

yum groupremove "nazwa_grupy1" ["nazwa_grupy2"] [...]

Warto tylko zwrócić uwagę na odinstalowywane zależności.

yum groupupdate

Jeśli chcemy zaktualizować określoną grupę, nie przeprowadzając jednocześnie aktualizacji całego systemu wykonamy polecenie:

yum groupdate "nazwa_grupy1" ["nazwa_grupy2"] [...]

Proszę zwrócić uwagę, że nazwy grup podawane są w cudzysłowach.

Usuwanie plików tymczasowych


Jeśli w pliku yum.conf ustawiliśmy opcję keepcache=1 pobierane pakiety nie będą automatycznie usuwane.

Oczywiście można pozbyć się niepotrzebnych nam już RPM-ów:

yum clean packages

Wydanie powyższej komendy spowoduje ich usunięcie. Można też usunąć tylko dane o dostępnych paczkach:

yum clean headers

Usunięcie wszystkiego na raz też jest możliwe:

yum clean all

W wyniku powyższych operacji kasowane są pliki z katalogu /var/cache/yum (ustawienie domyślne, które można zmienić opcją cachedir).

Opcje wywołania programu


Składnia:

yum [opcje] polecenie nazwa_paczki...

Spis ważniejszcych opcji:

  • -h, --help — wypisanie pomocy
  • -yyum nie pyta się o potwierdzenie polecenia, tylko je od razu wykonuje. Ostrożnie przy usuwaniu programów!
  • -c plik_konfiguracyjny — określa położenie pliku konfiguracyjnego. Pozwala na użycie innego pliku konfiguracyjnego niż /etc/yum.conf.
  • --version — wypisuje wersję programu i kończy jego działanie,
  • --nogpgcheck — wyłącza sprawdzanie cyfrowych sygnatur pakietów, odpowiada opcji gpgcheck=0 w yum.conf
  • --noplugins — wyłącza wszystkie zainstalowane wtyczki. Odpowiadająca opcja w pliku konfiguracyjnym: plugins=0,
  • --enablerepo=nazwa — pozwala na tymczasowe włączenie repozytorium. Odpowiadająca opcja w pliku konfiguracyjnym repozytorium: enabled=1,
  • --disablerepo=nazwa — pozwala na tymczasowe wyłączenie repozytorium. Przydatne w przypadku problemów z zależnościami. Odpowiadająca opcja w pliku konfiguracyjnym repozytorium: enabled=0,
  • --exclude=nazwa_paczki — pozwala na tymczasowe wykluczenie danej paczki z całego procesu. Można stosować znaki globalne. Odpowiadająca opcja w pliku konfiguracyjnym repozytorium: exclude,
  • -C — nakazuje wykonywanie wszystkich operacji korzystając tylko z cache’a. Yum nie ściąga wtedy żadnych plików z internetu, co skraca czas operacji typu info, list, provides czy search. Wymagane jest wcześniejsze wydanie polecenia:
yum makecache

Jeśli wykonujemy wiele zapytań po rząd, to można skorzystać również z shella yuma:

yum shell

yum-utils


yum-utils to malutka paczuszka z wtyczkami i programami korzystającymi z yuma, pozwalająca na łatwiejsze administrowanie RPM-ami, a nawet własnym repozytorium. Tutaj znajdziesz opis kilku z nich:

package-cleanup

Znajduje niepotrzebne pakiety lub sprawdza problemy z zależnościami

  • Lista dostępnych bibliotek, które nie są wymagane przez inne programy. Gdy stwierdzimy, że nie są potrzebne, możemy je spokojnie usunąć:
package-cleanup --leaves
  • Możemy pójść krok dalej i wyświetlić wszystkie dostępne paczki, które nie są wymagane przez inne programy:
package-cleanup --leaves --all

Po każdorazowym usunięciu jakiejś paczki, należy powyższą czynność powtórzyć, gdyż mogą wyświetlić się kolejne pozycje do usunięcia.

  • Usunięcie starych kerneli (ale tylko te zainstalowane z RPM-a) i pozostawienie dwóch najnowszych:
package-cleanup --oldkernels

Ilość kerneli określana w pliku yum.conf jest osobnym ustawieniem. Polecenie zostawi 2 nawet jeśli w pliku yum.conf masz ustawione 3.

  • Informacja o wszystkich problemach z zależnościami w naszym systemie. Wyjdą na jaw wszystkie efekty bezmyślnego stosowania opcji —force oraz —nodeps podczas ręcznej instalacji RPM-ów:
package-cleanup --problems

yumdownloader

ściąga (gdy mu się nakaże, to wraz zależnościami) pakiety do określonego katalogu, ale ich nie instaluje. Przydatne dla osób chcących pościągać aktualizacje, a potem przenieść je na komputer bez dostępu do internetu.

  • Sposób użycia:
yumdownloader [opcje] nazwa_paczki1 [nazwa_paczki2] [...]

Możliwe opcje to:

-destdir=KATALOG_DOCELOWY — katalog, do którego zostaną zapisane paczki. Jeśli pominiemy tę opcję, pliki zostaną zapisane w katalogu bieżącym.
-urls — zamiast ściągania plików na dysk, program poda URLe plików
-resolve — ściąga pliki wraz z zależnościami
-source — ściąga pakiety SRPM, a nie gotowe binarki

yum-complete-transaction

Znajduje niedokończone lub anulowane transakcje i próbuje je dokończyć. Możliwe, że potrzeba uruchomić go więcej niż raz do zakończenie wszystkich przerwanych transakcji.

inne

Paczka yum-utils oferuje jeszcze kilkanaście innych poleceń. Jeśli chcesz stworzyć własne repozytorium, powinieneś sprawdzić pozostałe.

RPM Package Manager

Echo-bug-48px.png
Szablon się ciut zmienił. Dokumentacja tego szablonu

RPM to podstawowe narzędzie do zarządzania pakietami w Fedorze jak i w wielu innych dystrybucjach. Wszystkie inne programy, takie jak Yum korzystają właśnie z RPM do zarządzania pakietami. Od razu nasuwa się pytanie: po co uczyć się obsługi RPM, skoro Yum potrafi samemu rozwiązywac zależności, ściągać pakiety z Internetu i aktuliazować cały system jednym poleceniem? W RPM trzeba to przecież wszystko wykonywać ręcznie. W zrozumieniu tego problemu być może pomoże porównanie tych programów do pisania w C (yum) oraz w asemblerze (RPM). C pozwala łatwo pisać programy i szybko uzyskiwać wymierne rezultaty, ale nie daje takiej pełni możliwości jak asembler.

Nazwy pakietów



Zanim zacznie się korzystać z RPM, warto zapoznać się z nazewnictwem pakietów RPM:

<nazwa>-<wersja>-<wydanie>.<architektura>.rpm
  • nazwa — nazwa programu/pakietu,
  • wersja — wersja programu (wersja, którą pobrano ze strony danego projketu, do zbudowania pakietu),
  • wydanie — określa numer wydania danego pakietu. Często też zawiera skrót określający dla jakiej dystrybucji jest przeznaczony. Przykładowo “mdk” to Mandriva, a “f10” to Fedora 10,
  • architektura — określa dla jakiej architektury przeznaczony jest dany pakiet, np. i386, i686, ppc, x86_64 lub noarch dla pakietów niezależnych od sprzętu (np. dokumentacja czy czcionki).

Przykład:

gtk+-1.2.10-66.fc10.i386

Oprócz tego dostępne są również pakiety SRPM, czyli ładnie spakowane źródła wraz z plikiem spec pozwalającym na zbudowanie binarnego pakietu RPM. Przykład:

gtk+-1.2.10-66.src.rpm

Ponadto, biblioteki są rozprowadzane jako dwie oddzielne paczki. Jedna zawiera gotowe binaria, które są potrzebne do działania programów, a druga pliki potrzebne do kompilacji innych programów (np. pliki nagłówkowe). Pozwala to na zaoszczędzenie miejsca na dysku. Te drugie mają dołączony do nazwy ciąg “-devel”. Przykład:

gtk+-devel-1.2.10-66.fc10.i386

Z powyższego podziału wynikają często problemy początkujących użytkowników. Przykładowo, kompilując jakiś program, dostają informację, że w systemie brakuje biblioteki «gtk+». Zamiast doinstalować pakiet «gtk+-devel», to ręcznie kompilują «gtk+». Nie dość, że śmiecą w systemie, to dodatkowo zawalają dysk duplikatami tych samych programów.

Na koniec warto wspomnieć o istnieniu pakietów z “-debuginfo” w nazwie. Służą one tylko i wyłącznie do debugowania aplikacji, np. przy użyciu GDB. Jeśli nie jesteś programistą i nie zamierzasz poprawiać danego programu, to te paczki są Ci całkowicie niepotrzebne.

Instalacja i aktualizacjia



Przygodę z RPM zwykle zaczyna się od instalacji jakiegoś pakietu:

rpm -i xxx.rpm
  • rpm — polecenie operujące na pakietach
  • -i — nakazuje RPM-owi instalację paczki (skrót od “install”)
  • xxx.rpm — nazwa pliku, który chcemy zainstalować


Do aktualizacji programów służy polecenie:

rpm -U xxx.rpm

Do podanych wyżej poleceń zwykle dołącza się:

  • -h — rysuje znaki hash (#), by pokazać stopień postępu (skrót od “hash”)
  • -v — tryb “gadatliwy”; RPM informuje wtedy użytkownika o tym, co w danej chwili wykonuje (skrót od “verbose”)


W ten sposób uzyskaliśmy polecenie, które jest najczęściej wykorzystywane do instalacji/aktualizacji pakietów:

rpm -Uvh xxx.rpm

Tak więc, do instalacji oprogramowania używaj parametru -U, a nie -i. Wyjątkiem jest kernel, którego zawsze instaluje się z parametrem -i. Dlaczego nie należy nigdy aktualizować jądra? Powód jest prosty — jest to na tyle krytyczny fragment systemu, że mały błąd w tej paczce może spowodować unieruchomienie całego systemu. Najbezpieczniejsze więc będzie instalowanie nowego jądra obok tego działającego. Po jego przetestowaniu i upewnieniu się, że działa poprawnie, można potem spokojnie pousuwać jego starsze wersje.

Często zdarza się, że nie możemy zainstalować jakiegoś pakietu, ponieważ do działania wymaga on instalacji innego, rpm pozwala na instalację wielu programów jednocześnie:

rpm -Uvh xxx.rpm yyy.rpm zzz.rpm

Moża również stosować metaznaki:

rpm -Uvh a*.rpm
rpm -Uvh *.rpm


Wybrane opcje instalacji


  • --oldpackage — zezwala na zastąpienie zainstalowanego pakietu jego starszą wersją. Powodów tego, że chcemy powrócić do starszej wersji używanych pakietów być wiele, np. nowsza wersja programu ma poważne błedy, które wykluczają ją z normalnego użytkowania (od niestabilnego działania aplikacji do nieuruchamiania się systemu włącznie). Teoretycznie możemy program usunąć i zainstalować jego starszą wersję — praktycznie rzecz biorąc nie zawsze jest to wykonalne ze względu na zależności. Przykładowo, usunięcie «glibc» wymagałoby usunięcia prawie całego systemu. W takich sytuacjach z ratunkiem przychodzi nam opcja “–-oldpackage”:
rpm -Uvh --oldpackage xxx.rpm
  • --replacepkgs — instaluje pakiety nawet jeśli są zainstalowane w systemie. Opcję tą często stosuje się w połączeniu z “--oldpackage”:
rpm -Uvh --replacepkgs xxx.rpm
rpm -Uvh --oldpackage --replacepkgs xxx.rpm
  • --replacefiles — zezwala na instalację pakietów nawet jeśli zastępują one pliki z innych, już zainstalowanych:
rpm -Uvh --replacefiles xxx.rpm
  • --force, --nodeps — powoduje instalację pakietu bez sprawdzania zależności. Brzmi zachęcająco? Tylko na początku… Naprawdę jest to tylko zamiatanie śmieci pod dywan. Wcześniej lub później wszystko i tak wyjdzie na wierzch. Tak zainstalowany program najprawdopodobniej nie będzie działać ze względu na brak bibliotek czy innych wymaganych programów. Co więcej, użycie tego parametru może nadpisać nam pliki z innych pakietów, przez co i one mogę przestać poprawnie funkcjonować. Można też zapomnieć o bezproblemowej aktualizacji/upgradzie systemu przy użyciu yuma lub Anacondy, ze względu na zniszczenie zależności pomiędzy pakietami. Jak widać, “–-force”, czy “--dodeps” powinno być stosowane bardzo rzadko (praktycznie rzecz biorąc to w ogóle, gdyż w 99.9% przypadków można problem rozwiązać w inny sposób).
rpm -Uvh --force --nodeps xxx.rpm


Deinstalacja



Wiemy już jak instalować/aktualizować programy. Warto więc nauczyć się teraz jak je usuwać z systemu:

rpm -e nazwa_pakietu

Parametr `-e’ to skrót od “erase”. Należy podkreślić, iż nazwa_pakietu to nie nazwa_pliku. Podawanie rozszerzenia rpm jest błędne i poniższa komenda zakończy się niepowodzeniem:

rpm -e gtk+-1.2.10-66.fc10.i386.rpm

Poprawne będzie wpisanie jednego z tych przykładów:

rpm -e gtk+
rpm -e gtk+-1.2.10
rpm -e gtk+-1.2.10-66
rpm -e gtk+-1.2.10-66.fc10.i386


Wybrane opcje deinstalacji



  • --allmatches - usuwa wszystkie wersje pakietu, które odpowiadają wprowadzonej nazwie, np:
rpm -e kernel-devel --allmatches
  • --nodeps — usuwa pakiet bez sprawdzania zależności. Konsekwencje stosowania są analogiczne jak przy instalacji:
rpm -e --nodeps xxx.rpm
  • --test — pozwala na stwierdzenie jak przebiegłaby dana operacja bez faktycznego usuwania pakietu z systemu. Pokazuje między innymi zależności; można jej również użyć podczas instalacji/aktualizacji, np:
[root@X ~]# rpm -e --test gimp
błąd: Niespełnione zależności:
      gimp >= 2:2.4 jest wymagany przez (zainstalowany) gimp-help-2.4.2-1.fc10.noarch


Zapytania



Rpm tworzy bazę danych zawierającą informację o wszystkich zainstalowanych programach. Dzięki temu możliwe jest uzyskanie informacji o pakietach, łączących je zależnościach, plikach które dostarczają itp.
Aby uzyskać informacje nie jest wymagane logowanie jako root - każdy użytkownik może uzyskać żądane informacje.


Podstawowe zapytanie ma postać:

rpm -q [opcje_wyboru] [opcje_zapytania]

Najprostsze użycie sprowadza się do podania nazwy pakietu, np:

[user@X ~]# rpm -q kernel
kernel-2.6.27.19-170.2.35.fc10.i686


Wybrane opcje



  • -a — powoduje odpytanie wszystkich zainstalowanych pakietów.
rpm -qa kernel

W przeciwieństwie do pierwszego przykładu, w którym odpytywany był pakiet o dokładnie podanej przez nas nazwie, zadając pytanie z opcją "-a" możemy stosować znaki globalne:

[user@X ~]# rpm -qa kernel*
kernel-headers-2.6.27.19-170.2.35.fc10.i386
kerneloops-0.12-1.fc10.i386
kernel-devel-2.6.27.19-170.2.35.fc10.i686
kernel-firmware-2.6.27.19-170.2.35.fc10.noarch
kernel-2.6.27.19-170.2.35.fc10.i686
  • grep i sort - proste odfiltrowanie i sortowanie wyników zewnętrznym narzędziem
[user@X ~]# rpm -qa |grep kernel|sort
kernel-2.6.27.12-170.2.5.fc10.x86_64
kernel-devel-2.6.27.12-170.2.5.fc10.x86_64
kernel-firmware-2.6.27.19-170.2.35.fc10.noarch
kernel-headers-2.6.27.19-170.2.35.fc10.x86_64
kerneloops-0.12-1.fc10.x86_64
  • -i — wyświetla podstawowe informacje o pakiecie:
[user@X ~]# rpm -qi stasks
Name        : stasks                       
Version     : 0.4                              
Release     : 1.fc10                        
Install Date: śro, 11 mar 2009, 20:04:43     
Group       : Applications/System           
Size        : 127945                         
Signature   : (none)
URL         : http://www.kde-look.org/content/show.php/STasks?content=99739
Summary     : Stasks
Description : Stask to zawierający ciekawe efekty plazmoid, który może zostać użyty zamiast menedżera zadań KDE4
  • -l, --list — zwraca pliki dostarczane przez pakiet:
[user@X ~]# rpm -ql stasks
/usr/lib/kde4/plasma_applet_stasks.so
/usr/share/kde4/services/plasma-applet-stasks.desktop

Czasami jedna paczka dostarcza kilka programów, łatwo je znaleźć filtrując (grep) pliki w katalogach bin, sbin:

[user@X ~]# rpm -ql yum-utils |grep bin
/usr/bin/debuginfo-install
/usr/bin/find-repos-of-install
/usr/bin/package-cleanup
/usr/bin/repo-graph
/usr/bin/repo-rss
/usr/bin/repoclosure
/usr/bin/repodiff
/usr/bin/repomanage
/usr/bin/repoquery
/usr/bin/reposync
/usr/bin/repotrack
/usr/bin/verifytree
/usr/bin/yum-builddep
/usr/bin/yum-debug-dump
/usr/bin/yum-groups-manager
/usr/bin/yumdownloader
/usr/sbin/yum-complete-transaction
  • --changelog — wyświetla informacje o zmianach dla podanego pakietu:
[user@X ~]# rpm -q --changelog inkscape
* wto sty 13 2009 Lubomir Rintel <lkundrak@v3.sk> - 0.46-6.1
- Fix crash with bitmap font (#477158)                      

* sob paź 18 2008 Lubomir Rintel <lkundrak@v3.sk> - 0.46-6
- Fix color sliders with recent GTK (#467431)
(...)
  • -f — wyświetla pakiet, który dostarcza podany przez nas plik:
[user@X ~]# rpm -qf /usr/share/kde4/services/plasma-applet-stasks.desktop
stasks-0.4-1.fc10.i386

Czasami chcielibyśmy wiedzieć, z której paczki jest dany program/komenda, nie trzeba męczyć się przy użyciu locate, find, whereis. Żeby się dowiedzieć skąd jest komenda "mkdir" wystarczy:

[user@X ~]# rpm -qf $(which mkdir)
coreutils-6.12-20.fc10.x86_64

O ile nie istnieje alias o tej samej nazwie, wówczas trzeba wyłuskać ścieżkę osobno (which mkdir)

  • --whatrequires — zwraca listę programów, które do działania wymagają podanego w zapytaniu pakietu:
[user@X ~]# rpm -q --whatrequires gcc
gcc-c++-4.3.2-7.i386
  • --requires — zwraca listę programów wymaganych do działania podanego pakietu:
[user@X ~]# rpm -q --requires gcc
/bin/sh
/sbin/install-info
binutils >= 2.17.50.0.17-3
cpp = 4.3.2-7
glibc-devel >= 2.2.90-12
(...)
  • --whatprovides — zwraca listę pakietów, które dostarczają podaną własność:
[user@X ~]# rpm -q --whatprovides stasks
stasks-0.4-1.fc10.i386
  • --provides — zwraca udostępniane właściwości:
[user@X ~]# rpm -q --provides stasks
plasma_applet_stasks.so
stasks = 0.4-1.fc10
stasks(x86-32) = 0.4-1.fc10


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, czy 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.

Wprowadzenie do kompilacji programów


Ściągając programy najczęściej nie pobieramy gotowych do instalacji i użycia pakietów binarnych, ale ich źródła, które musimy własnoręcznie skompilować. Również podczas rekompilacji pakietów źródłowych programy są kompilowane, a następnie tworzony jest plik .rpm. Tworząc nowy pakiet rpm również zaczniemy od kompilacji programu.
Kompilując program musimy mieć zainstalowany odpowiedni kompilator. W przypadku Fedory jest to gcc:

[root@X ~]# yum install gcc gcc-c++

Wraz z kodem źródłowym, w plikach readme, install itp. z reguły dołączony jest opis jak dany program skompilować. Najczęściej wymaga to wykonania trzech etapów:

  1. ./configure - uruchamia skrypt, który przygotuje pliki do kompilacji, oraz sprawdzi, czy w systemie zainstalowane są wszystkie wymagane do kompilacji programy. Należy pamiętać, że w przypadku braku jakiś programów, czy bibliotek trzeba zainstalować odpowiednie pakiety -devel, np: jeśli wykonując ./configure dostaniemy informację alsa-lib - not found zainstalujemy pakiet alsa-lib-devel. Skrypt ./configure często uruchamiany jest z argumentami, których listę otrzymamy wykonując ./configure --help. Daje to możliwość włączenia/wyłączenia dodatkowych funkcjonalności programów, określania miejsca instalacji skompilowanego programu, itp. Np. często stosowanym argumentem jest
    ./configure --prefix=/usr, który określa, że program ma być zainstalowany w katalogu /usr,
  2. make - na tym etapie program jest kompilowany i jeśli proces ten zakończy się sukcesem będzie on gotowy do instalacji,
  3. make install - instaluje program w systemie, aby pogram zainstalować wymagane jest posiadanie uprawnień root'a. Przygotowując się do skonstruowania pliku spec często stosuje się opcję make install DESTDIR="/TU_KATALOG", dzięki czemu program nie zostanie zainstalowany w systemie, ale w określonym wcześniej katalogu. Pozwoli to na przetestowanie, czy instalacja zakończy się sukcesem, oraz otrzymamy listę plików, które zależy spakietować, wraz z określeniem, gdzie mają być zainstalowane. Próbną instalację wykonuje się będąc zalogowanym jako zwykły użytkownik.

Pogramy tworzone dla środowiska Kde 4 do kompilacji wykorzystują cmake:

[root@X ~]# yum install cmake

W takim przypadku pierwszy etap kompilacji najczęściej polega na stworzeniu katalogu build i wykonaniu w nim:

  1. cmake .. Dwukropek określa, że pliki wymagane do kompilacji znajdują się w katalogu nadrzędnym. W przypadku programów dla KDE4 często polecenie cmake ma postać:
cmake ../ -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix`

W przypadku programów napisanych w Qt4, nie korzystających jednak z bibliotek Kde 4, np. qnapi, pierwszy etap kompilacji może mieć postać:

  1. qmake-qt4 xxx.pro, gdzie xxx to z reguły nazwa programu.

W takim przypadku, w Fedorze 10, należy najpierw zainstalować pakiet:

[root@X ~]# yum install qt-devel

Jak widać pierwszy etap kompilacji może przybierać różne formy. Którą należy wybrać można określić w dość prosty sposób. Jeśli w rozpakowanych źródłach znajduje się plik configure, uruchomimy ./configure, w przypadku, kiedy znajduje się tam plik CMakeLists.txt, z reguły utworzymy katalog build i wykonamy cmake, jeśli źródła zawierają plik xxx.pro wykonamy qmake-qt4.

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ąć. 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 pliki 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 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 fakt, że nie wszystkie one bazują na rpm, twórcy programów prawie nigdy nie załączają odpowiednich plików spec. Z tego względu 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ówna pakietu binarnego i źródłowego, -tb tylko binarnego itp.

Podstawowy opis plików spec


Echo-bug-48px.png
Szablon się ciut zmienił. Dokumentacja tego szablonu

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 - skryptu 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. Stosowane są 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
Osobiste
Przestrzenie nazw

Warianty
Działania
Wiki
Nawigacja
Inne
Narzędzia