Jak uniknąć problemów z Antergosem

Przyglądając się problemom, jakie dostarcza Antergos wielu użytkownikom od kilku lat, spróbuję zestawić w punktach kilka porad, które zminimalizują najczęściej występujące z nim kłopoty.

1. Usunięcie plików *-meta.
Niemal wszystkie instalacje (pierwsze) Antergosa odbywają się z użyciem tzw. meta paczek. To jeden ze sposobów instalacji zespołu większej ilości programów w Archu. Meta paczki nie zawierają żadnych binarek. Są to jedynie paczki niosące informacje o tym, że jakieś paczki mają zostać w systemie zainstalowane. Treść PKGBUILDów takich paczek zawiera w polu depends listę paczek do zainstalowania. Taka instalacja powoduje, że późniejsza próba odinstalowania jednej z paczek umieszczonych w depends pociągnąć za sobą może chęć odinstalowania "połowy" systemu, albo spotkamy się z informacją o tym, że odinstalowanie czegoś nie jest możliwe.

Rozwiązanie
Po zainstalowaniu Antergosa, przeszukujemy system pod kątem zainstalowanych paczek z "meta" w nazwie. Ich nazwy wyglądają w następujący sposób "nazwa_czegoś-meta-dalsza_charakterystyka_paczki", ot choćby - instalując całą Plasmę w ten sposób mamy paczkę "plasma-meta".
Wyszukujemy u siebie:
pacman -Qs metaTeraz odinstalować należy każdą z tak znalezionych paczek.

Uwaga
W ten sposób pozbywamy się nałożonego nam kagańca, ale z drugiej strony istnieje łatwość odinstalowania paczek niezbędnych systemowi. O ile odinstalowanie jakiejś aplikacji, która wcześniej była w pliku "meta" nie stanowi już problemu i nie zrobi w systemie niczego złego, to już nad odinstalowaniem komponentów środowiska należy się zastanowić dwa razy i w razie wątpliwości spytać.

2. LightDM
Antergos używa LigthDM jako menedżer logowania. Wymyślony niegdyś w Canonical DM nie jest obecnie intensywnie rozwijany (Ubuntu i pochodne z niego zrezygnowały), co powoduje, że niekiedy możemy się spotkać z problemami po aktualizacjach systemu (nie oznacza to, że z innym DM nie będzie). Dodatkowo LigthDM uniemożliwia sesję w Wayland tych DE, które już mają taką możliwość (np. GNOME, Plasma). Problematyczny jest również jego oparty o technologię webową greeter. Możecie zatem rozważyć sobie zmianę tego DM na inny. Jedyna zaleta, to efekt estetyczny dla domyślnych tematów środowisk wspieranych przez Antergosa.
Proponuję dla środowisk:
a. GNOME - GDM
b. Plasma, LXQt (inne oparte o Qt5, jak choćby Lumina) - SDDM
c. Xfce4, MATE, Cinnamon (inne oparte na Gtk) - LXDM

Zmiana odbywa się w kilku ruchach:
1. Należy znaleźć odpowiedni DM w repozytorium i go zainstalować w systemie np.
pacman -Syu sddm2. Uruchamiamy nowy DM, np.:
systemctl enable sddm -f3. Restartujemy DM (uwaga nastąpi wylogowanie, zapiszcie co potrzebujecie) np.:
systemctl stop lightdm(w tym momencie winno nastąpić wylogowanie i system winien uruchomić się z wybranym, nowym DM).

3. Paczki z repozytorium AntergosW repozytorium Antergosa od czasu do czasu znajdują się paczki, których nie ma w repozytoriach Archa (z których Antergos bezpośrednio korzysta), ale są w AUR. Często paczki tu oferowane są tak konstruowane, by tzw. aur-helpery nie chciały ich aktualizować z AUR. Niestety rozwiązania przyjęte w Antergos nie są najlepsze i najlepiej skorelowane z Archem i AUR w tym zakresie. Otóż, gdy paczka z AUR przejdzie do repozytorium Archa jest od tej chwili aktualizowana przez jego zespół. Nie ma znaczenia, czy ta paczka, wcześniej budowana z AUR w repozytoriach Antergosa jeszcze istnieje, czy też została już usunięta. W naszym systemie pozostajemy z paczką starszą niż dostępna, która jest jednocześnie widoczna jako nowsza (to użycie epoch w PKGBUILD, co dla Was nie ma znaczenia) - pacman takiej paczki nie zaktualizuje. Jeśli zatem zobaczycie w systemie coś takiego (przykład z innego wątku):
ostrzeżenie: pepper-flash: local (1:26.0.0.137-1) jest nowsze niż extra (31.0.0.108-1)to oznacza, że spotkaliście się z takim problemem. Ostrzeżenie musi mieć taką postać:
a. wskazywać, że lokalna (local) paczka jest nowsza niż w repozytorium (extra, core, community, multilib),
b. numer wersji paczki "nowszej" musi mieć postać "1:jakieś.liczby",
c. numer wersji paczki w repozytorium musi mieć postać "jakieś.liczby",
d. "jakieś.liczby" z paczki w repo muszą mieć wartość większą (>) niż "jakieś.liczby" paczki lokalnej.
Spełnienie łącznie powyższych warunków oznacza, że wbrew ostrzeżeniu (ważny jest ppkt. b), paczka w repozytorium jest nowsza niż lokalna.
Dokonujemy instalacji tej paczki:
pacman -Syu paczka
4. Repozytoria AntergosaTu już sobie sami mocno rozważcie. Osobiście uważam, że lepszym rozwiązaniem jest ich przeniesienie na koniec listy repozytoriów udostępnionych w /etc/pacman.conf. Twierdzę tak dlatego, że niekiedy twórcy Antergosa nie nadążają z aktualizacjami swoich paczek względem paczek w Archu. Stosując się do tej porady dalej będziecie mieć dostępne paczki (tam ich jest 5 na krzyż) z Antergosa, ale bez kłopotów z aktualizacją całego systemu z Archa. Jeśli takie kłopoty wówczas napotkacie, to diagnoza gdzie szukać jest prosta.
Bezwzględnie to zalecam, jeśli Antergosowi udostępniliście repozytoria testowe Archa.