pavbaranov Arch

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 ...

Prawdopodobnie nikt, kto korzysta z KDE nie musiał instalować packagekit. Wraz z wersją Plasma 5.10 pojawiła się jednak nowa wersja aplikacji Discover (plasma-discover), która w opcjonalnych zależnościach posiada flatpak oraz packagekit-qt5. Obie rozszerzają możliwości Discover na instalację przez tą aplikację innych programów. Umożliwiają również instalowanie ich za pomocą Krunnera. Pierwsza instaluje paczki flatpak. Druga instaluje paczki z repozytorium. Pewnie wielu z Was zdziwi zachowanie tej aplikacji przy instalowaniu pakietów. Otóż w standardowej instalacji Archa (i pewnie innych pochodnych dystrybucji) próba zainstalowania jakiejkolwiek aplikacji przez Discover oznajmi jedynie, że przebiega instalacja i... po chwili program zostanie zainstalowany. Dodatkowo zostanie on zainstalowany systemowo, w katalogu głównym linuksa. Nie tylko bez pytania o pozwolenie (czyt. hasło administratora), ale również bez oznajmiania jakie zależności zostaną zainstalowane. Co ciekawe odinstalowanie ...

Od pewnego czasu, jak świat długi i szeroki, dochodzą informacje o niesamowitym problemie związanym z aktualizacją, bądź instalacją paczek w Antergosie. Wszystkiemu winni są oczywiście ludzie. Tym razem deweloperzy Antergosa, który swoją nową paczkę antergos-keyring , która odpowiada za wprowadzenie do systemu kluczy GPG umożliwiających sprawdzenie autentyczności pakietów, podpisali jakimiś wadliwymi kluczami. Innymi słowy paczka *.sig jest wadliwa. Nie mam ochoty dochodzić co jest zrobione źle, zwłaszcza, że nie mam wpływu na poprawę tego pliku. Mogę jedynie przedstawić proste rozwiązanie. Kiedy zatem otrzymujecie błąd, tego typu (może ich być więcej, to jedynie przykład): błąd: antergos-keyring: signature from "Antergos Build Server (Automated Package Build System) " is unknown trust :: Plik /var/cache/pacman/pkg/antergos-keyring-20170524-1-any.pkg.tar.xz jest uszkodzony (Niepoprawny lub uszkodzony pakiet (podpis PGP)). Czy chcesz go usunąć? [T/n] Odpowiadacie na to pytan...

ABS, dotychczasowe narzędzie służące w Archu do pobierania kodu źródłowego paczek (nie mylić z kodem samych aplikacji) zakończyło swój byt . Wcale to jednak nie oznacza, że jesteśmy zdani na ręczne przekopiowanie wszystkich niezbędnych plików służących budowie paczki. Otóż, prawdopodobnie już u każdego z nas zagościł niewielki programik asp . Tak niewielki, że można go było przeoczyć. Ów programik z powodzeniem może służyć właśnie do tego, do czego dotychczas służył ABS. Po pierwszym uruchomieniu powstanie nam katalog ~/.cache/asp . Potem, gdy będziemy chcieli pobrać kod niezbędny do budowy paczki wystarczy wpisać: asp export nazwa_repozytorium/nazwa_paczki Stosowny katalog z wszystkimi plikami, które służą jej budowaniu zostanie utworzony w miejscu wydania powyższego polecenia. Sam kod oraz nieco więcej o użyciu programu znajdziecie na githubie .

Zdarza się niekiedy, że KMail powita nas takim ekranem: W zasadzie nie jest to problem. Trzeba poukładać sobie od nowa skrzynkę, pobrać wiadomości itd. itp. Problem, gdy nie mamy na to czasu. Wówczas... proste rozwiązanie. Otwieramy konsolę, wpisujemy: akonadictl restart i po chwili możemy się cieszyć poprawnie działającym KMail.

Pytanie wydaje się być trywialne. Przecież wszyscy wiemy (oczywiście na podstawie Archa): # pacman -S nazwa_pakietu Czyżby? Cóż doczytaliśmy się jednej informacji, ale pominęliśmy inne. Oczywiście, że powyższe polecenie zainstaluje pakiet. Całkiem możliwe, że aplikacja będzie działać. Niemniej jednak pozwolę sobie zauważyć, że posiąwszy powyższą wiedzę nie doczytaliśmy się innej informacji: częściowa aktualizacja nie jest przez pacman wspierana . Zaraz pewnie usłyszę: co ma aktualizacja, w dodatku częściowa do instalacji pakietu. Ano ma. Przyglądnijmy się na początek co zawierają repozytoria Archa. Trywialnie możemy odpowiedzieć: paczki. Tylko, że w przeciwieństwie do dystrybucji wydawniczych, są one "w ciągłym ruchu". Arch linux zainstalowany miesiąc temu nie będzie tym samym systemem, który zainstalowaliśmy dzisiaj i to nawet jeśli w obu wprowadzimy te same pakiety, albowiem nie będą one - przynajmniej w części - te same, ale takie same. Nazwa będzie taka sama, ale już w...

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...