pavbaranov Arch

Jednym ze sposobów przyspieszenia aktualizacji oraz zmniejszenia wielkości danych ściąganych przy tej okazji z internetu jest użycie tzw. delta upgrade . Niestety nie wszystkie serwery to oferują. Znając taki serwer można się jednak pokusić o wprowadzenie odpowiednich zmian. Przede wszystkim zaczynamy od serwera. W tej chwili znam jedynie takie dwa , w tym jeden z dalekiego RPA. Zasadniczym krokiem jest zmiana pliku /etc/pacman.d/mirrorlist  i dodanie na pierwszym miejscu serwera oferującego delta upgrades. Posiłkując się listą z powyższego odnośnika dodajemy zatem: Server = http://archlinux.uk.mirror.allworldit.com/archlinux-deltarepo/$repo/os/$arch Można też dodać drugi serwer z RPA: Server = http://archlinux.za.mirror.allworldit.com/archlinux-deltarepo/$repo/os/$arch   Dokonujemy zmian w pliku /etc/pacman.conf poprzez: 1. usunięcie znaku #  sprzed: - w sekcji [options] #UseDelta    = 0.7 - w sekcji #Misc options #UseDelta 2. instalujemy paczk...

Dzięki pracy naszego forumowicza nycko123 powstała (bo już jest) i powstaje (bo będzie lepsza) swego rodzaju nakładka na pacmana (a także asp) stanowiąca jednocześnie podstawowy tzw. AURhelper. Po co kolejna, skoro już tyle ich jest? O to spytajcie autora, jednakże ze swej strony mogę wyliczyć jej niewątpliwe zalety. Przede wszystkim jest to skrypt w czystym języku powłoki. Zaledwie jeden plik wykonywalny, jeden konfiguracyjny oraz spolszczenie. W porównaniu z wieloma innymi tego typu narzędziami nie wymaga on zatem instalacji w systemie dużej ilości zależności. Tam, gdzie to możliwe, posługuje się systemowymi narzędziami. W zakresie, w jakim stanowi on menedżer paczek wykorzystuje po prostu pacmana. Z całą jego składnią. Jednocześnie składnię tę rozszerza. Instalując bowiem opcjonalną zależność asp, umożliwia również proste ściągnięcie źródeł paczek z repozytoriów. Oficjalnych na pewno. Jeśli chodzi o nieoficjalne - tu gorzej, albowiem najczęściej tych źródeł po prostu nie ma, a jeś...

Oj, tam. Psioczymy niekiedy na nasz system (Arch), a nie znamy jego możliwości. Psioczymy na przykład, że aby sprawdzić możliwość aktualizacji systemu musimy wydać jakieś polecenie, wpisać hasło administratora i dopiero potem dowiemy się, czy aktualizacja jest możliwa. Innymi słowy, wpisujemy w terminalu: sudo pacman -Syu No dobrze, a czy korzystając z dobrodziejstw zainstalowanych wraz z pacmanem nie możemy napisać: checkupdates ...? Nie musimy wpisywać haseł administratora, niczego. Po chwili uzyskamy informację czy jest, czy też nie jest możliwa aktualizacja systemu.

Arch oferuje doprawdy świetne narzędzie do obsługi pakietów. Niemniej jednak zbliża się już koniec drugiej dekady XXI w. i przyzwyczajenia użytkowników, czy też ich oczekiwania w zakresie jakiegoś prostego, graficznego menedżera paczek są duże i poniekąd można je uznać za uzasadnione. Tymczasem pacman czuje się jak ryba w wodzie wyłącznie w konsoli. Natura nie znosi próżni, stąd też już od dawna powstają takie graficzne menedżery. Ostanio - głównie za sprawą ich domyślnego instalowania w dystrybucjach pochodnych - popularność zyskały pamac oraz octopi. Oba te programy oferują, działające nieustannie w tle, małe narzędzia monitorujące możliwość aktualizacji pakietów. W ich konfiguracji można sobie zmienić częstotliwość aktualizacji. Jeśli nic nie zmienimy w systemie, to owe narzędzia zainstalują się wraz ze wspomnianymi menedżerami i ustawione będą (o ile pamiętam) na sprawdzanie aktualizacji raz dziennie. Zwykle oznacza to, że rozpoczynają swe działanie zaraz po pierwszym uruchomieniu ...

