[SOLVED] Aktualizacja – luźne pytanie

[pavbaranov]

@Ulther – to rozwiązanie nieco na wyrost, albowiem @wiini nie wskazuje na istnienie jakiegokolwiek błędu przy aktualizacji, a jedynie na to, że aktualizacja na jednym z komputerów nie jest dostępna (innymi słowy pacman -Syu nic nie zwraca). Wprawdzie proponowane przez Ciebie rozwiązanie nie jest inwazyjne i nie powinno spowodować niczego oprócz odnowienia kluczy w systemie, jednakże dobra zasada współpracy ze swoim systemem jest taka, by nie dokonywać w nim niepotrzebnych zmian, czy ingerencji.

[azja]

… skłonny jestem przychylić się do pavbaranov, zgodnie z zasadą, że nie należy mnożyć bytów ponad potrzebę, ale krok zaproponowany przez Ulther wydaje się być sensownym, w sytuacji gdy poprzednie zalecane działania nie przynoszą skutku.

Swoją drogą (a propos linku) wrzuciłem gotową receptę do swojego prywatnego help’a – może kiedyś trzeba będzie ją zastosować, a po co szukać w internetach. Rzuciło mi się w oczy, Panowie, że w pierwszej, bardziej zachowawczej części, kolejność jest następująca:

sudo pacman-key --refresh-keys
sudo pacman-key --populate archlinux manjaro

a w drugiej, bardziej agresywnej:

sudo pacman-key --populate archlinux manjaro
sudo pacman-key --refresh-keys

Ciekawe czy, a jeżeli tak, to jakie ma, to znaczenie. Należałoby się pewnie wgryźć w operacje, jakie poszczególne komendy wykonują i poskładać ich logikę. Ale, to takie niewinne OT.

Nie zadawaj pytania, jeżeli nie jesteś gotów usłyszeć odpowiedzi

[pavbaranov]

azja napisał(a):

Ciekawe czy, a jeżeli tak, to jakie ma, to znaczenie.

To jest normalna kolej rzeczy.
Pierwsza kolejność: aktualizujesz klucze z serwera (–refresh-keys), a następnie odświeżasz lokalną ich bazę (–populate).
Druga kolejność: tu kluczem jest usunięcie dotychczasowej bazy z systemu (rm) i ich całkowita instalacja od nowa (pacman -Sy XYZ); skoro tak, to najpierw musisz bazę zainicjować (–init), odświeżyć (–populate) i… w zasadzie nie wiadomo już po co aktualizacja kluczy z serwera (–refresh-keys).
Tak, czy inaczej problem, na który powyższe jest remedium, przejawia się tym, że pacman widzi aktualizacje, ale nie może ich zainstalować, albowiem klucze gpg mu się nie zgadzają, natomiast w omawianym przypadku pacman nie widzi możliwości aktualizacji.

Swoją drogą, to w tym poradniku jest jeden błąd, otóż nie:
pacman -Sy nazwa_paczki
ale
pacman -Syu nazwa_paczki
Pierwsze rozwiązanie (choć nie powinno występować akurat z tymi paczkami, które w tutorialu), gdy wejdzie w krew może, ale nie musi, zrobić w systemie „kuku”, najczęściej objawiające się niedziałającym programem.

[azja]

pavbaranov –>
… 'nie wiadomo już po co aktualizacja kluczy z serwera’ jest odpowiedzią na moje wątpliwości.
————-
EDIT: może i ma, to sens, bo sprawdza drożność mechanizmu aktualizacji kluczy.
————-
… myślę, że 'błąd’ wynika (spekuluję) z założenia, że problem dotyczy tych paczek i tylko tych paczek, a reszta jest OK, więc nie musimy ich sprawdzać. Fakt, że założenie ryzykowne, bo jeżeli okaże się, że mamy 'rozsynchronizowany’ system, to takim poleceniem (bez full upgrade) możemy go dobić.

Nie zadawaj pytania, jeżeli nie jesteś gotów usłyszeć odpowiedzi

