Zrozumieć niezrozumiałe - korzystanie z AUR helperów
Jak niemal wszyscy doskonale wiemy, w Archu istnieje AUR, zawierający "paczki", których nie ma w repozytoriach oficjalnych. Akronim tłumaczy się jako Arch User Repository. Tylko, że w przeciwieństwie do "normalnych" repozytoriów znanych z innych, mainstreamowych dystrybucji, w AUR nie spotkamy paczek binarnych, gotowych do zainstalowania w systemie, a jedynie "przepisy" na ich lokalną (na komputerze użytkownika) budowę. W AUR znajdują się zatem wyłącznie pliki automatyzujące kompilację jakiegoś programu i tworzące z niego paczkę rozpoznawalną przez pacmana, która może być następnie przez niego zarządzana.
Arch zaleca, by korzystanie z AUR odbywało się w nastąpujący sposób:
Jak zatem zauważyliście, cały proces budowy paczki odbywa się zatem na naszym dysku.
Żadne z narzędzi oficjalnie oferowanych w repozytoriach Archa nie potrafi zarządzać przepisami z AUR bezpośrednio. Przyroda nie znosi próżni, a człowiek ma to do siebie, że jeśli może sobie coś ułatwić, to prędzej, czy później tego dokona. Nie inaczej stało się z AUR. Mamy cały wysyp różnych narzędzi, które automatyzują powyższy proces. Chyba najpopularniejszym pozostaje yaourt pomimo wielkiej niechęci do tego narzędzia deweloperów Archa. Programy tego typu zwane są AUR helperami. Ich działanie obejmuje zwykle możliwość przeszukiwania bazy AUR w poszukiwaniu interesującego nas programu, budowę oraz instalację (mniejsza o to, że ostatecznie i tak instaluje taki program pacman) zbudowanej paczki. Na pierwszy rzut oka, wszystkie te programy zachowują się zatem dokładnie tak samo jak pacman, na którego zresztą stanowią swego rodzaju nakładkę, czy też dla którego są pewnym rozszerzeniem.
Proces kompilacji dokonuje dziesiątek odwołań do plików. Jeśli wykonywany jest na dysku typu HDD jest on powolniejszy, zwykle również konsekwencją tych odwołań do dysku jest spowolnienie działania całego środowiska, czy programów. Większość AUR helperów do procesu kompilacji wykorzystuje katalog /tmp. W Archu nie jest to "zwykły" katalog umieszczony na dysku, ale pewna przestrzeń tworzona w RAM. W ten sposób tworzenie paczki jest nie tylko szybsze, ale również oszczędza nam dysk.
Ma to jednak inne konsekwencje.
Podczas budowania paczki ściągane są źródła, następnie tworzone są dwa katalogi src oraz pkg. W następnym kroku źródła są przenoszone do katalogu src, tam rozpakowywane, potem odbywa się proces kompilacji, a następnie zbudowane w jego wyniku skompilowane już składniki aplikacji, są przenoszone do katalogu pkg, który w dalszej kolejności jest pakowany do jakiejś postaci akceptowalnej przez pacmana - najczęściej tar.xz.
Zwróćmy teraz uwagę, że w katalogu, w którym tworzona jest paczka musimy zarezerwować miejsce dla źródeł i to często dwukrotnie, rozpakowanych źródeł, plików tworzonych podczas kompilacji programu oraz będących jej wynikiem plików binarnych, które również wymagają podwójnego miejsca (raz w src drugi raz w pkg) oraz spakowanej paczki. Standardowo, w przypadku AUR helperów wszystko to odbywa się w RAM, a w zasadzie do dyspozycji tmpfs, w którego części mieści się tmp gdzie paczka jest budowana, w połowie jej rozmiaru (domyślnie dla tmpfs rezerwowana jest połowa dostępnej pamięci RAM).
Pół biedy zatem, gdy za pomocą AUR helpera budujemy stosunkowo niewielką paczkę, która ma stosunkowo niewielkie źródła. Wszystko przebiegnie gładko i po chwili otrzymamy zbudowaną paczkę, gotową do zainstalowania. Jednakże, gdy zamierzamy zbudować jakiś większy program, bądź też całkiem mały, jednakże wymagający sporo miejsca, to bez trudu cała przestrzeń tmp zostanie zajęta na potrzeby budowania paczki. Konsekwencją będzie nie tylko częsty komunikat o braku dostępnego miejsca dla jej budowy, ale nawet problemy w działaniu całego systemu.
Dla uzmysłowienia sobie skali problemu zwróćmy uwagę na stosunkowo niewielką paczkę i zarazem często stosowaną, jaką jest opera-ffmpeg-codecs. Cała paczka, po zbudowaniu liczy zaledwie ok. 3 MB. Dla zbudowania wymaga jednak pobrania źródeł całego chromium, które liczą sobie blisko 460 MB i to w postaci skompresowanej do xz. Po rozpakowaniu sam katalog ze źródłami chromium liczy sobie ok. 2,4 GB. Efekt jest taki, że dla zbudowania stosunkowo małej paczki opera-ffmpeg-codecs wymagany jest obszar ok. 4-5 GB pamięci RAM. Jest oczywiste, że na komputerze, który nie jest wyposażony w co najmniej 6 GB RAM (a i to jest absolutnie graniczną wielkością i zależną od wielu czynników) taka operacja się nie powiedzie. Konsekwencją próby budowy tej paczki na komputerze, który ma nie więcej niż 4 GB RAM może być stopniowy spadek responsywności środowiska (jeśli budujemy jednocześnie korzystając z jakiegoś), aż do oznak zawieszenia się komputera (tak na prawdę, to winny one minąć, niemniej jednak przez dłuższą chwilę komputer będzie zachowywał się jakby był zawieszony).
Dodatkowo musimy jeszcze pamiętać, że nie każdy AUR helper usuwa po sobie pozostałości budowania paczki, które w dalszym ciągu zajmują RAM (tmp).
Innymi słowy - budujmy paczki z głową.
Arch zaleca, by korzystanie z AUR odbywało się w nastąpujący sposób:
- ściągnięcie tzw. tarballa ze źródłami, bądź obecnie - sklonowanie ich repozytorium z GIT,
- przejście do katalogu z PKGBUILD (po ewentualnym wcześniejszym rozpakowaniu źródeł),
- wydanie polecenia makepkg z odpowiednimi przełącznikami,
- instalacja paczki (oczywiście można to wykonać w jednej linii z makepkg).
Jak zatem zauważyliście, cały proces budowy paczki odbywa się zatem na naszym dysku.
Żadne z narzędzi oficjalnie oferowanych w repozytoriach Archa nie potrafi zarządzać przepisami z AUR bezpośrednio. Przyroda nie znosi próżni, a człowiek ma to do siebie, że jeśli może sobie coś ułatwić, to prędzej, czy później tego dokona. Nie inaczej stało się z AUR. Mamy cały wysyp różnych narzędzi, które automatyzują powyższy proces. Chyba najpopularniejszym pozostaje yaourt pomimo wielkiej niechęci do tego narzędzia deweloperów Archa. Programy tego typu zwane są AUR helperami. Ich działanie obejmuje zwykle możliwość przeszukiwania bazy AUR w poszukiwaniu interesującego nas programu, budowę oraz instalację (mniejsza o to, że ostatecznie i tak instaluje taki program pacman) zbudowanej paczki. Na pierwszy rzut oka, wszystkie te programy zachowują się zatem dokładnie tak samo jak pacman, na którego zresztą stanowią swego rodzaju nakładkę, czy też dla którego są pewnym rozszerzeniem.
Proces kompilacji dokonuje dziesiątek odwołań do plików. Jeśli wykonywany jest na dysku typu HDD jest on powolniejszy, zwykle również konsekwencją tych odwołań do dysku jest spowolnienie działania całego środowiska, czy programów. Większość AUR helperów do procesu kompilacji wykorzystuje katalog /tmp. W Archu nie jest to "zwykły" katalog umieszczony na dysku, ale pewna przestrzeń tworzona w RAM. W ten sposób tworzenie paczki jest nie tylko szybsze, ale również oszczędza nam dysk.
Ma to jednak inne konsekwencje.
Podczas budowania paczki ściągane są źródła, następnie tworzone są dwa katalogi src oraz pkg. W następnym kroku źródła są przenoszone do katalogu src, tam rozpakowywane, potem odbywa się proces kompilacji, a następnie zbudowane w jego wyniku skompilowane już składniki aplikacji, są przenoszone do katalogu pkg, który w dalszej kolejności jest pakowany do jakiejś postaci akceptowalnej przez pacmana - najczęściej tar.xz.
Zwróćmy teraz uwagę, że w katalogu, w którym tworzona jest paczka musimy zarezerwować miejsce dla źródeł i to często dwukrotnie, rozpakowanych źródeł, plików tworzonych podczas kompilacji programu oraz będących jej wynikiem plików binarnych, które również wymagają podwójnego miejsca (raz w src drugi raz w pkg) oraz spakowanej paczki. Standardowo, w przypadku AUR helperów wszystko to odbywa się w RAM, a w zasadzie do dyspozycji tmpfs, w którego części mieści się tmp gdzie paczka jest budowana, w połowie jej rozmiaru (domyślnie dla tmpfs rezerwowana jest połowa dostępnej pamięci RAM).
Pół biedy zatem, gdy za pomocą AUR helpera budujemy stosunkowo niewielką paczkę, która ma stosunkowo niewielkie źródła. Wszystko przebiegnie gładko i po chwili otrzymamy zbudowaną paczkę, gotową do zainstalowania. Jednakże, gdy zamierzamy zbudować jakiś większy program, bądź też całkiem mały, jednakże wymagający sporo miejsca, to bez trudu cała przestrzeń tmp zostanie zajęta na potrzeby budowania paczki. Konsekwencją będzie nie tylko częsty komunikat o braku dostępnego miejsca dla jej budowy, ale nawet problemy w działaniu całego systemu.
Dla uzmysłowienia sobie skali problemu zwróćmy uwagę na stosunkowo niewielką paczkę i zarazem często stosowaną, jaką jest opera-ffmpeg-codecs. Cała paczka, po zbudowaniu liczy zaledwie ok. 3 MB. Dla zbudowania wymaga jednak pobrania źródeł całego chromium, które liczą sobie blisko 460 MB i to w postaci skompresowanej do xz. Po rozpakowaniu sam katalog ze źródłami chromium liczy sobie ok. 2,4 GB. Efekt jest taki, że dla zbudowania stosunkowo małej paczki opera-ffmpeg-codecs wymagany jest obszar ok. 4-5 GB pamięci RAM. Jest oczywiste, że na komputerze, który nie jest wyposażony w co najmniej 6 GB RAM (a i to jest absolutnie graniczną wielkością i zależną od wielu czynników) taka operacja się nie powiedzie. Konsekwencją próby budowy tej paczki na komputerze, który ma nie więcej niż 4 GB RAM może być stopniowy spadek responsywności środowiska (jeśli budujemy jednocześnie korzystając z jakiegoś), aż do oznak zawieszenia się komputera (tak na prawdę, to winny one minąć, niemniej jednak przez dłuższą chwilę komputer będzie zachowywał się jakby był zawieszony).
Dodatkowo musimy jeszcze pamiętać, że nie każdy AUR helper usuwa po sobie pozostałości budowania paczki, które w dalszym ciągu zajmują RAM (tmp).
Innymi słowy - budujmy paczki z głową.
Komentarze
Prześlij komentarz