Zdarza się, że przy aktualizacji lub instalacji jakichś paczek w systemie pojawia się informacja, że jakiś plik znajduje się już w systemie plików. Potem otrzymujemy jedynie informację, że żadna paczka nie została zainstalowana, czy zaktualizowana. Nie jest to żaden problem i gdy tylko będziemy postępować właściwie rozwiązanie zawsze się znajdzie. Wpierw jednak jestem winien jedno wytłumaczenie. Dla użytkowników innych menedżerów paczek dziwnym może się wydawać, że skoro jakiś jeden pakiet nie może być zainstalowany, to inne pakiety również. Otóż pacman nie wspiera aktualizacji pojedynczej paczki. I słusznie - Arch jest dystrybucją ciągłą i paczki dostępne w repozytorium są (winny być) zawsze już przebudowane, gdy nowe wersje ich zależności wprowadzone zostały do repozytorium. Wracamy. Przede wszystkim wszelkie rozwiązania typu skasować plik, który koliduje, sforsować instalację nowej paczki itp., które są niekiedy pokazywane jako remedium na wszystkie bolączki nie są właście. W nieszc...

W Archu wiele programów zawiera wszystkie swoje pliki lokalizacyjne. W ten sposób, instalując jakiś program otrzymujemy nie tylko te pliki, które chcemy, ale także takie, z których na pewno nie skorzystamy. Wprawdzie nie jest są to pliki duże, jednakże skoro nie muszą w naszym systemie istnieć, to po co mają w nim być? Wielu prawdopodobnie spotkało się z takimi narzędziami jak localepurge, czy bleachbit i próbowało zapewne z ich pomocą usuwać te pliki. Po takiej czynności pacman będzie jednakże sygnalizował niespójność pakietów (brak ich części). Od czasu pojawienia się wersji 4.2 pacmana istnieje jednakże znacznie lepsze rozwiązanie. Otóż w pliku /etc/pacman.conf możemy skorzystać z tzw. odwróconych wyrażeń regularnych, które umieścimy w polu NoExtract . W ten sposób pacman zostanie poinstruowany o tym, że z paczki nie ma rozpakować określonych plików i umieścić ich w systemie. Zainstalowane tak paczki nie będą powodowały żadnych informacji o błędach ze strony pacmana. Konieczne jest...

Nie, żadne magiczne ustawienia kompilatora. Nie o to chodzi. Program, który "steruje" kompilowaniem paczek zarządzanych przez pacmana, to makepkg. Jest on wykorzystywany nie tylko przy lokalnym tworzeniu paczek z jego pomocą, ale również chyba przez wszystkie tzw. helpery AUR. Program jest sterowany plikiem /etc/makepkg.conf . Wewnątrz katalogu, w którym następuje budowa paczki, tworzone są dwa podkatalogi: src  oraz pkg . W pierwszym następuje budowa (kompilacja) programu. Jeśli to zostanie wykonane bez błędów, skompilowany program wraz ze wszystkimi elementami niezbędnymi do jego działania umieszczany jest w katalogu pkg , którego wewnętrzna struktura odpowiada systemowi katalogów Archa (czy innej dystrybucji). Przynajmniej powinna odpowiadać. Następnie cała zawartość katalogu jest pakowana do pliku tar , który - jeśli domyślnych ustawień makepkg.conf  nie zmienimy jest następnie kompresowany (np. do formatu xz . W ten sposób otrzymujemy znane nam paczki pacmana nazwa.pkg....

Co jakiś czas pojawiają się pośród użytkowników Archa, czy Manjaro rozpaczliwe głosy związane z próbą zainstalowania paczek pochodzących z najpopularniejszych dystrybucji, a w zasadzie paczek oferowanych w formacie deb lub rpm. Najczęściej głosy te pochodzą od bardzo świeżych użytkowników naszej dystrybucji. Co gorsza dotyczą one często sterowników, albo aplikacji, które i tak są oferowane w AUR albo w jakchś repozytoriach. Ze względu na dostępność w repozytoriach Archa dpkg oraz rpm w ślad za takim "lamentem" idzie cudowna podpowiedź: zainstaluj sobie dpkg/rpm i za pomocą tego menedżera zainstaluj paczkę w systemie. Czy coś takiego ma szansę powodzenia? Oczywiście. Menedżer paczek jest wszak aplikacją wyspecjalizowaną w m.in. ich instalacji. I wszystko wydaje się wspaniałe. STOP. Niestety nic nie jest wspaniałe. Nie tak się to robi i tak instalacji aplikacji pakowanych dla obcych dystrybucji się nie robi. Kiedy o tym pisałem, spotykałem się z najpopularniejszym pytaniem...