Co naprawdę oznacza, że pacman (Arch) nie wspiera częściowej aktualizacji

Pośród osób pracujących na Arch Linux jak mantra powtarzane jest twierdzenie: pacman (Arch) nie wspiera częściowej aktualizacji. Co w istocie to oznacza? Jakie są najczęściej popełniane błędy?

1. Synchronizacja repozytoriów dla zabawy
Zdarzyło się Wam wydać polecenie pacman -Sy bądź pacman -Syy, a za jakiś czas instalować program poprzez pacman -S? Jeśli nie, to jak dowodzą świadectwa innych użytkowników tu i ówdzie rozsiane po internecie praktyka ta wcale nie jest tak rzadka. Zobaczmy zatem co się dzieje w takich przypadkach i do czego to prowadzi.
Pierwsze polecenie dokona synchronizacji informacji o dostępnych paczkach (w tym ich wersjach) w repozytoriach z informacjami lokalnie przechowywanymi w bazie pacmana. Nie jest dokonywana żadna aktualizacja systemu. Następne polecenie oczywiście zainstaluje paczkę. Paczkę w takiej wersji, jaka jest w danym momencie w repozytorium.
Zwróćmy teraz uwagę na to w jaki sposób budowane są paczki w repozytoriach Archa oraz jakie informacje przekazywane są pacmanowi.
Otóż zakładając, że paczki w repozytoriach budowane są prawidłowo, a nie mamy żadnej podstawy twierdzić inaczej, to w danym momencie, w repozytorium, które jest w 100% zsynchronizowane z głównym repozytorium Archa są paczki, które zostały zbudowane na podstawie swoich zależności, które są wymagane do poprawnej ich  pracy. Z drugiej strony paczki - jeśli to nie jest bezwzględnie wymagane - nie zawierają informacji o tym w jakiej wersji ma być jakaś paczka, od której są zależne. Taka informacja nie jest też przekazywana pacmanowi w żaden sposób.
Jeśli zatem wykonamy czynności, jakie opisałem na wstępie, to może się zdarzyć, że zostanie zainstalowana paczka w wersji, która wymaga swojej zależności również w określonej wersji. Jeśli owa zależność w systemie będzie już zainstalowana, to nie zostanie zaktualizowana. Efekt łatwy do przewidzenia - system będzie działać wadliwie.

Prawidłowo zatem w każdym przypadku:

pacman -Syu

2. Instalacja paczki bez aktualizacji systemu
Przeczytawszy poprzedni punkt już chyba wszystko wiadomo - instalacja paczki poprzez:

pacman -S paczka

nie ma żadnego sensu. Albo operacja taka się nie uda, albo wywoła skutek jak poprzednio, czyli dopuścimy się częściowej, a niewspieranej, aktualizacji systemu przy okazji instalacji jakiejś paczki. Oczywiście w niektórych przypadkach może się zdarzyć, że wszystko przebiegnie prawidłowo. To jednak przypadek.
Zasadniczo w opisany wyżej sposób można instalować paczkę, jeśli jesteśmy pewni, że od ostatniej synchronizacji baz pacmana z repozytorium oraz aktualizacji systemu w repozytoriach nie pojawiły się nowe wersje paczek, które mamy już zainstalowane w systemie. Zdecydowanie lepszym sposobem, a już zawsze, gdy dość dawno nie dokonywaliśmy aktualizacji systemu jest:

pacman -Syu paczka

3. Aktualna lista serwerów źródłowych
No właśnie, pacman wypisuje różne komunikaty, a bardzo często pozostają one bez żadnej reakcji. Zadowalamy się, że "aktualizacja się powiodła". W zakresie opisywanym jeden z częściej popełnianych błędów jest związany z aktualizowaniem paczki pacman-mirrorlist. Ta paczka jest dość często aktualizowana i przynosi ze sobą wyłącznie jeden plik mirrolist, który zawiera aktualną na dzień wydania listę serwerów źródlanych Archa. Jeśli jednak w systemie istnieje już plik /etc/pacman.d/mirrorlist, to aktualizacja tej paczki powoduje jedynie wgranie do tej lokalizacji nowej listy, ale pod nazwą mirrorlist.pacnew, który to plik oczywiście nie jest "czytany" przez pacman podczas aktualizacji systemu. Jeśli zatem nie dokonamy zmiany nazwy tego pliku na mirrorlist to system nadal będzie się "aktualizował" z serwerów źródlanych, które mogą nie być już aktualne. Pamiętajmy przy tym, że pacman "czyta" listę udostępnionych mu serwerów w kolejności wskazanej w pliku /etc/pacman.d/mirrorlist i po nawiązaniu udanego połączenia z pierwszym serwerem z listy "zadowala się" nim i to z niego następuje aktualizacja, nawet jeśli serwery umieszczone poniżej są aktualniejsze.
Pamiętajmy również, że sama zmiana nazwy mirrorlist.pacnew na mirrorlist nic nie da albowiem wszelkie serwery na tej liście są zakomentowane. Musimy usunąć znak "#" sprzed nazwy Server.
Osobiście dla odnawiania listy serwerów stosuję jednak program reflector z taką listą poleceń:

reflector --verbose --latest 5 --sort rate --save /etc/pacman.d/mirrorlist

W ten sposób dostarczanych mi jest do systemu pięć najświeższych serwerów posegregowanych od tego, który spośród nich oferuje najszybszy transfer do najwolniejszego. Oczywiście można sobie zrobić dla takiej komendy jakiś alias, bo będzie wygodniej.
Oczywiście to nie jedyne sposoby, gdyż z pierwszej strony Archa w sekcji Tools możemy znaleźć przydatne narzędzia do sprawdzania i generowania listy serwerów, a nadto są inne jeszcze narzędzia od reflectora.

4. Bezsensowne ignorowanie aktualizacji paczek
Dość częstą praktyką jest dodawanie do pacman.conf jakichś paczek, bo nam się wydaje, że lepiej będzie tak działać. Oczywiście, że można, ba nawet niekiedy trzeba, ale... Zwróćmy uwagę na to jak są budowane paczki w Archu. W danym momencie, w repozytorium winny znajdować się paczki, które umożliwiają poprawną pracę w tym systemie. Oznacza to m.in., że te, które ze względu na jakieś swoje zależności wymagają przebudowania, zostały przebudowane po wprowadzeniu do repozytoriów nowej wersji swej zależności. Jeśli zatem z jakiegoś powodu do IgnorePkg dodamy którąkolwiek z tych paczek, to jesteśmy na dobrej drodze do spowodowania, że system będzie działać wadliwie. Jeśli zatem już umieszczamy coś w IgnorePkg to róbmy to z głową i na pewno nie umieszczajmy tu niczego ze względu na jakąś paczkę budowaną z AUR. To paczka z AUR ma być dostosowana do paczek systemowych, a nie odwrotnie.

Krótko mówiąc - można wszystko, ale róbmy to z głową.