[pavbaranov]

azja napisał(a):

‚błąd’ wynika (spekuluję) z założenia, że problem dotyczy tych paczek i tylko tych paczek

Myślę, że jednak z pewnych przyzwyczajeń. Jakoś przyzwyczailiśmy się, że instalujemy paczkę jakimś poleceniem, chcemy mieć najnowszą to aktualizujemy repozytoria i…
I to się nazywa debianowe/ubuntowe/itd/itp podejście. Tam inaczej są paczki budowane i inaczej mają podawane zależności od, tego co w systemach RR jest zwyczajem, a już w szczególności Archa i pochodnych. Tutaj w krew nam winno wejść, że jakiekolwiek zmiany w zainstalowanych programach robimy po pełnej aktualizacji systemu (lub wraz z nią). PKGBUILDy niezmiernie rzadko i wyłącznie wówczas, gdy jest to absolutnie niezbędne, zawierają deklaracje wersji paczek zależnych. Tutaj paczka nazywa się paczka, a nie paczka_1.12. Zależnością jest „paczka”, nie „paczka_1.12”, albowiem ta ostatnia będzie… inną paczką (ostatnio wychodzi to przy openssl). Paczki są budowane – zasadniczo – na podstawie tych paczek (z tymi zależnościami), które są w repozytorium stabilnym… Archa (oprócz tych, które są budowane przez Manjaro; o zmianach w paczkach Archa niemalże zapomnijmy). Dodatkowo jest takie repozytorium w Archu jak staging, które odpowiada za „hibernację” pewnych paczek do czasu przebudowania innych, które są w jakiejś zależności z nimi. Nv.
Efekt jest taki, że jeśli wydamy polecenie:
pacman -S paczka
bądź
pacman -Sy paczka
to przy nieszczęśliwym zbiegu przypadków możemy spotkać się z taką sytuacją, w której „paczka” nie będzie wymagać jakichś zależności, albowiem pacman odnajdzie je jako już zainstalowane w systemie. Pobierze natomiast i zainstaluje ową „paczkę”. Jeśli „paczka” została zbudowana na podstawie jakiejś paczki zależnej w innej wersji od tej, która znajduje się już w systemie, to coś może nie zadziałać. To właśnie przez założenie, że Arch (ogólnie RR) ma być zawsze aktualne oraz wymagania (a raczej ich brak) w PKGBUILDzie deklarowania minimalnych (i maksymalnych niekiedy) wersji kompatybilnych z nimi paczek zależnych. Założenie jest takie, że zaktualizowany system ma obowiązek działać (choć oczywiście bywają wyjątki).
Wydanie natomiast polecenia:
pacman -Syu paczka
na pewno dokona aktualizacji wszystkich paczek znajdujących się lokalnie w naszym systemie, a nadto instalację paczki „paczka”. Mamy zatem pewność, że „paczka” została przeznaczona (i zbudowana) na podstawie tych samych wersji paczek, które mamy w systemie i tych właśnie, a nie innych wymaga.

I sorry, za OT.

[wiini]

azja napisał(a):

sudo pacman-mirrors -g
sudo pacman -Syyu

Może nie zawsze trzeba, ale nigdy nie powinno zaszkodzić, a zdecydowanie polecam ich wykonanie w takich niejasnych sytuacjach, jaką ma wiini. Swoją drogą, wiini daj znać jak poszło.

Przecież obie te komendy wykonałem o czym napisałem we wcześniejszych postach, zatem nie ma o czym dawać znać ( chociaż nic nie stoi na przeszkodzie aby napisać, że nie zadziałało ).
Obecnie jestem w pracy, ale jak wrócę to sprawdzę listę mirrorów wg sugestii pavbaranov i dam znać .
Dziękuję za wszelkie pomocne uwagi.
pozdrawiam

[azja]

