Korzystając z systemów Arch-like - a więc także Manjaro, możemy korzystać ze zbiorów Arch Users Repository.
ArchLinux User Community Repository (AUR) - po polsku oznacza repozytorium społeczności użytkowników Arch Linuksa. Jest zbiorem PKGBUILDów pisanych przez użytkowników Arch Linuksa. Mówiąc prostym językiem, AUR to pakiety, których nie dołączono jeszcze do oficjalnego repozytorium [community], a do tego kandydują. Użytkownicy głosują na poszczególne pakiety, które po osiągnięciu pozytywnej opinii społeczności trafiają do zbioru pakietów oficjalnych.
Tyle na temat AUR mówi polskojęzyczna Wiki. Żeby korzystać z dobrodziejstw AUR powinniśmy zainstalować:
pacman -S base-devel To bardzo istotne, gdyż bez tego skompilowanie czegokolwiek będzie niemożliwe.
Przejdźmy zatem do meritum. Jak pobierać? Jest kilka wyjść. Użytkownicy Arch Linux z pewnością poradzą sobie z zainstalowaniem nakładek na pacmana obsługujących AUR - natomiast użytkownicy Manjaro mają prawo tego nie wiedzieć. To proste. Yaourt w Manjaro jest OOTB, packer musimy zainstalować samodzielnie:
pacman -S packerObsługa tych programów jest bardzo podobna jak pacmana - sprowadza się do wydania poleceń:
packer -S nazwa_programuyaourt -S nazwa_programuNadto w Manjaro oferowane są nakładki graficzne na pacmana i yaourt, które umożliwiają instalację wprost z AUR. W zależności od wersji Manjaro, domyślnie instalowane są pamac (we wszystkich wersjach zbudowanych w oparciu o Gtk+) oraz octopi (w wersjach zbudowanych z użyciem Qt). Tutaj wystarczy wyszukać i wskazać aplikację do instalacji z AUR.
W teorii wszystko powinno działać - w praktyce możemy napotkać się na przeróżne problemy takie jak błędna suma kontrolna, nieaktualny adres ze źródłami programu, brak zależności, bądź zbyt mało miejsca w tempfs. Dlatego powinniśmy poznać stare, sprawdzone, ręczne metody kompilowania - tutaj w praktyce wszystko powinno pójść bez problemu (choć rzecz jasna, mogą wystąpić).
Schemat działania jest bardzo prosty:
wget https://aur.archlinux.org/packages/nazwa_pakietu/nazwa_pakietu.tar.gz
tar zxvf nazwa_pakietu.tar.gz
cd nazwa_pakietu
makepkg -sircTak więc pokrótce opiszę działanie każdego z wymienionego przeze mnie parametru makepkg
s - odpowiada za pobranie zależności potrzebnych do zbudowania pakietu
i - instaluje zbudowany pakiet
r - usuwa zbędne zależności (tak zwane makedepends)
c - usuwa katalogi
src oraz
pkg powstałe podczas kompilowania
Nieco wyżej padło pojęcie
makedepends. Co to takiego? To zależności potrzebne do zbudowania paczki, niewymagane do prawidłowego działania programu, zatem zwykle po skompilowaniu możemy je usunąć.
Pora przejść do klasycznych problemów, jakie może napotkać młody adept szlachetnej sztuki kompilowania.
1. Błędne sumy kontrolneKomunikat o błędnych sumach może mieć różne podłoże. Suma kontrola może nie być wygenerowana prawidłowo, sumy kontrolne różnią się wielkością z polem źródła. Mamy dwie możliwości.
I. Bardzo łatwa
Nie musimy bawić się w edycję. Wydajemy polecenie
updpkgsumsktóre aktualizuje sumy kontrolne. To wszystko
II. Trudniejsza
Edytujemy PKGBUILD i podmieniamy sumy kontrolne wygenerowane poleceniem:
makepkg -g2. Nieaktualny/niedziałający adres źródeł/żródłaZdarzy się, że serwer na którym umieszczone są źródła, odmówi posłuszeństwa. Wtedy zostaje nam albo poczekać albo zmienić na inny, alternatywny - o ile taki istnieje. Za przykład posłuży BFQ - strona, na której znajdują się źródła często odmawia posłuszeństwa. Możemy zrobić to na dwa sposoby. Potrzebujemy dowolnego tarballa kernela korzystającego z
I. Mniej czasochłonny
Wpisujemy w konsolę
sed -i 's|^_bfqpath=.*$|_bfqpath=\"https://pf.natalenko.name/mirrors/bfq/3.16.0-v7r5/[url=http://repo-ck.com/source/mirror][/url]\"|' PKGBUILDII. Bardziej czasochłonny:
Musimy edytować PKGBUILD, odszukać w nim odpowiednią linijkę:
_bfqpath="http://algo.ing.unimo.it/people/paolo/disk_sched/patches/3.16.0-v7r5"Musimy zakomentować stary wpis:
#_bfqpath="http://algo.ing.unimo.it/people/paolo/disk_sched/patches/3.16.0-v7r5"Tuż pod nim/nad nim dodajemy nowy:
_bfqpath="https://pf.natalenko.name/mirrors/bfq/3.16.0-v7r5/"Dzięki czemu potrzebne nam źródła zostaną pobrane. Oczywiście, to tylko przykład - za każdym razem adres będzie inny i trzeba będzie to uwzględniać. Samo "_bfq" przed "patch" zostało dodane przez autora PKGBUILDu. Równie dobrze może być ona nazwana w dowolny inny sposób. Z reguły szukamy linijki z "path" w nazwie i tej, na której budowa paczki napotkała problem ze znalezieniem pliku ze źródłami.
3. Brak zależności niezbędnych do zbudowania paczki. Tutaj problem jest poważniejszy, gdyż trzeba dokładnie ustalić, jak nazywa się brakująca zależność. Czasem jest to podane wprost, czasem musimy chwilę się nad tym zastanowić. Najprościej jest użyć do tego Google - po chwili szukania z pewnością znajdziemy odpowiedź na nurtujące nas pytanie.
Przykładowo, jeśli przy kompilowaniu
mdm-display-manager dojdziemy do wniosku, że brakuje paczki
libwebkit, powinniśmy ją umieścić wśród zależności:
depends=('pam' 'libdmx' 'gtk2' 'libgnomecanvas' 'librsvg'
'libxml2' 'libart-lgpl' 'dbus-glib' 'libwebkit')
Dzięki temu kompilowanie powinno ruszyć i po chwili powinniśmy cieszyć się działającym programem. Niemniej, musimy pamiętać, że może się zdarzyć wyjątek od tej reguły. Mianowicie, budowany program może wymagać biblioteki, która w repozytoriach już nie występuje lub jest wymagana starsza wersja biblioteki. W tej sytuacji pomóc może cofnięcie paczki dzięki ARM (Arch Rollback Machine) - paczki możemy pobrać stąd:
https://seblu.net/a/arm/packages/. Oczywiście najprościej jest zainstalować program downgrade:
yaourt -S downgradei przy jego użyciu dokonać zmiany wersji danej paczki na starszą (np. e4rat występujące w AUR nie buduje się z wykorzystaniem ostatniej, dostępnej wersji audit, ale jeśli ją cofniemy, wówczas paczka zbuduje się prawidłowo).
Może się jednak zdarzyć, że zależności nie pozwolą na cofnięcie paczki - w takiej sytuacji lepiej jest zaniechać dalszych prób, gdyż możemy poważnie uszkodzić system.
4. Usuwanie zbędnych patchy.
Z tym problemem miałem styczność zarówno podczas kompilowania kerneli jak i nowszych wersji KDE (o ile pamiętam, było to przy kompilowaniu KDE 4.14 beta3 czyli 4.13.95). Na czym polega błąd? Już wyjaśniam. Otóż czasem na kernel/program nakładana jest tymczasowa łatka, usuwająca jakiś błąd. Przy kolejnej wersji upstream może (nie musi) naprawić ten błąd, przez co możemy otrzymać taki komunikat:
"Reversed (or previously applied) patch detected!"Czasem namierzenie tego patcha jest bardzo łatwe (komunikat wskazuje "winnego" całej sytuacji) - wtedy usuwamy patch i po sprawie. Niestety, czasem namierzenie jest trudniejsze (zwłaszcza, jeśli takich patchy jest kilka i tylko część z nich została załatana). Wtedy musimy uzbroić się w cierpliwość i metodą prób i błędów usuwać patche i sprawdzać, czy komunikat dalej występuje. Jeśli po usunięciu patcha komunikat nie ustąpił, nakładamy go ponownie i próbujemy dalej, do skutku. Jeśli po usunięciu patcha dostaniemy podobny (ale inny) komunikat, postępujemy analogicznie - aż do sytuacji, w której te komunikaty przestaną występować.
Moja rada - zamiast usuwać wpisy dotyczące patcha lepiej jest je zakomentować znakiem
#, przynajmniej do czasu, gdy ustalimy które patche możemy usunąć a które lepiej zostawić. Za każdym razem musimy generować nowe sumy kontrolne - musimy o tym pamiętać.
