Zarządzanie pakietami: Różnice pomiędzy wersjami

Z Fedora Wiki
Skocz do: nawigacji, wyszukiwania
m (Zapytania)
(repozytoria: - compiz)
 
(Nie pokazano 34 wersji utworzonych przez 4 użytkowników)
Linia 1: Linia 1:
{{CiachMake}}
+
<small>''(alias: [[rpm]] | [[yum]])''</small>
 
=='''Yum'''==
 
=='''Yum'''==
  
 
Yum to [http://pl.wikipedia.org/wiki/System_zarz%c4%85dzania_pakietami system zarządzania pakietami]. Jest to w Fedorze podstawowe narzędzie do instalacji, deinstalacji oraz aktualizacji oprogramowania. Pozwala na zminimalizowanie problemu [http://pl.wikipedia.org/wiki/Piek%C5%82o_zale%C5%BCno%C5%9Bci piekła zależności], które jest tak widoczne podczas ręcznej instalacji plików RPM.
 
Yum to [http://pl.wikipedia.org/wiki/System_zarz%c4%85dzania_pakietami system zarządzania pakietami]. Jest to w Fedorze podstawowe narzędzie do instalacji, deinstalacji oraz aktualizacji oprogramowania. Pozwala na zminimalizowanie problemu [http://pl.wikipedia.org/wiki/Piek%C5%82o_zale%C5%BCno%C5%9Bci piekła zależności], które jest tak widoczne podczas ręcznej instalacji plików RPM.
 
====Yumex====
 
====Yumex====
Początkującym napewno łatwiej będzie wyszukiwać i instalować oprogramowanie korzystając z graficznej nakładki '''yumex'''.
+
Początkującym na pewno łatwiej będzie wyszukiwać i instalować oprogramowanie korzystając z graficznej nakładki '''yumex'''.
 
<pre>yum install yumex</pre>
 
<pre>yum install yumex</pre>
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.
+
Pamiętaj tylko, że podczas działania yumex nie możesz korzystać 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 instalować oprogramowania w dwóch terminalach na raz.
  
 
===Konfiguracja===
 
===Konfiguracja===
{{Box/Tip|Tip|Szczegółowy opis wszystkich opcji można znaleźć w manualu:''' man yum.conf'''}}
+
{{Box|Tip|Tip|Szczegółowy opis wszystkich opcji można znaleźć w manualu:''' man yum.conf'''}}
 
==== yum.conf ====
 
==== yum.conf ====
 
----
 
----
Linia 39: Linia 39:
 
*'''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).
 
*'''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.
 
*'''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.
+
*'''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 [[GRUB|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 ====
 
==== yum.repos.d ====
Linia 47: Linia 46:
 
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.
 
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):  
+
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 rozważania na poniższym przykładzie (standardowy plik /etc/yum.repos.d/fedora-updates.repo):  
 
<pre>[updates]
 
<pre>[updates]
 
name=Fedora $releasever - $basearch - Updates
 
name=Fedora $releasever - $basearch - Updates
Linia 61: Linia 60:
 
**'''failovermethod=priority''' — według kolejności, zaczynając od pierwszego (wartość domyślna)
 
**'''failovermethod=priority''' — według kolejności, zaczynając od pierwszego (wartość domyślna)
 
**'''failovermethod=roundrobin''' — losowo
 
**'''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/
+
*'''baseurl''' — URL do repozytorium. Ścieżka wskazująca położenie katalogu repodata. Obsługiwane są protokoły typu <nowiki>http://</nowiki>, 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
 
*'''mirrorlist''' — ścieżka do pliku z listą serwerów lustrzanych dla danego repozytorium
 
*'''enabled''' — włącza/wyłącza repozytorium
 
*'''enabled''' — włącza/wyłącza repozytorium
Linia 71: Linia 70:
 
*'''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-*  
 
*'''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).
 
*'''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 ====  
 
==== repozytoria ====  
Linia 78: Linia 76:
 
Standardowo po zainstalowaniu systemu mamy włączone dwa repozytoria:
 
Standardowo po zainstalowaniu systemu mamy włączone dwa repozytoria:
  
* fedora — pakiety, które są dostępne na płytach instalacyjnych
+
* fedora — pakiety, które są dostępne na płytach instalacyjnych,
* updates — wszelakie aktualizacje programów z repozytorium fedora
+
* updates — wszelakie aktualizacje programów z repozytorium fedora,
  
 
Oprócz wyżej wymienionych dostępne są również:
 
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
+
* 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.
 
* 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.'''
 
'''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:
+
W repozytoriach fedora i fedora-updates znajduje się wyłącznie wolne oprogramowanie. Nie znajdują się w nich min. kodeki audio-wideo objęte ochroną patentową (głównie w USA), oraz binarne sterowniki o zamkniętym kodzie źródłowym. W celu dodania powyższych funkcjonalności do Fedory należ skorzystać z dodatkowych repozytoriów:
 
*'''[http://rpmfusion.org/ 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.
 
*'''[http://rpmfusion.org/ 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:
 
Instalacja rpmfusion sprowadza się do wydania polecenia:
<pre>su -c 'rpm -Uvh http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm\
+
<pre>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'</pre>
 
  http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm'</pre>
  
 
Rpmfusion, wraz z domyślnymi repozytoriami fedory, dostarcza większość programów potrzebnych do codziennego korzystania z systemu. Zainstaluj koniecznie !
 
Rpmfusion, wraz z domyślnymi repozytoriami fedory, dostarcza większość programów potrzebnych do codziennego korzystania z systemu. Zainstaluj koniecznie !
  
*'''[http://get.adobe.com/flashplayer/ adobe]''' — zawiera pakiety Adobe Flash Player, oraz Reader dla systemu Linuks. Można je zainstalować za pomocą polecenia (architektura x86):
+
*'''[http://get.adobe.com/flashplayer/ adobe]''' — zawiera pakiety Adobe Flash Player, oraz Reader dla systemu Linux. Można je zainstalować za pomocą polecenia (architektura x86):
<pre>su -c 'http://linuxdownload.adobe.com/adobe-release/adobe-release-i386-1.0-1.noarch.rpm'</pre>
+
<pre>su -c 'rpm -Uvh http://linuxdownload.adobe.com/adobe-release/adobe-release-i386-1.0-1.noarch.rpm'</pre>
  
 
Instalacja flasha dla architektury x64 jest opisana w [[Poradnik#System_64_bitowy_3|poradniku]]
 
Instalacja flasha dla architektury x64 jest opisana w [[Poradnik#System_64_bitowy_3|poradniku]]
 
*'''[http://www.linux-ati-drivers.homecall.co.uk/ compiz-fusion]''' — repozytorium popularnego programu compiz-fusion, zawierającego wiele ciekawych efektów pulpitu.
 
 
W celu instalacji repozytorium należy wykonać polecenie:
 
<pre>su -c 'rpm -Uvh http://www.linux-ati-drivers.homecall.co.uk/compiz-fusion-release-1-6.noarch.rpm'</pre>
 
  
 
*'''[http://www.google.com/linuxrepositories/testrepo.html google]''' — repozytorium zawierające popularny program [http://picasa.google.com/ picasa]. Picasa 3 znajduje się w repozytorium [google-testing].
 
*'''[http://www.google.com/linuxrepositories/testrepo.html google]''' — repozytorium zawierające popularny program [http://picasa.google.com/ picasa]. Picasa 3 znajduje się w repozytorium [google-testing].
Linia 124: Linia 117:
 
Plik należy skopiować do katalogu ''/etc/yum.repos.d''
 
Plik należy skopiować do katalogu ''/etc/yum.repos.d''
  
*'''[http://apt.kde-redhat.org/apt/kde-redhat/fedora/ kde]''' — zawiera najnowsze wydania środowiska graficznego [http://www.kde.org/ 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.
+
*'''[http://apt.kde-redhat.org/apt/kde-redhat/fedora/ kde]''' — zawiera najnowsze wydania środowiska graficznego [http://www.kde.org/ 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. Wersje rozwojowe środowiska (beta, RC) umieszczane są w [kde-unstable].
  
{{Box/Warn|Uwaga|Środowisko KDE jest dostarczane również z Fedorą. Repozytorium to wyróżnia jedynie czas, w jakim pojawiają się nowe pakiety dla Fedory, zwykle bardzo szybko po oficjalnym wydaniu. Proszę korzystać ostrożnie. Nie należy używać repozytorium [kde-unstable]}}
+
{{Box|Warn|Uwaga|Środowisko KDE jest dostarczane również z Fedorą. Repozytorium to wyróżnia jedynie czas, w jakim pojawiają się nowe pakiety dla Fedory, zwykle bardzo szybko po oficjalnym wydaniu. Proszę korzystać ostrożnie, szczególnie w przypadku [kde-unstable]}}
 +
 
 +
 
 +
'''Tworzenie własnego repozytorium.'''
 +
 
 +
Istnieje możliwość utworzenia własnego repozytorium, zawierającego samodzielnie pobrane paczki rpm. W tym celu należy zainstalować pakiet ''createrepo'':
 +
<pre>[root@X ~]# yum install createrepo</pre>Opcjonalnie można również zainstalować program ''repoview'':<pre>[root@X ~]# yum install repoview</pre>
 +
''Repoview'' stworzy indeks plików naszego repozytorium w formacie html, umożliwiając tym samym przeglądanie ich w przeglądarce.<br \>
 +
Aby stworzyć repozytorium należy wykonać polecenie:
 +
<pre>[user@X ~]# createrepo -d /ścieżka_do_katalogu_z_pakietami</pre>
 +
Opcja '''-d''' powoduje utworzenie bazy danych sqlite, która jest wymagana przez repoview, jeśli nie planujemy jego użycia można ją pominąć. Jeśli chcemy utworzyć indeks wykonamy polecenie:
 +
<pre>[user@X ~]# repoview /ścieżka_do_katalogu_z_pakietami</pre>
 +
W katalogu z pakietami utworzony został podkatalog repoview, w którym wystarczy otworzyć plik ''index.html''.<br \>
 +
Pozostaje jeszcze utworzyć plik z konfiguracją naszego repozytorium i umieścić go w ''/etc/yum.repos.d'', np. ''moje.repo'':
 +
<pre>[moje]
 +
name = moje
 +
baseurl = file:///ścieżka_do_katalogu_z_pakietami/
 +
enabled=1
 +
gpgcheck=0</pre>
 +
Jeśli dodamy paczki rpm należy zaktualizować repozytorium:
 +
<pre>[user@X ~]# createrepo -d --update /ścieżka_do_katalogu_z_pakietami</pre>
 +
Aktualizacji będzie wymagać także indeks repoview, w tym przypadku wystarczy wykonać takie same polecenie jak za pierwszym razem.
  
 
===Obsługa===
 
===Obsługa===
{{Box/Tip|Tip|Szczegółowy opis wszystkich opcji można znaleźć w manualu: '''man yum'''}}
+
{{Box|Tip|Tip|Szczegółowy opis wszystkich opcji można znaleźć w manualu: '''man yum'''}}
  
 
==== Aktualizacja ====
 
==== Aktualizacja ====
Linia 161: Linia 175:
 
----
 
----
  
<onlyinclude>Do instalacji programów służy polecenie:
+
Do instalacji programów służy polecenie:
 
<pre>yum install nazwa_programu1 [nazwa_programu2] [...]</pre>
 
<pre>yum install nazwa_programu1 [nazwa_programu2] [...]</pre>
</onlyinclude>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.
+
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:
 
Jeśli chcemy, aby yum sprawdził zależności samodzielnie ściągniętych programów, zastosujemy opcję '''localinstall''', np:
 
<pre>[root@X ~]# yum localinstall /home/user/rpmbuild/RPMS/i386/qnapi-0.1.6.rc2-1.i386.rpm</pre>
 
<pre>[root@X ~]# yum localinstall /home/user/rpmbuild/RPMS/i386/qnapi-0.1.6.rc2-1.i386.rpm</pre>
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 <onlyinclude>pakiety ściągane z internetu nie posiadają cyfrowego podpisu, dlatego też często stosuje się również opcję '''--nogpgcheck''':
+
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''':
 
<pre>[root@X ~]# cd /home/user/rpmbuild/RPMS/i386
 
<pre>[root@X ~]# cd /home/user/rpmbuild/RPMS/i386
yum localinstall --nogpgcheck qnapi-0.1.6.rc2-1.i386.rpm</pre></onlyinclude>
+
yum localinstall --nogpgcheck qnapi-0.1.6.rc2-1.i386.rpm</pre>
  
 
==== Reinstalacja oprogramowania ====
 
==== Reinstalacja oprogramowania ====
Linia 247: Linia 261:
 
----
 
----
  
<onlyinclude>Jeśli chcemy wyszukać pakiet zawierający określony plik, bądź bibliotekę skorzystamy z opcji:<pre>yum provides nazwa_pliku</pre></onlyinclude>
+
Jeśli chcemy wyszukać pakiet zawierający określony plik, bądź bibliotekę skorzystamy z opcji:<pre>yum provides nazwa_pliku</pre>
 +
Można korzystać również z metaznaków np.<pre>yum provides nazwa_p*</pre>
 
Przykładowo, szukamy pakietów zawierających libasound.so.2:<pre>[root@X ~]# yum provides libasound.so.2
 
Przykładowo, szukamy pakietów zawierających libasound.so.2:<pre>[root@X ~]# yum provides libasound.so.2
 
alsa-lib-1.0.18-6.rc3.fc10.i386 : The Advanced Linux Sound Architecture (ALSA) library
 
alsa-lib-1.0.18-6.rc3.fc10.i386 : The Advanced Linux Sound Architecture (ALSA) library
Linia 365: Linia 380:
 
<pre>yum makecache</pre>
 
<pre>yum makecache</pre>
  
Jeśli wykonujemy wiele zapytań po rząd, to można skorzystać również z shella yuma:
+
==== Powłok programu ====
<pre>yum shell</pre>
+
----
 +
 
 +
Jeśli wykonujemy wiele zapytań pod rząd, to można skorzystać również z shella yuma:
 +
<pre>yum shell</pre> Po wejściu do powłoki wystarczy wpisać {{pre|help}}, by dostać listę dostępnych poleceń.
 +
* '''przykład 1:''' - aktualizacja połączona z usunięciem jednej paczki i instalacją drugiej
 +
<pre>echo -e "update\n remove pidgin\n install kadu\n run\n quit" | yum -y shell</pre>
 +
* '''przykład 2: skrypt''' - tworzymy plik ''skrypt.yum'' (rozszerzenie przykładowe) o zawartości:
 +
<pre>#!/usr/bin/yum shell
 +
 
 +
# Uwaga! to polecenie automatycznie potwierdza wszelkie transakcje
 +
config assumeyes true
 +
 
 +
# wypunktowane transakcje
 +
check-update
 +
reinstall udev
 +
 
 +
# wykonanie skryptu
 +
run</pre>
 +
nadajemy mu prawa do wykonywania {{pre|chmod u+x skrypt.yum}} i możemy uruchomić przez {{pre|./skrypt.yum}}
  
 
===yum-utils===
 
===yum-utils===
Linia 374: Linia 407:
 
====package-cleanup====
 
====package-cleanup====
 
Znajduje niepotrzebne pakiety lub sprawdza problemy z zależnościami
 
Znajduje niepotrzebne pakiety lub sprawdza problemy z zależnościami
* <onlyinclude>Lista dostępnych bibliotek, które nie są wymagane przez inne programy. Gdy stwierdzimy, że nie są potrzebne, możemy je spokojnie usunąć:
+
* Lista dostępnych bibliotek, które nie są wymagane przez inne programy. Gdy stwierdzimy, że nie są potrzebne, możemy je spokojnie usunąć:
<pre>package-cleanup --leaves</pre></onlyinclude>
+
<pre>package-cleanup --leaves</pre>
 
* Możemy pójść krok dalej i wyświetlić wszystkie dostępne paczki, które nie są wymagane przez inne programy:
 
* Możemy pójść krok dalej i wyświetlić wszystkie dostępne paczki, które nie są wymagane przez inne programy:
 
<pre>package-cleanup --leaves --all</pre>
 
<pre>package-cleanup --leaves --all</pre>
 
Po każdorazowym usunięciu jakiejś paczki, należy powyższą czynność powtórzyć, gdyż mogą wyświetlić się kolejne pozycje do usunięcia.
 
Po każdorazowym usunięciu jakiejś paczki, należy powyższą czynność powtórzyć, gdyż mogą wyświetlić się kolejne pozycje do usunięcia.
 +
* Wyjście można formatować za pomocą tych samych parametrów co przy odpytywaniu rpm. <br />
 +
Przykład: sformatowana lista paczek wraz z ich rozmiarem
 +
<pre>package-cleanup -q --leaves --all --qf "%40{name} : %10{size} " | sort -k 3 -g</pre>
 +
:''zobacz też: [[które programy zajmują najwięcej miejsca]]''
 
* Usunięcie starych kerneli (ale tylko te zainstalowane z RPM-a) i pozostawienie dwóch najnowszych:
 
* Usunięcie starych kerneli (ale tylko te zainstalowane z RPM-a) i pozostawienie dwóch najnowszych:
 
<pre>package-cleanup --oldkernels</pre>
 
<pre>package-cleanup --oldkernels</pre>
 
Ilość kerneli określana w pliku yum.conf jest osobnym ustawieniem. Polecenie zostawi 2 nawet jeśli w pliku yum.conf masz ustawione 3.
 
Ilość kerneli określana w pliku yum.conf jest osobnym ustawieniem. Polecenie zostawi 2 nawet jeśli w pliku yum.conf masz ustawione 3.
* <onlyinclude>Informacja o wszystkich problemach z zależnościami w naszym systemie.</onlyinclude> Wyjdą na jaw wszystkie efekty bezmyślnego stosowania opcji —force oraz —nodeps podczas ręcznej instalacji RPM-ów:
+
* 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:
<onlyinclude><pre>package-cleanup --problems</pre></onlyinclude>
+
<pre>package-cleanup --problems</pre>
  
 
====yumdownloader====
 
====yumdownloader====
Linia 402: Linia 439:
  
 
==RPM Package Manager==
 
==RPM Package Manager==
{{Box/Tip|Tip|Szczegółowy opis wszystkich opcji można znaleźć w manualu:''' man rpm'''}}
+
{{Box|Tip|Tip|Szczegółowy opis wszystkich opcji można znaleźć w manualu:''' man rpm'''}}
  
 
[http://pl.wikipedia.org/wiki/RPM RPM] to podstawowe narzędzie do zarządzania pakietami w Fedorze jak i w wielu innych dystrybucjach. Wszystkie inne programy, takie jak [http://pl.wikipedia.org/wiki/Yum 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.
 
[http://pl.wikipedia.org/wiki/RPM RPM] to podstawowe narzędzie do zarządzania pakietami w Fedorze jak i w wielu innych dystrybucjach. Wszystkie inne programy, takie jak [http://pl.wikipedia.org/wiki/Yum 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.
Linia 430: Linia 467:
  
 
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 [http://pl.wikipedia.org/wiki/GDB GDB]. Jeśli nie jesteś programistą i nie zamierzasz poprawiać danego programu, to te paczki są Ci całkowicie niepotrzebne.
 
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 [http://pl.wikipedia.org/wiki/GDB GDB]. Jeśli nie jesteś programistą i nie zamierzasz poprawiać danego programu, to te paczki są Ci całkowicie niepotrzebne.
 +
 +
Podsumowując, używając Fedory ma się styczność z czterema typami pakietów, których zastosowanie i obsługę warunkuje ich nazwa, oraz rozszerzenie:
 +
*'''.rpm''' - pakiet binarny, zawierający programy i biblioteki wykorzystywane w codziennej pracy z Fedorą,
 +
*'''.src.rpm''' - pakiet źródłowy, który wymaga rekompilacji przy użyciu [[Rpmbuild|rpmbuild]],
 +
*'''-devel''' - pakiet zawierający nagłówki niezbędne przy własnoręcznej kompilacji programów,
 +
*'''-debuginfo''' - pakiety instalowane w przypadku chęci uzyskania informacji diagnostycznych.
  
 
=== Instalacja i aktualizacjia ===
 
=== Instalacja i aktualizacjia ===
Linia 460: Linia 503:
 
Tak więc, do instalacji oprogramowania używaj parametru -U, a nie -i. <span style="color: green">Wyjątkiem jest kernel</span>, 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.
 
Tak więc, do instalacji oprogramowania używaj parametru -U, a nie -i. <span style="color: green">Wyjątkiem jest kernel</span>, 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, <onlyinclude>rpm pozwala na instalację wielu programów jednocześnie:
+
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:
<pre>rpm -Uvh xxx.rpm yyy.rpm zzz.rpm</pre></onlyinclude>
+
<pre>rpm -Uvh xxx.rpm yyy.rpm zzz.rpm</pre>
 
Moża również stosować metaznaki:
 
Moża również stosować metaznaki:
 
<pre>rpm -Uvh a*.rpm
 
<pre>rpm -Uvh a*.rpm
Linia 553: Linia 596:
 
kernel-2.6.27.19-170.2.35.fc10.i686</pre>
 
kernel-2.6.27.19-170.2.35.fc10.i686</pre>
  
*'''grep i sort''' - proste <onlyinclude>odfiltrowanie i sortowanie wyników zewnętrznym narzędziem
+
*'''grep i sort''' - proste odfiltrowanie i sortowanie wyników zewnętrznym narzędziem
 
<pre>[user@X ~]# rpm -qa |grep kernel|sort
 
<pre>[user@X ~]# rpm -qa |grep kernel|sort
 
kernel-2.6.27.12-170.2.5.fc10.x86_64
 
kernel-2.6.27.12-170.2.5.fc10.x86_64
Linia 559: Linia 602:
 
kernel-firmware-2.6.27.19-170.2.35.fc10.noarch
 
kernel-firmware-2.6.27.19-170.2.35.fc10.noarch
 
kernel-headers-2.6.27.19-170.2.35.fc10.x86_64
 
kernel-headers-2.6.27.19-170.2.35.fc10.x86_64
kerneloops-0.12-1.fc10.x86_64</pre></onlyinclude>
+
kerneloops-0.12-1.fc10.x86_64</pre>
  
 
*'''-i''' — wyświetla podstawowe informacje o pakiecie:
 
*'''-i''' — wyświetla podstawowe informacje o pakiecie:
Linia 578: Linia 621:
 
/usr/lib/kde4/plasma_applet_stasks.so
 
/usr/lib/kde4/plasma_applet_stasks.so
 
/usr/share/kde4/services/plasma-applet-stasks.desktop</pre>
 
/usr/share/kde4/services/plasma-applet-stasks.desktop</pre>
<onlyinclude>Czasami jedna paczka dostarcza kilka programów, łatwo je znaleźć filtrując (grep) pliki w katalogach ''bin, ''sbin'':
+
Czasami jedna paczka dostarcza kilka programów, łatwo je znaleźć filtrując (grep) pliki w katalogach ''bin, ''sbin'':
 
<pre>[user@X ~]# rpm -ql yum-utils |grep bin
 
<pre>[user@X ~]# rpm -ql yum-utils |grep bin
 
/usr/bin/debuginfo-install
 
/usr/bin/debuginfo-install
Linia 596: Linia 639:
 
/usr/bin/yum-groups-manager
 
/usr/bin/yum-groups-manager
 
/usr/bin/yumdownloader
 
/usr/bin/yumdownloader
/usr/sbin/yum-complete-transaction</pre></onlyinclude>
+
/usr/sbin/yum-complete-transaction</pre>
  
 
*'''--changelog''' — wyświetla informacje o zmianach dla podanego pakietu:
 
*'''--changelog''' — wyświetla informacje o zmianach dla podanego pakietu:
Linia 610: Linia 653:
 
<pre>[user@X ~]# rpm -qf /usr/share/kde4/services/plasma-applet-stasks.desktop
 
<pre>[user@X ~]# rpm -qf /usr/share/kde4/services/plasma-applet-stasks.desktop
 
stasks-0.4-1.fc10.i386</pre>
 
stasks-0.4-1.fc10.i386</pre>
Czasami chcielibyśmy wiedzieć, z której paczki jest dany program/komenda, nie trzeba męczyć się przy użyciu ''locate, find, whereis''. <onlyinclude>Żeby się dowiedzieć skąd jest komenda "mkdir" wystarczy:
+
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:
 
<pre>[user@X ~]# rpm -qf $(which mkdir)
 
<pre>[user@X ~]# rpm -qf $(which mkdir)
coreutils-6.12-20.fc10.x86_64</pre></onlyinclude>
+
coreutils-6.12-20.fc10.x86_64</pre>
O ile nie istnieje alias o tej samej nazwie, wówczas trzeba wyłuskać ścieżkę osobno (which mkdir)
+
O ile nie istnieje alias o tej samej nazwie, wówczas trzeba wyłuskać ścieżkę osobno (which mkdir).<br>
 +
W linuksie możemy iść krok dalej i bawiąc się budowaniem kolejnych zagnieżdżeń wyświetlić np. informacje o paczce.
 +
<pre>[user@X ~]# rpm -qi $(rpm -qf $(which mkdir))</pre>
  
 
*'''--whatrequires''' — zwraca listę programów, które do działania wymagają podanego w zapytaniu pakietu:
 
*'''--whatrequires''' — zwraca listę programów, które do działania wymagają podanego w zapytaniu pakietu:
Linia 638: Linia 683:
 
stasks(x86-32) = 0.4-1.fc10</pre>
 
stasks(x86-32) = 0.4-1.fc10</pre>
  
== Rpmbuild ==
 
  
=== Wstęp ===
 
----
 
  
Zagadnieniem związanym z zarządzaniem pakietami jest obsługa pakietów źródłowych.<br \> 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'''.<br \>
+
{{Anchor|linki}}
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ć.<br \>
+
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.<br />
 
Kompilując program musimy mieć zainstalowany odpowiedni [http://pl.wikipedia.org/wiki/Kompilator kompilator]. W przypadku Fedory jest to [http://pl.wikipedia.org/wiki/Gcc gcc]:
 
<pre>[root@X ~]# yum install gcc gcc-c++</pre>
 
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:
 
#'''./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 <br \>''./configure --prefix=/usr'', który określa, że program ma być zainstalowany w katalogu ''/usr'',
 
#'''make''' - na tym etapie program jest kompilowany i jeśli proces ten zakończy się sukcesem będzie on gotowy do instalacji,
 
#'''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.<br \>
 
Pogramy tworzone dla środowiska [http://www.kde.org/ Kde 4] do kompilacji wykorzystują ''cmake'':
 
<pre>[root@X ~]# yum install cmake</pre>
 
W takim przypadku pierwszy etap kompilacji najczęściej polega na stworzeniu katalogu ''build'' i wykonaniu w nim:
 
#'''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ć:
 
<pre>cmake ../ -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix`</pre>
 
W przypadku programów napisanych w [http://pl.wikipedia.org/wiki/Qt Qt4], nie korzystających jednak z bibliotek Kde 4, np. [http://krzemin.iglu.cz/software/qnapi qnapi], pierwszy etap kompilacji może mieć postać:
 
#'''qmake-qt4 xxx.pro''', gdzie xxx to z reguły nazwa programu. 
 
W takim przypadku, w Fedorze 10, należy najpierw zainstalować pakiet:
 
<pre>[root@X ~]# yum install qt-devel</pre>
 
 
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:<pre>[root@X ~]# yum install rpm-build rpmdevtools</pre>
 
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:<pre>[user@X ~]# rpmdev-setuptree</pre>Powyższe polecenie utworzyło w naszym katalogu domowym katalog ''rpmbuild'', oraz podkatalogi:
 
<pre>
 
rpmbuild
 
  |-BUILD
 
  |-BUILDROOT
 
  |-RPMS
 
  |  |-i386
 
  |  |-noarch
 
  |-SOURCES
 
  |-SPECS
 
  |-SRPMS
 
</pre>
 
 
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ć:
 
<pre>rpmbuild {--rebuild|--recompile} pakiet_źródłowy</pre>
 
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.<br \>
 
 
''Przykład'': pobierzmy pakiet źródłowy programu unzip:
 
<pre>wget http://download.fedora.redhat.com/pub/fedora/\
 
linux/releases/10/Fedora/source/SRPMS/unzip-5.52-9.fc9.src.rpm</pre>
 
Nie pozostaje już nic innego, jak zbudować paczkę rpm:
 
<pre>[user@X ~]# rpmbuild --rebuild unzip-5.52-9.fc9.src.rpm</pre>
 
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:
 
<pre>[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
 
[...]
 
</pre>
 
Jak widać pakiet został zbudowany na maszynie x86 i w związku z tym umieszczono go w podkatalogu ''i386''.<br \> 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 <u>muszą</u> znajdować się w katalogu SOURCES.<br \>
 
 
Składnia polecenia ma postać:
 
<pre>rpmbuild {-ba|-bb|-bp|-bc|-bi|-bl|-bs} PLIK_SPEC</pre>
 
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.<br \>
 
Jeśli chcemy edytować plik spec posiadanego pakietu źródłowego musimy go wcześniej zainstalować:
 
<pre>[user@X ~]# rpm -ivh xxx.src.rpm</pre>
 
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.<br \>
 
 
''Przykład'': Zainstalujmy pobrany wcześniej pakiet źródłowy programu unzip:
 
<pre>[user@X ~]# rpm -ivh unzip-5.52-9.fc9.src.rpm</pre>
 
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:
 
<pre>[user@X ~]# cd /home/user/rpmbuild/SPECS
 
[user@X ~]# rpmbuild -ba unzip.spec</pre>
 
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.<br \>
 
Składnia polecenia ma postać:     
 
<pre>rpmbuild {-ta|-tb|-tp|-tc|-ti|-tl|-ts} TARBALL</pre>
 
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 itp.
 
 
=== Podstawowy opis plików spec ===
 
----
 
{{Box/Tip|Info| Przedstawione w tym rozdziale informacje należy traktować jako krótkie wprowadzenie do budowy plików spec. Więcej informacji np. [http://www.rpm.org/max-rpm/ max-rpm], [http://genetikayos.com/code/repos/rpm-tutorial/trunk/rpm-tutorial.html rpm-tutorial] }}
 
 
Przyjrzyjmy się szkieletowi pliku '''spec''', w którym umieszczone są wszystkie informacje potrzebne do budowy pakietu rpm.
 
<pre>[user@X ~]# rpmdev-newspec nowy.spec</pre>
 
Utworzony został plik ''nowy.spec'' zawierający:
 
<pre>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></pre>
 
 
'''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ę <u>wszystkich</u> 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:
 
<pre>%changelog
 
* Sat Mar 21 2009 Imię Nazwisko <adres@email>
 
- Updated to 0.5 </pre>
 
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.<br \>
 
 
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:
 
<pre>[user@X ~]# rpm --showrc</pre>
 
 
 
''Przykładowe makra''
 
----
 
 
*'''%{name}''' - makro korzystające z nazwy programu umieszczonej w sekcji ''Name'',
 
*'''%{version}''' - wersja programu zamieszczona w sekcji ''Version'',<br \>
 
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''
 
 
 
== Inne źródła pomocy, polecane strony ==
 
== Inne źródła pomocy, polecane strony ==
 
==== yum ====
 
==== yum ====
Linia 883: Linia 705:
 
[http://www.rpm.org/wiki/Docs Wiki rpm.org] (en) <br>
 
[http://www.rpm.org/wiki/Docs Wiki rpm.org] (en) <br>
 
[http://rpm.org/max-rpm-snapshot Maximum RPM] (en) <br>
 
[http://rpm.org/max-rpm-snapshot Maximum RPM] (en) <br>
 +
[http://www.ibm.com/developerworks/views/linux/libraryview.jsp?sort_by=&show_abstract=true&show_all=&search_flag=&topic_by=-1&type_by=Articles&search_by=rpm+part&Go.x=0&Go.y=0 Packaging software with RPM (ibm.com)] (en) <br>
  
 
+
[[Kategoria:Administracja systemem]]
[[Kategoria:Artykuły]][[Kategoria:Administracja systemem]]
+

Aktualna wersja na dzień 06:28, 10 maj 2011

(alias: rpm | yum)

Spis treści

[edytuj]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.

[edytuj]Yumex

Początkującym na pewno ł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 korzystać 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 instalować oprogramowania w dwóch terminalach na raz.

[edytuj]Konfiguracja

Tip.png
Tip
Szczegółowy opis wszystkich opcji można znaleźć w manualu: man yum.conf

[edytuj] 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.

[edytuj] 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 rozważ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).

[edytuj] 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. Nie znajdują się w nich min. kodeki audio-wideo objęte ochroną patentową (głównie w USA), oraz binarne sterowniki 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 Linux. Można je zainstalować za pomocą polecenia (architektura x86):
su -c 'rpm -Uvh http://linuxdownload.adobe.com/adobe-release/adobe-release-i386-1.0-1.noarch.rpm'

Instalacja flasha dla architektury x64 jest opisana w poradniku

  • 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. Wersje rozwojowe środowiska (beta, RC) umieszczane są w [kde-unstable].
Warn.png
Uwaga
Środowisko KDE jest dostarczane również z Fedorą. Repozytorium to wyróżnia jedynie czas, w jakim pojawiają się nowe pakiety dla Fedory, zwykle bardzo szybko po oficjalnym wydaniu. Proszę korzystać ostrożnie, szczególnie w przypadku [kde-unstable]


Tworzenie własnego repozytorium.

Istnieje możliwość utworzenia własnego repozytorium, zawierającego samodzielnie pobrane paczki rpm. W tym celu należy zainstalować pakiet createrepo:

[root@X ~]# yum install createrepo
Opcjonalnie można również zainstalować program repoview:
[root@X ~]# yum install repoview

Repoview stworzy indeks plików naszego repozytorium w formacie html, umożliwiając tym samym przeglądanie ich w przeglądarce.
Aby stworzyć repozytorium należy wykonać polecenie:

[user@X ~]# createrepo -d /ścieżka_do_katalogu_z_pakietami

Opcja -d powoduje utworzenie bazy danych sqlite, która jest wymagana przez repoview, jeśli nie planujemy jego użycia można ją pominąć. Jeśli chcemy utworzyć indeks wykonamy polecenie:

[user@X ~]# repoview /ścieżka_do_katalogu_z_pakietami

W katalogu z pakietami utworzony został podkatalog repoview, w którym wystarczy otworzyć plik index.html.
Pozostaje jeszcze utworzyć plik z konfiguracją naszego repozytorium i umieścić go w /etc/yum.repos.d, np. moje.repo:

[moje]
name = moje
baseurl = file:///ścieżka_do_katalogu_z_pakietami/
enabled=1
gpgcheck=0

Jeśli dodamy paczki rpm należy zaktualizować repozytorium:

[user@X ~]# createrepo -d --update /ścieżka_do_katalogu_z_pakietami

Aktualizacji będzie wymagać także indeks repoview, w tym przypadku wystarczy wykonać takie same polecenie jak za pierwszym razem.

[edytuj]Obsługa

Tip.png
Tip
Szczegółowy opis wszystkich opcji można znaleźć w manualu: man yum

[edytuj] 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.

[edytuj] 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

[edytuj] 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.

[edytuj] 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.

[edytuj] 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.

[edytuj] 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


[edytuj] 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
Można korzystać również z metaznaków np.
yum provides nazwa_p*
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.

[edytuj] 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


[edytuj] 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.

[edytuj] 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).

[edytuj] 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

[edytuj] Powłok programu


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

yum shell
Po wejściu do powłoki wystarczy wpisać help, by dostać listę dostępnych poleceń.
  • przykład 1: - aktualizacja połączona z usunięciem jednej paczki i instalacją drugiej
echo -e "update\n remove pidgin\n install kadu\n run\n quit" | yum -y shell
  • przykład 2: skrypt - tworzymy plik skrypt.yum (rozszerzenie przykładowe) o zawartości:
#!/usr/bin/yum shell

# Uwaga! to polecenie automatycznie potwierdza wszelkie transakcje
config assumeyes true
  
# wypunktowane transakcje
check-update
reinstall udev

# wykonanie skryptu
run

nadajemy mu prawa do wykonywania chmod u+x skrypt.yum i możemy uruchomić przez ./skrypt.yum

[edytuj]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:

[edytuj]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.

  • Wyjście można formatować za pomocą tych samych parametrów co przy odpytywaniu rpm.

Przykład: sformatowana lista paczek wraz z ich rozmiarem

package-cleanup -q --leaves --all --qf "%40{name} : %10{size} " | sort -k 3 -g
zobacz też: które programy zajmują najwięcej miejsca
  • 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

[edytuj]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

[edytuj]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.

[edytuj]inne

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

[edytuj]RPM Package Manager

Tip.png
Tip
Szczegółowy opis wszystkich opcji można znaleźć w manualu: man rpm

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.

[edytuj] 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.

Podsumowując, używając Fedory ma się styczność z czterema typami pakietów, których zastosowanie i obsługę warunkuje ich nazwa, oraz rozszerzenie:

  • .rpm - pakiet binarny, zawierający programy i biblioteki wykorzystywane w codziennej pracy z Fedorą,
  • .src.rpm - pakiet źródłowy, który wymaga rekompilacji przy użyciu rpmbuild,
  • -devel - pakiet zawierający nagłówki niezbędne przy własnoręcznej kompilacji programów,
  • -debuginfo - pakiety instalowane w przypadku chęci uzyskania informacji diagnostycznych.

[edytuj] 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

[edytuj] 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


[edytuj] 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).
W linuksie możemy iść krok dalej i bawiąc się budowaniem kolejnych zagnieżdżeń wyświetlić np. informacje o paczce.

[user@X ~]# rpm -qi $(rpm -qf $(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


[edytuj] Inne źródła pomocy, polecane strony

[edytuj] yum

Software Management with Yum (fedoraproject) (en)

[edytuj] wyszukiwarki rpm

Uwaga! stosuj tylko wtedy, gdy pakietu nie ma w repozytoriach fedory.
http://rpm.pbone.net
http://rpmfind.net
http://rpmseek.com

[edytuj] budowa i zarządzanie rpm

Kurs budowania pakietow rpm (Hoppke Repo) mirror
Możliwa droga do zostania szeregowym developerem PLD (uwaga konkurencja, nie brać wszystkiego na serio)
RMP Guid (fedoraproject) (en)
How to create an RPM package (fedoraproject) (en)
Wiki rpm.org (en)
Maximum RPM (en)
Packaging software with RPM (ibm.com) (en)

Osobiste
Przestrzenie nazw

Warianty
Działania
Wiki
Nawigacja
Inne
Narzędzia