pavbaranov –>
… OT jest jak najbardziej w temacie, bo cały czas krążymy wokół potencjalnych przyczyn braku aktualizacji na komp’ie wiini.
Ja ewoluowałem, dostosowując swoje zachowanie do aktualnego stanu wiedzy. Zacząłem od narzędzi graficznych (wyłącznie), a skończę zapewne na takim etapie, na jakim jestem obecnie – mix pacman/pamac. Pamac jest, moim zdaniem, bardzo dobrym narzędziem, oferującym podstawowy zakres funkcjonalności pacman’a w ergonomicznej (prawie, bo bez myszy nie ujedziesz daleko)
————-
EDIT: przed chwilą sprawdziłem i widzę postępy, w porównaniu do stanu sprzed paru miesięcy – da radę, całkiem nieźle, nawigować po programie przy użyciu klawiatury.
————-
i elastycznej formie. Pacman, z kolei, daje pełne spektrum możliwości, również te, których nie ma Pamac. Poszczególne pakiety (z oficjalnych repo i AUR) przeglądam/instaluję/deinstaluję za pomocą Pamac’a (po uprzednim wykonaniu funkcji 'Odśwież bazy danych’), a full update i parę innych przydatnych operacji, przy użyciu Pacman’a.
… obecnie, pomijając elementy estetyczno-porządkujące, cała operacja sprowadza się do:

sudo pacman-mirrors -g
sudo pacman -Syyu
tac /var/log/pacman.log | sed -n '/full system upgrade/q;s/.*\[ALPM\] upgraded //p'
sudo pacman-optimize
sudo bleachbit --preview system.localizations

Po dzisiejszej dyskusji, zacząłem zastanawiać się, czy nie dołączyć do tej procedury, na początku:

sudo pacman -Syy
sudo pacman-key --refresh-keys
sudo pacman-key --populate archlinux manjaro

wiini –>
… a propos 'napisałem we wcześniejszych postach’ … czasem trudno zachować spójność wątku, w ferworze codziennej walki, szczególnie, że nie wszystkie komunikaty, są jednoznaczne w treści (forum, to dynamiczna i improwizowana forma wymiany myśli). Nie zaszkodzi zwrócić uwagi, w stylu 'jak już wspominałem’ albo 'jak wyżej’, ale napinka jest zbędna. Dzięki za info, że nie zadziałało. Oprócz porównania mirror’ów, sprawdź również dwa pozostałe pliki konfiguracyjne (patrz: wcześniejszy post), pod kątem różnic. Jeżeli niczego nie znajdziesz, to warto, moim zdaniem, przetestować trop podsunięty przez Ulther.
… no i, zgodnie z zasadą, że urządzenie elektryczne podłączone do prądu działa znacznie lepiej, warto zainteresować się drożnością połączenia – zarówno od strony fizycznej, jak i software’owej – może nie ściąga aktualizacji, bo ich nie widzi, a to, że precyzyjnie nie informuje o problemie, to nic szczególnego – obsługa błędów jest na tyle doskonała, na ile szeroka jest wyobraźnia programisty.
… warto również ograniczyć ilość krajów, w których szuka mirror’ów, np.:

/etc/pacman-mirrors.conf
--------------------------------------
OnlyCountry = Poland,Germany,France

Nie zadawaj pytania, jeżeli nie jesteś gotów usłyszeć odpowiedzi

[wiini]

azja – absolutnie nie taki był mój zamiar pisząc tekst o tym, że już wykonałem oba polecenia. Przepraszam jeśli źle to zabrzmiało.
panbaranov – zadziałała zmiana pierwszego serwera, w komputerze w którym nie widział aktualizacji był serwer w Belgii, natomiast w komputerze z aktualizacją serwer w Holandii. Zmieniłem na Holenderski i właśnie się aktualizuje. Wielkie dziękuję.

pozdrawiam

[azja]

… spoko, to tylko luźna uwaga była.
Zdecydowanie polecam ograniczyć wybór do mirror’ów niemieckich i francuskich. Ani razu, przez blisko dwa lata, nie zawiodłem się na nich.

Nie zadawaj pytania, jeżeli nie jesteś gotów usłyszeć odpowiedzi

[Autor]

Posty