Właściwie, jako użytkownik PLD, mógłbyś żyć w nieświadomości i nie przejmować się tym, że istnieje coś innego, poza poldkiem, co obsługuje pakiety. Jednak wiedza o tym, że istnieje RPM a poldek jest dla niego zaawansowaną nakładką jeszcze nikomu nie zaszkodziła.
Poniższy przewodnik nie opisuje wszystkich możliwości menadżera pakietów RPM. Ma on pokazać, jak w praktyce można nim się posługiwać. Niektóre sztuczki i kruczki mogą się wam przydać chociażby do skryptów powłoki.
Wszystkie polecenia, wymienione w tym punkcie, nie wymagają uprawnień super-użytkownika (roota).
rpm -qa
Wypisuje całą listę pakietów zainstalowaną na Twoim komputerze.
Niech cię piekło pochłonie, jeśli na forum, albo którejś liście dyskusyjnej PLD, wkleisz całą zawartość tego polecenia :) Najczęściej wspomniane polecenie występuje w duecie z grepem:
rpm -qa | grep coś
lub:
rpm -qa | grep -i coś
lub jeszcze lepiej:
rpm -qa | grep -i coś | sort
Przydają się one głównie wtedy, gdy chcemy podzielić się z innymi szczegółową informacją o naszym systemie.
Grep, wywołany bez żadnych parametrów, wyszuka w tym co dostanie na wejściu wskazaną frazę “coś”, np.:
[dirdival@pld ~]$ rpm -qa | grep geany geany-plugin-classbuilder-0.18-1.i686 geany-plugin-spellcheck-0.4-1.i686 geany-plugin-htmlchars-0.18-1.i686 geany-plugin-splitwindow-0.18-1.i686 geany-plugin-gdb-0.0.2-1.i686 geany-plugin-saveactions-0.18-1.i686 geany-0.18-1.i686 geany-plugin-latex-0.4-1.i686 geany-plugin-export-0.18-1.i686 geany-devel-0.18-1.i686 geany-plugin-filebrowser-0.18-1.i686
W tym konkretnym przypadku grep na wejściu otrzymuje listę wszystkich pakietów. Przegląda ją linia po linii i wyszukuje w nich ciągu znaków “geany”. Jeśli je znajdzie wypisze na ekran. W taki oto sposób, podzieliliśmy się ze światem informacją, o zainstalowanym na naszym systemie programie geany, wraz z jego wtyczkami.
Opcja (-i), za dokumentacją, ignoruje rozróżnienia w wielkości liter. Czasami bywa to przydatne, niektóre pakiety zawierają w swoich nazwach wielkie litery.
Ostatni przykład to właściwie trio a nie tandem. Wspólnie ze sobą grają: rpm, grep oraz sort. Ostatni z nich zapewnia, że wynik zostanie wypisany w kolejności leksykograficznej:
[dirdival@pld ~]$ rpm -qa | grep -i geany | sort geany-0.18-1.i686 geany-devel-0.18-1.i686 geany-plugin-classbuilder-0.18-1.i686 geany-plugin-export-0.18-1.i686 geany-plugin-filebrowser-0.18-1.i686 geany-plugin-gdb-0.0.2-1.i686 geany-plugin-htmlchars-0.18-1.i686 geany-plugin-latex-0.4-1.i686 geany-plugin-saveactions-0.18-1.i686 geany-plugin-spellcheck-0.4-1.i686 geany-plugin-splitwindow-0.18-1.i686
Czyż tak wypisana lista nie prezentuje się czytelniej? Od razu widać grupy pakietów.
Czas na prawdziwą bombę: współpraca duetu i kwartetu :)
$ rpm -qa | wc -l $ rpm -qa | sort | uniq | wc -l
Zanim odpowiem na pytanie, co właściwie się tu dzieje, kilka słów o uniq i wc. Polecenie uniq z posortowanej (ważne: posortowanej) listy usuwa duplikaty. Wc to … nie jest to o czym myślicie :) Wc w tym przypadku jest skrótem od “word count”. Wywołane z opcją (-l) po prostu liczy liczbę linii, którą dostanie na wejściu i wypisuje ją jako wynik.
Wracając do meritum. Jeśli liczby, zwrócone przez powyższe polecenia, różnią się to mamy kłopot. W naszym systemie jest pakiet, który został zainstalowany co najmniej dwukrotnie. Co gorsza, nie uda Ci się go usunąć za pomocą poldka! O tym jak pozbyć się zdublowanych pakietów przeczytasz w punkcie “opcje instalacji i usuwania”.
Drugim, znacznie łatwiejszym, sposobem znalezienia zduplikowanych pakietów jest wywołanie polecenia:
$ rpm -qa | sort | uniq -d
Jeśli mamy problem z bazą rpm, w wyniku powinniśmy otrzymać listę kłopotliwych pakietów.
Dla rozluźnienia sytuacji, będą teraz proste i przyjemne polecenia:
$ rpm -qf ścieżka
a właściwie:
$ rpm -qf `which nazwa_programu`
Zwracam uwagę, że:
Samo which zwraca pełną ścieżkę do programu.
Przykład:
[dirdival@pld ~]$ rpm -qf `which pdflatex` texlive-format-pdflatex-20080816-8.i686
Reasumując, w ten oto sposób możemy dowiedzieć się do której paczki należy dany plik. Przydatne, zwłaszcza gdy nie znamy programu, nie ma do niego mana a chcemy się czegoś więcej o nim dowiedzieć. Doskonale współpracuje z kolejnym poleceniem:
$ rpm -qi nazwa_pakietu
Wypisuje ono opis zainstalowanego pakietu. Już nie musimy wchodzić do poldka, wszystko mamy jak na dłoni.
Przykład:
[dirdival@pld ~]$ rpm -qi texlive-format-pdflatex-20080816-8.i686
Bądź jako kombos:
[dirdival@pld ~]$ rpm -qf `which pdflatex` | xargs rpm -qi
Opis xargs znajdziecie w manie, żeby nie było za prosto :)
Warto jeszcze wspomnieć o możliwości wypisania wszystkich nazw zainstalowanych pakietów, bez ich numerów wersji. Poniżej znajdziecie dwie najbardziej przydatne komendy tego typu.
Każda nazwa pakietu w nowej linii:
$ rpm -qa --qf "%{NAME}\n" | sort
Wszystkie pakiety w jednej linii oddzielone spacją:
$ rpm -qa --qf "%{NAME} "
W zasadzie powinieneś unikać instalacji oraz usuwania pakietów bezpośrednio z RPM. Poldek doskonale sobie z tym radzi a przy tym dba o wszystkie zależności. Dlatego wszystkich poleceń wymienionych w tym punkcie używaj z rozwagą, nie bez powodu wymagają one uprawnień super-użytkownika.
Instalacja pakietu wygląda następująco:
# rpm -hiv nazwa_pakietu
wersja dla zdesperowanych, lubiących kłopoty to:
# rpm -hiv --nodeps nazwa_pakietu
Znaczenie poszczególnych opcji:
Pierwsze polecenie (rpm -hiv) zainstaluje wskazany pakiet. Właściwie powinienem napisać spróbuje zainstalować. Jeśli w naszym systemie znajdują się wszystkie programy, z których zamierza korzystać dany pakiet, instalacja powinna się powieść. W przeciwnym wypadku zostaniemy poinformowani o problemach.
Drugi przykład zainstaluje paczkę bez spełnionych zależności. Można zadać pytanie, właściwie po co? Przecież programy w niej zawarte nie będą działały poprawnie. Czasami jednak nie chodzi nam o same programy, ale o dane: grafikę, dźwięk, bądź inne pliki.
Czas na opcje usuwania:
# rpm -e -v nazwa_pakietu
i analogicznie do instalacji:
# rpm -e -v --nodeps nazwa_pakietu
Opcja -e oznacza usuwanie, od słowa “erase”. Znaczenie pozostalych parametrów jest identyczne jak przy instalacji. rpm -e -v usunie wskazany pakiet o ile nie istnieją takie paczki, które chcą z niego korzystać. Opcja –nodeps zapewnia, że zostanie on skasowany bez szemrania.
Przykład uzasadnionego zastosowania instalacji i usuwania pakietów bezpośrednio z RPM, znajdziecie w przewodniku przywracanie poprzedniej wersji pakietu.
Na deser zostawiłem usuwanie zdublowanych pakietów. Jeśli narozrabiasz w systemie i zainstalujesz przypadkowo kilkukrotnie ten sam pakiet, będziesz miał problemy. Poldek nie dopuszcza do takich rzeczy, ale bawiąc się RPM-em możesz przypadkowo zrobić sobie kuku. Próba standardowego usunięcia nic nie da:
[root@pld ~]# rpm -e -v --nodeps gnome-disk-utility-libs-2.28.1-1 błąd: "gnome-disk-utility-libs-2.28.1-1" określa wiele pakietów [root@pld ~]# rpm -qi gnome-disk-utility-libs Name : gnome-disk-utility-libs Relocations: (not relocatable) Version : 2.28.1 Vendor: (none) Release : 1 Build Date: wto, 3 lis 2009, 09:44:04 Install Date: czw, 5 lis 2009, 17:30:41 Build Host: nereid-builder ... Name : gnome-disk-utility-libs Relocations: (not relocatable) Version : 2.28.1 Vendor: (none) Release : 1 Build Date: czw, 5 lis 2009, 18:12:55 Install Date: czw, 5 lis 2009, 18:17:20 Build Host: pld
Sprawę rozwiąrze użycie opcji –allmatches:
[root@pld ~]# rpm -e -v --allmatches --nodeps gnome-disk-utility-libs-2.28.1-1 Zapisano: /var/spool/repackage/1257691850/gnome-disk-utility-libs-2.28.1-1.i686.rpm Zapisano: /var/spool/repackage/1257691850/gnome-disk-utility-libs-2.28.1-1.i686.rpm
Jeśli jesteś zainteresowany, dlaczego RPM napisał, że zapisano dane pakiety a nie je usunięto, przeczytaj wspomniany już przewodnik przywracanie poprzedniej wersji pakietu.
Od czasu do czasu warto uruchomić weryfikację pakietów w naszym systemie. Najprostsza i najczęściej stosowana postać jej wywołania to:
rpm -Va
Powyższe polecenie, najprościej rzecz ujmując, porówna informacje z bazy rpm z rzeczywistością. Jako wynik wypisze różnice, w idealnym przypadku nie zobaczymy nic (może trochę przesadziłem, oznaczałoby to, że administrator nie skonfigurował systemu). A więc powinniśmy chociażby ujrzeć listę wszystkich plików konfiguracyjnych, z katalogu /etc, których zawartość modyfikowaliśmy. Pozwala to upewnić się, jakie pliki powinniśmy mieć na pewno w swojej kopii bezpieczeństwa.
Jeśli w wyniku zobaczymy informację o brakujących plikach, powinniśmy uważnie się im przyjrzeć. Nie musi od razu oznaczać to coś złego, ale w szczególnych przypadkach, może świadczyć o kłopotach chociażby z systemem plików. Warto “namierzyć” pakiet z którego pochodzą, na przykład opisanym wcześniej poleceniem rpm -qf i zastanowić się, czy nie należy ponownie zainstalować wybrakowaną paczkę.
Powyższy temat został również opisamy w oficjalnej dokumentacji w “Kontrola integralności systemu”