Wprawdzie Arch, przynajmniej w swojej stabilnej odsłonie, winien umożliwić uruchomienie każdego programu udostępnianego w tej dystrybucji. Niemniej jednak, z różnych powodów może się zdarzyć, że zmuszeni jesteśmy stosować jakieś programy z repozytorium [testing], czy z AUR, w tym także programy budowane w wersjach rozwojowych. Zdarzyć się może (i zdarza), że wczoraj jeszcze działający program dzisiaj już nie uruchomi się. Często wygląda to w taki sposób, że inicjując go z menu widzimy jak program "startuje", ale zamiast się otworzyć tego nie robi. Niektóre programy wprawdzie wystartują, ale ukażą nam błąd. Chwalmy tych, którzy umożliwili takim programom pokazanie nam, na czym ów błąd polega. W pierwszej kolejności, w takim przypadku, próbujemy uruchomić program w konsoli. Często zobaczymy tam, komunikat w rodzaju (w przykładach posługuję się fikcyjną biblioteką foo.so):
(...) /usr/lib/foo.so.1 don't existJeśli zobaczymy, że jest to jakiś plik, którego rozszerzenie to so, so.CYFRA, to chodzi o to, że program, który uruchamiamy - jeśli wcześniej się uruchamiał - nie jest przeznaczony do działania z wersją biblioteki, jaką mamy aktualnie w systemie. Jeśli w konsoli nie uzyskamy informacji o miejscu położenia biblioteki, to w pierwszej kolejności lokalizujemy ją. Skorzystamy z polecenia locate (jeśli ktoś w systemie nie ma, to można zainstalować paczkę mlocate, bądź posłużyć się jakimkolwiek innym programem przeszukującym dysk za plikami).
locate foo.so.1W ten sposób uzyskamy lokalizację tej biblioteki. Teraz korzystamy z pacmana:
pacman -Qo /usr/lib/foo.so.1W wyniku uzyskamy informację do jakiej paczki należy /usr/lib/foo.so.1. Powiedzmy, że jest to paczka foo w wersji 1.2.3.
Przydałoby się dowiedzieć jaką wersję tej paczki oferuje Arch w repozytorium stabilnym i pozostałych. Znów skorzystamy z pacmana bądź yaourta:
pacman -Ss foolub
yaourt fooPowinno nas to naprowadzić na to, skąd mamy zainstalowaną paczkę. Możemy jeszcze sprawdzić informacje o tym czyją jest zależnością, czy też w jaki sposób została ona zainstalowana:
pacman -Qi fooMożemy przeglądnąć również dziennik logów pacmana, by dowiedzieć się kiedy, przy jakiej okazji tę paczkę zainstalowaliśmy. Znajduje się on w pliku /var/log/pacman.log. Jest to plik tekstowy, zatem przeglądać można go w dowolny sposób. W AUR znajduje się jednak wygodna przeglądarka tego pliku o nazwie pacmanviewer.
Wyposażeni w taką wiedzę powinniśmy teraz zadecydować, czy:
- cofnąć paczkę do działającej wersji (ale uwaga, wówczas inny program, który ściągnął właśnie tę bibliotekę w obecnej wersji może przestać działać),
- spróbować skompilować niedziałający program w oparciu o nową bibliotekę,
- (tak są jeszcze inne rozwiązania, ale na tyle ryzykowne i niepolecane, że nie będę o nich pisać; część z nas je zna, jeśli zna, to te rozwiązania są wyłącznie do nich adresowane, albowiem trzeba być bardzo mocno świadomym, co robimy i dlaczego; w związku z tym nie będę ich tu polecać).
Pierwsze dokonujemy - najwygodniej - narzędziem downgrade (jest w AUR). W drugim przypadku polecam następujące działanie:
yaourt -G foo && cd fooŚciągnęliśmy "przepisy" umożliwiające budowę paczki i przeszliśmy do katalogu, w którym się one znajdują.
Teraz trzeba przeglądnąć PKGBUILD, albowiem, być może będzie on wymagać właśnie określonej wersji biblioteki. Jeśli tak jest możemy spróbować z wersjami rozwojowymi (git, svn, bzr itp.), albo udać się na stronę programu, gdzie być może uzyskamy jakieś informacje. Po ewentualnym dostosowaniu PKGBUILDu wydajemy polecenie:
makepkg -si
To oczywiście pewien schemat działania. Nie zawsze pomoże. Nie jest nawet w 100% polecany (albowiem niekiedy programy są przeznaczone do pracy z określonymi wyłącznie bibliotekami). Jeśli się powiodło - fajnie. Jeśli nie - trzeba szukać jakiegoś innego rozwiązania.
