Zarządzanie pakietami

Z Fedora Wiki
Skocz do: nawigacji, wyszukiwania

(alias: rpm | yum)

Spis treści

Yum

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

Yumex

Początkującym 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.

Konfiguracja

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

yum.conf


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

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

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

Opis opcji

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

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

yum.repos.d


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

Przetwarzane są tylko pliki z rozszerzeniem .repo. W każdym takim pliku może znajdować się opis jednego lub większej ilości repozytoriów. Rozpatrzmy dalsze 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).

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.

Obsługa

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

Aktualizacja


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

Aktualizacja systemu

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

yum update

Dostępne aktualizacje

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

yum check-update

Aktualizacja poszczególnych programów

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

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

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

yum update hexedit kde\*

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

Opcja --skip-broken

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

yum update --skip-broken

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

Instalacja oprogramowania


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

yum install nazwa_programu1 [nazwa_programu2] [...]

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


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

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

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

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

Reinstalacja oprogramowania


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

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

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

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

Usuwanie zainstalowanych programów


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

yum remove nazwa_programu1 [nazwa_programu2] [...]

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

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

Lista dostępnych programów


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

yum list

lub

yum list all

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

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

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

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

 yum list extras

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

Wyszukiwanie programów po opisie


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

yum search ciąg_znaków

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

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

yum search burn


Wyszukiwanie paczek zawierających określone pliki


Jeśli chcemy wyszukać pakiet zawierający określony plik, bądź bibliotekę skorzystamy z opcji:
yum provides nazwa_pliku
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.

Uzyskiwanie opisu danego programu


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

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


Operacje na grupach programów


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

yum grouplist

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

yum grouplist

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

yum grouplist hidden

yum groupinfo

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

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

yum groupinstall

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

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

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

yum groupinstall "MySQL Database" "PostgreSQL Database"

yum groupremove

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

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

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

yum groupupdate

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

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

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

Usuwanie plików tymczasowych


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

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

yum clean packages

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

yum clean headers

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

yum clean all

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

Opcje wywołania programu


Składnia:

yum [opcje] polecenie nazwa_paczki...

Spis ważniejszcych opcji:

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

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

yum-utils


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

package-cleanup

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

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

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

  • 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

yumdownloader

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

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

Możliwe opcje to:

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

yum-complete-transaction

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

inne

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

RPM Package Manager

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.

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.

Instalacja i aktualizacjia



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

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


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

rpm -U xxx.rpm

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

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


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

rpm -Uvh xxx.rpm

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

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

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

Moża również stosować metaznaki:

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


Wybrane opcje instalacji


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

Deinstalacja



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

rpm -e nazwa_pakietu

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

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

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

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


Wybrane opcje deinstalacji



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


Zapytania



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


Podstawowe zapytanie ma postać:

rpm -q [opcje_wyboru] [opcje_zapytania]

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

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


Wybrane opcje



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

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

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

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

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

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

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

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

O ile nie istnieje alias o tej samej nazwie, wówczas trzeba wyłuskać ścieżkę osobno (which mkdir).
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


Inne źródła pomocy, polecane strony

yum

Software Management with Yum (fedoraproject) (en)

wyszukiwarki rpm

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

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