Budujemy paczki z AUR bez yaourt, czy innego wrappera
Ze względu na to, że do świata Archa najczęściej droga prowadzi z innych dystrybucji, w internecie krążą różne mity. Tym razem wspomnę jedynie o tych związanych z AUR. Co rusz można się dowiedzieć, że repozytorium AUR to "takie PPA" (ze świata *buntu), czy nieoficjalne repozytoria znane innym dystrybucjom. Otóż nic bardziej błędnego. Podczas, gdy w PPA, czy w nieoficjalnych repozytoriach (Archowi takie również są znane) znajdziemy paczki binarne, to AUR jest jedynie składnicą "przepisów" pozwalających jedynie na skompilowanie programu ze źródeł i stworzenie z nich paczki, którą można zarządzać przez pacmana. Owe "przepisy" są po prostu instrukcjami, które potrafią odczytać narzędzia systemowe Archa. Praktycznie wszelkie narzędzia, jakie możemy wywołać w powłoce (np. bash).
Co to oznacza dla użytkownika? Cóż - m.in. to, że skoro może być w tych "przepisach" dowolna co do zasady komenda, to biorąc pod uwagę, że nie istnieje jakakolwiek weryfikacja owych skryptów, ani też użytkowników, którzy je umieszczają w AUR (z wyjątkiem tej, przeprowadzanej na własnej skórze użytkowników), to "przepisy" te należy czytać. Jak mamy przepis kulinarny, w którym będzie napisane, by dodać arszenik, to też przecież nie zrobimy takiej potrawy.
Co to oznacza dalej? Jeśli to jedynie "przepis" na zbudowanie paczki, a pacman potrafi zarządzać dopiero paczką, to nie służy on do obsługi repozytorium AUR.
Nadto trzeba mieć świadomość, że pomimo tego, że w wiki Archa znajdziemy wielokrotnie jakieś instrukcje polecające instalację jakiegoś programu z AUR, to tak samo wiki (z wyjątkiem oficjalnego podręcznika), jak i AUR nie znajduje się pod opieką deweloperów tej dystrybucji. Arch udostępnia jedynie narzędzie do przeszukiwania repozytorium AUR, które obecnie mieści się na githubie. Brak wsparcia dla AUR przez Archa oznacza, że co do zasady nie trafią do jego repozytoriów narzędzia rozszerzające możliwości pacmana o obsługę AUR (tzw. wrappery). Nie znajdzecie zatem tu popularnego - choć odsądzanego od czci i wiary - yaourt, czy jakiegokolwiek innego.
Nadeszła zatem ta chwila, gdy jesteśmy po świeżej instalacji Archa i właśnie zacieramy ręce ze znanym hasłem w ustach: no i co by tu jeszcze spieprzyć, panowie. AUR jest świetną skarbnicą takich możliwości.
No, ale jak zainstalować z AUR cokolwiek, skoro brak ulubionego yaourta? Jogurt kupujemy w sklepie, a my zajmiemy się możliwościami, jakie tkwią w samym Archu. Przecież paczki budowane z AUR są według tych samych receptur, jakie obowiązują dla paczek umieszczanych w jego repozytoriach. Narzędzia zatem muszą w Archu być. I są.
W pierwszej kolejności trzeba zainstalować zbiór podstawowych programów, które służą rozwojowi paczek - należą one do grupy base-devel. Instalujemy:
W tej chwili jesteśmy wstępnie przygotowani do budowy paczki z AUR (a także z oficjalnych repozytoriów, czy z innych miejsc, gdzie podawane są PKGBUILDy i pozostałe skrypty umożliwiające ich budowę).
Polecam jednak zaopatrzenie się również w walidatora PKGBUILD i paczek o nazwie namcap:
W ramce po prawej stronie znajdujemy "akcje" jakie możemy wykonać. Wpierw jednak czytamy komentarze. Już z nich możemy się bowiem wiele dowiedzieć. Zakładając, że wszystko jest ok, przeglądamy PKGBUILD. Musimy się bowiem upewnić, że to co chcemy zainstalować w istocie zostanie zainstalowane, a nie trafiliśmy na jakiegoś dowcipnisia. Wiemy co jest napisane - ok, nie wiemy, nie rozumiemy - to albo sięgamy po wiedzę bardziej doświadczonych użytkowników, albo ryzykujemy (wszak czy nie to robimy korzystając z wrapperów?).
Ze wspomnianej ramki ściągamy snapshot (Download snapshot), paczkę tar.gz, która zawiera całość skryptów. Najlepiej ją umieścić w jakimś katalogu, który służył nam będzie do budowania paczek, np. ~/builds. Po ściągnięciu do katalogu snapshota, rozpakowujemy go:
Budową paczki zajmie się program makepkg. Wydajemy pierwsze polecenie:
Jeśli budowa się powiodła, w katalogu, w którym budowaliśmy paczkę zostanie ona utworzona i będzie nosić nazwę rozpoczynającą się od nazwy_snapshota i kończyć rozszerzeniem pkg.tar.xz. Oprócz tego zobaczymy tam dwa katalogi: src oraz pkg. Pierwszy zawiera źródła programu oraz efekty ich kompilacji, drugi mieści - w pewnym uproszczeniu - niespakowaną paczkę *.pkg.tar.xz. Warto teraz po raz drugi sięgnąć po namcap tyle, że teraz wywołać go na paczce:
Po udanym zbudowaniu paczki i zainstalowaniu jej w systemie, możemy usunąć pozostałości po budowaniu, takie jak katalogi src i pkg, czy też całość katalogu, w którym paczka była budowana. Pamiętajmy jednak, że tak zbudowana paczka nie trafi do katalogu /var/cache/pacman/pkg.
Osobiście sugerowałbym co najmniej pozostawienie skryptów budujących paczkę (i ewentualnie ściągniętych źródeł), szczególnie gdy dokonaliśmy jakichś zmian w PKGBUILD. Pamiętajmy bowiem, że całość AUR jest poza obszarem zainteresowania twórców paczek w Archu. O ile zatem - co do zasady - system zbudowany z repozytoriów Archa (w tym poszczególne aplikacje) winien działać, to zasada ta nie obowiązuje już w przypadku programów budowanych z AUR. Często się zdarza, że do systemu dostarczone są np. nowe biblioteki, które nie posłużyły budowaniu paczki z AUR i po ich instalacji, taka aplikacja z AUR przestaje działać. Wówczas trzeba ją przebudować (jeśli się da) i zainstalować od nowa przebudowaną wersję. Stąd też dobrze mieć swój PKGBUILD, który temu służył.
Powyższe oczywiście nie wyczerpuje (i nie było to moim zamiarem) całości kwestii związanych z budową paczek. Polecam w tym zakresie wiki Archa, rozpoczynając od materiału o AUR. Przyda się również inna wiedza, prezentowana w ramce po prawej stronie. Mam nadzieję jednak, że prezentowany wyżej tekst przyda się szczególnie osobom, które w Archu znalazły się po raz pierwszy.
Co to oznacza dla użytkownika? Cóż - m.in. to, że skoro może być w tych "przepisach" dowolna co do zasady komenda, to biorąc pod uwagę, że nie istnieje jakakolwiek weryfikacja owych skryptów, ani też użytkowników, którzy je umieszczają w AUR (z wyjątkiem tej, przeprowadzanej na własnej skórze użytkowników), to "przepisy" te należy czytać. Jak mamy przepis kulinarny, w którym będzie napisane, by dodać arszenik, to też przecież nie zrobimy takiej potrawy.
Co to oznacza dalej? Jeśli to jedynie "przepis" na zbudowanie paczki, a pacman potrafi zarządzać dopiero paczką, to nie służy on do obsługi repozytorium AUR.
Nadto trzeba mieć świadomość, że pomimo tego, że w wiki Archa znajdziemy wielokrotnie jakieś instrukcje polecające instalację jakiegoś programu z AUR, to tak samo wiki (z wyjątkiem oficjalnego podręcznika), jak i AUR nie znajduje się pod opieką deweloperów tej dystrybucji. Arch udostępnia jedynie narzędzie do przeszukiwania repozytorium AUR, które obecnie mieści się na githubie. Brak wsparcia dla AUR przez Archa oznacza, że co do zasady nie trafią do jego repozytoriów narzędzia rozszerzające możliwości pacmana o obsługę AUR (tzw. wrappery). Nie znajdzecie zatem tu popularnego - choć odsądzanego od czci i wiary - yaourt, czy jakiegokolwiek innego.
Nadeszła zatem ta chwila, gdy jesteśmy po świeżej instalacji Archa i właśnie zacieramy ręce ze znanym hasłem w ustach: no i co by tu jeszcze spieprzyć, panowie. AUR jest świetną skarbnicą takich możliwości.
No, ale jak zainstalować z AUR cokolwiek, skoro brak ulubionego yaourta? Jogurt kupujemy w sklepie, a my zajmiemy się możliwościami, jakie tkwią w samym Archu. Przecież paczki budowane z AUR są według tych samych receptur, jakie obowiązują dla paczek umieszczanych w jego repozytoriach. Narzędzia zatem muszą w Archu być. I są.
W pierwszej kolejności trzeba zainstalować zbiór podstawowych programów, które służą rozwojowi paczek - należą one do grupy base-devel. Instalujemy:
# pacman -S base-develpotwierdzając, że chcemy zainstalować wszystkie paczki. Co do zasady żaden program, który składa się na tę grupę nie będzie znajdował się w zależnościach służących do budowy pakietu (makedepends), zatem bez tego ani rusz. Z drugiej strony, jeśli jakikolwiek program służący do budowania paczki nie znajduje się w tej grupie, to winien on być dodany do makedepends.
W tej chwili jesteśmy wstępnie przygotowani do budowy paczki z AUR (a także z oficjalnych repozytoriów, czy z innych miejsc, gdzie podawane są PKGBUILDy i pozostałe skrypty umożliwiające ich budowę).
Polecam jednak zaopatrzenie się również w walidatora PKGBUILD i paczek o nazwie namcap:
# pacman -S namcapWyszukujemy interesujący nas program w AUR na stronie: https://aur.archlinux.org/packages/
W ramce po prawej stronie znajdujemy "akcje" jakie możemy wykonać. Wpierw jednak czytamy komentarze. Już z nich możemy się bowiem wiele dowiedzieć. Zakładając, że wszystko jest ok, przeglądamy PKGBUILD. Musimy się bowiem upewnić, że to co chcemy zainstalować w istocie zostanie zainstalowane, a nie trafiliśmy na jakiegoś dowcipnisia. Wiemy co jest napisane - ok, nie wiemy, nie rozumiemy - to albo sięgamy po wiedzę bardziej doświadczonych użytkowników, albo ryzykujemy (wszak czy nie to robimy korzystając z wrapperów?).
Ze wspomnianej ramki ściągamy snapshot (Download snapshot), paczkę tar.gz, która zawiera całość skryptów. Najlepiej ją umieścić w jakimś katalogu, który służył nam będzie do budowania paczek, np. ~/builds. Po ściągnięciu do katalogu snapshota, rozpakowujemy go:
tar -zxvf nazwa_snapshota.tar.gzW katalogu utworzy się nowy katalog o nazwie_snapshota. Przechodzimy do niego. W katalogu tym znajdziemy plik PKGBUILD oraz ewentualnie inne pliki służące do budowy paczki, takie jak pliki instalacyjne (*.install), czy różne patche (chyba, że te są pobierane bezpośrednio z sieci). Możemy teraz także dostosować PKGBUILD do swoich potrzeb. Należałoby się także upewnić, czy PKGBUILD jest prawidłowy. Do tego służy nam ów wspomniany wcześniej walidator:
namcap PKGBULDJeśli weryfikacja odbędzie się prawidłowo (czyli namcap nie zwróci nic, po wywołaniu przejdzie do lini promptu) - możemy przystąpić do budowy paczki. Jeśli coś zwróci, to PKGBUILD nie jest prawidłowy (lub namcap zadziałał niewłaściwie) - wówczas albo modyfikujemy PKGBUILD (jeśli wiemy co robimy), albo sięgamy po wiedzę bardziej doświadczonych użytkowników, albo... ryzykujemy.
Budową paczki zajmie się program makepkg. Wydajemy pierwsze polecenie:
makepkg -sPrzełącznik "-s", który do niego został dodany służy sprawdzeniu zależności. Jeśli pola depends i makedepends zawierają jakieś zależności, których w naszym systemie nie ma, to o ile znajdują się one w repozytoriach Archa (bądź szerzej udostępnionych w pliku /etc/pacman.conf), zostaną one dociągnięte i zainstalowane, a paczka będzie dalej budowana. Jeśli jednak makepkg zwraca informację o nierozwiązanych zależnościach i nie może ich pobrać, to co do zasady należałoby przyjąć, że jakieś zależności znajdują się w AUR. Tych makepkg nie umie automatycznie zainstalować. Musimy je sami wyszukać i zbudować przed budową naszego pakietu.
Jeśli budowa się powiodła, w katalogu, w którym budowaliśmy paczkę zostanie ona utworzona i będzie nosić nazwę rozpoczynającą się od nazwy_snapshota i kończyć rozszerzeniem pkg.tar.xz. Oprócz tego zobaczymy tam dwa katalogi: src oraz pkg. Pierwszy zawiera źródła programu oraz efekty ich kompilacji, drugi mieści - w pewnym uproszczeniu - niespakowaną paczkę *.pkg.tar.xz. Warto teraz po raz drugi sięgnąć po namcap tyle, że teraz wywołać go na paczce:
namcap nazwa_paczki.pkg.tar.xzJeśli wszystko przebiegnie prawidłowo, a przede wszystkim nie otrzymamy informacji o błędach w paczce (oznaczone one będą przez E), to możemy paczkę instalować:
# pacman -U nazwa_paczki.pkg.tar.xzJeśli jednakże namcap pokazał nam jakieś błędy, to mamy czas na ich naprawę w PKGBUILD. Po tej czynności wywołujemy polecenie:
makepkg -RfPrzełącznik "-R" powoduje przebudowanie (przepakietowanie) paczki z uwzględnieniem nowego PKGBUILDu na podstawie już skompilowanych źródeł. Czynność ta zajmuje wiele mniej czasu niż budowanie paczki ze źródeł (ich kompilację). Przełącznik "-f" nadpisze wcześniej zbudowaną paczkę; jeśli ją wcześniej usuniemy - nie musimy go używać.
Po udanym zbudowaniu paczki i zainstalowaniu jej w systemie, możemy usunąć pozostałości po budowaniu, takie jak katalogi src i pkg, czy też całość katalogu, w którym paczka była budowana. Pamiętajmy jednak, że tak zbudowana paczka nie trafi do katalogu /var/cache/pacman/pkg.
Osobiście sugerowałbym co najmniej pozostawienie skryptów budujących paczkę (i ewentualnie ściągniętych źródeł), szczególnie gdy dokonaliśmy jakichś zmian w PKGBUILD. Pamiętajmy bowiem, że całość AUR jest poza obszarem zainteresowania twórców paczek w Archu. O ile zatem - co do zasady - system zbudowany z repozytoriów Archa (w tym poszczególne aplikacje) winien działać, to zasada ta nie obowiązuje już w przypadku programów budowanych z AUR. Często się zdarza, że do systemu dostarczone są np. nowe biblioteki, które nie posłużyły budowaniu paczki z AUR i po ich instalacji, taka aplikacja z AUR przestaje działać. Wówczas trzeba ją przebudować (jeśli się da) i zainstalować od nowa przebudowaną wersję. Stąd też dobrze mieć swój PKGBUILD, który temu służył.
Powyższe oczywiście nie wyczerpuje (i nie było to moim zamiarem) całości kwestii związanych z budową paczek. Polecam w tym zakresie wiki Archa, rozpoczynając od materiału o AUR. Przyda się również inna wiedza, prezentowana w ramce po prawej stronie. Mam nadzieję jednak, że prezentowany wyżej tekst przyda się szczególnie osobom, które w Archu znalazły się po raz pierwszy.
dzięki, pomocne
OdpowiedzUsuń