Dobre praktyki i błędy w zarządzaniu pakietami

Jesteś nowy na forum? Przeczytaj ...

Home Fora Forum wsparcia Podstawy Dobre praktyki i błędy w zarządzaniu pakietami

Ten wątek zawiera 4 odpowiedzi, ma 2 uczestników, ostatnio zmodyfikowany przez azja azja 4 tygodni temu.

Oglądasz 5 posty - 1 do 5 (z 5 ogółem)
  • Autor
    Posty
  • #8547
    azja
    azja
    Moderator

    kolega @pavbaranov, popełnił u Siebie text, który warto przeczytać:
    https://linux-pavbaranov.blogspot.com/2018/11/co-na-prawde-oznacza-ze-pacman-arch-nie.html
    Odnosi się w nim do błędów popełnianych w trakcie używania pacman’a, a dokładniej, tematu częściowej aktualizacji. Zapewne błędów powszechnych, bo jesteśmy leniwi i skłonni do chodzenia na skróty. Dlatego ja wykorzystuję skrypty, uruchamiane jednym, leniwym poleceniem.

    generalnie rzecz biorąc, zgadzam się z opiniami @pavbaranov, bo trudno inaczej. Dołożę jednak kilka uwag, biorących się z mojego doświadczenia i specyfiki Manjaro (@pavbaranov pisze o Arch’u):

    ad.1. SYNCHRONIZACJA REPOZYTORIÓW DLA ZABAWY
    Jeżeli aktualizujesz repozytoria, to aktualizuj również system (pakiety):
    $ pacman -Syu
    Chociaż ja wolę:
    $ pacman -Syyu
    W przypadku pamac’a w Manjaro, idzie to tak:
    $ pamac update --force-refresh --aur
    co sprowadza się do wymuszenia odświeżenia bazy, aktualizacji systemu i AUR.

    ad.2. INSTALACJA PACZKI BEZ AKTUALIZACJI SYSTEMU
    Jeżeli instalujesz jakąś paczkę, to wcześniej/równocześnie zaktualizuj system:
    $ pacman -Syu nazwa_pakietu
    Oczywiście, j.w., ja dołożyłbym drugie ‚y’. Chcąc użyć pamac’a:
    $ pamac update --force-refresh --aur && pamac install nazwa_pakietu
    czyli odświeżenie bazy, aktualizacja i instalacja pakietu. Dokładam do tego, po instalacji, sprawdzenie dostępnych aktualizacji (wszystko idzie ze skryptu, więc jedna komenda więcej nie robi różnicy, a mam dodatkowy element kontrolny):
    $ pamac checkupdates -aur && pamac list --orphans
    co znaczy tyle, że mam informacje nt. dostępnych aktualizacji (z AUR włącznie) i ewentualną listę osieroconych pakietów (konfigurację mam taką, że paczki, których nikt nie potrzebuje, są odinstalowywane, ale może zdarzyć się tak, że wskutek jakichś niepowodzeń, coś zostanie).

    ad.3. AKTUALNA LISTA SERWERÓW ŹRÓDŁOWYCH
    Zanim zaktualizujesz system lub zainstalujesz nowy pakiet, to zaktualizuj listę mirror’ów. W Arch’u trzeba wykonać kilka operacji lub zainstalować jedno z dostępnych narzędzi. W Manjaro jest łatwiej, bo narzędzie przychodzi z systemem: pacman-mirrors. Ja używam polecenia, które bierze konfigurację z pliku /etc/pacman-mirrors.conf, ale odpowiada to, z grubsza komendzie:
    $ sudo pacman-mirrors --country Germany,France --protocols https --method rank --set-branch stable --api
    a więc aktualizacja listy mirrorów z ograniczeniem do konkretnych krajów i protokołów, wg czasu dostępu.

    ad.4. BEZSENSOWNE IGNOROWANIE AKTUALIZACJI PACZEK
    Ostrożnie podchodźmy do wpisywania pakietów na listę ignorowanych, zgodnie z zasadą ‚wszystko dla ludzi, byle z umiarem’ lub ‚nie ma problemu, jeżeli wiesz co robisz’. Arch czy Manjaro – bez różnicy, zalecana świadomość.

    podsumowując, jeżeli chcemy zainstalować nowy pakiet, to:

    
    $ sudo pacman-mirrors --country Germany,France --protocols https --method rank --set-branch stable --api
    $ pamac update --force-refresh --aur
    $ pamac install nazwa_pakietu
     

    a chcąc aktualizować system:

    
    $ sudo pacman-mirrors --country Germany,France --protocols https --method rank --set-branch stable --api
    $ pamac update --force-refresh --aur
    $ pamac checkupdates -aur
    $ pamac list --orphans
     

    wszystko to pakuję w skrypty, aby nie przeciążać zmęczonej głowy i wyeliminować głupie błędy spowodowane literówkami, czy chwilowym roztargnieniem. Przeczytajcie text @pavbaranov i moje uwagi, dotyczące specyfiki Manjaro i podzielcie się swoimi opiniami i praktykami dotyczącymi zarządzania pakietami.

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

    #8550

    pavbaranov
    Forumowicz

    Thx za reklamę :)
    A poważnie, to nie tyle uwagi, co pytanie. Jak piszesz, preferujesz:
    pacman -Syy
    nad
    pacman -Sy
    (mniejsza o to co po ostatnim „y”). Dlaczego? Różnica między „y”, a „yy” jest taka, że w pierwszym przypadku dochodzi do pobrania świeżych (tj. „nowszych” niż te, które już naszemu systemowi są już udostępnione) baz danych pakietów z serwera, podczas, gdy w drugim dokonywane jest pobranie baz nawet jeśli nasze, lokalne, są aktualne. Pacman ma wbudowany system, który umożliwia weryfikację, czy baz odległych i lokalnych pod kątem ich aktualności. Preferowane przez Ciebie polecenie powoduje zatem – wg mnie – wyłącznie niepotrzebny ruch sieciowy i dodatkowe obciążenie serwerów, z których korzystamy, podczas gdy efekt dla naszego systemu jest taki sam.
    Bez żadnych podtekstów i broń boże nie czepiając się, chciałbym się dowiedzieć co przemawia do Ciebie, by wybrać owe podwójne „y” w miejsce pojedynczego.
    (Bo kiedy w istocie należy wymusić aktualizację nawet aktualnych baz, to myślę, że wiem).

    #8553
    azja
    azja
    Moderator

    @pavbaranov -> bierze się, to z ogólnego podejścia do rzeczywistości. Można powiedzieć, że ‚yy’ jest emanacją mojego światopoglądu. Jako przedstawiciel gatunku z gruntu głupiego (bo za taki uważam Homo sapiens), również samego siebie nie traktuję jako zbyt mądrego. Sprytny, zaradny, bogaty w mądrość życiową – tak; mądry, w głębokim sensie tego słowa – nie. Dlatego staram się przewidywać i zapobiegać brakom swojej mądrości, niedoskonałościom postrzegania, lenistwu, etc. – tworzę obronę drugiej linii (jako pierwsza jest świadomość), którą budują takie elementy jak pasy bezpieczeństwa czy kask rowerowy, nawyki, procedury postępowania, skrypty, itp. Podwójne ‚y’ nie szkodzi. Zapewne w 99% przypadków nie pomaga. Ale niewielkim kosztem (ciut większy transfer i odrobinę więcej czasu – dwa razy w miesiącu, średnio) zabezpieczam się na ten 1%.

    zdarzyło Ci się, że w trakcie upgrade’u systemu komp zwisł lub stracił zasilanie? Niemożliwe, niezwykle rzadkie? Mnie dwa razy – raz mi się upiekło, a raz miałem poważne problemy. Wcześniej zastanawiałem się nad taką sytuacją, ale nie miałem pomysłu na to, co może się zdarzyć i jak można temu zaradzić. Gdy już zdarzyło się, to rozpoznałem temat i zmieniłem odrobinę nawyki, aby następnym razem przejść chorobę szybciej i z mniejszą temperaturą. Gdybym znał sposób na zmniejszenie prawdopodobieństwa / uniknięcie tego typu sytuacji, to wdrożyłbym go wcześniej i zapomniał (delegował skryptom lub palcom). Dlatego używam ‚yy’. Nie pokładam w tym wielkich nadziei – ot, drobny element większej całości. Nie forsuję również tego rozwiązania, ale jeżeli ktoś pyta, albo sam odzywam się na ten temat, to zaznaczam, że JA używam ‚yy’.

    skoro już jesteśmy w pobliżu i wspomniałeś o tym, to napisz kiedy należałoby ewidentnie wymusić aktualizację baz.

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

    #8556

    pavbaranov
    Forumowicz

    Oczywiście, że – z punktu widzenia użytkownika, owe „yy” nie powoduje niczego złego. Zwróć jednak uwagę, że pobranie czegoś z serwera powoduje jego obciążenie. W przypadku takiej „praktyki”, gdy dosięgnie ona wszystkich użytkowników danego systemu, to jego obciążenie będzie znaczne. Oczywiście można to mieć gdzieś ze swojego, egoistycznego (nie w pejoratywnym znaczeniu) punktu widzenia. Niemniej jednak – przynajmniej ja wychodzę z takiego założenia – szanujmy tych, którzy nam coś dają. W tym przypadku udostępniają swój serwer dla naszej wygody i przyjemności.
    Zwłaszcza, że owe „yy” absolutnie nic nie daje (przynajmniej nie wytłumaczyłeś w swoim wpisie od jakiegoż to voodoo może uchronić Twój system) w codziennym użytkowaniu. Jeśli to ma być panaceum na utratę zasilania (nie, nie zdarzyło mi się) bądź zawieszenie komputera (Arch mi się nie zawiesił, wcześniejsze systemy? bodaj zdarzyło mi się to w Debianie i Kubuntu), to raczej nie tędy droga, a i rozwiązanie wówczas bywa doraźne (i pewnie nie tylko polegające na wymuszonej aktualizacji nawet aktualnej bazy).

    Kiedy natomiast stosować? Ja znalazłem taki w zasadzie jeden przypadek – gdy nasza baza w jakiś sposób jest uszkodzona (o potrzebie i tak się dowiemy, wówczas wymusimy).

    #8557
    azja
    azja
    Moderator

    # OBCIĄŻENIE. Przyznam, że nie zastanawiałem się wcześniej nad tym problemem – dopiero wczoraj, gdy o tym napisałeś, to pomyślałem, że fakt, zwiększa, to obciążenie server’ów. Miałem, rzecz jasna, tego świadomość – ale nie przyszło mi do głowy traktować tego jako coś problematycznego. Jestem gościem, który minimalizuje transfer, a masowe oglądanie telewizji czy filmów przy użyciu internetu, traktuję jak cywilizacyjną perwersję (uważam, że jest to użycie dostępnych środków technicznych, dalekie od optymalnego). Dlatego drobne zwiększenie przesyłu danych nie jest dla mnie niczym niestosownym. Drobne, bo wykonuję, to dwa razy w miesiącu, wtedy gdy aktualizuję system – nie robię tego wtedy, gdy sprawdzam dostępność aktualizacji, a instalacje nowych aplikacji, to obecnie margines (raczej odinstalowuję te, które przetestowałem i okazało się, że nie spełniają moich oczekiwań). Jest jeszcze jeden powód, marginalizujący problem – robię tak tylko na swojej głównej maszynie, a rezerwowa i instalacje ‚zaprzyjaźnione’ wykorzystują standardowe mechanizmy graficzne, tak aby użytkownicy nie nabywali zbyt ‚egzotycznych’ nawyków, bo jeżeli mnie zabraknie, to będą musieli poradzić sobie sami.

    # POWÓD. Raz, w trakcie upgrade’u, wystąpiła utrata zasilania (zewnętrza awaria) i raz zawieszenie systemu (podejrzewam sprzęt) – nie, ‚yy’ nie ma mnie chronić przed tego typu problemami. Choć może się zdarzyć, że w wyniku tego rodzaju perturbacji może wystąpić uszkodzenie bazy. Więc dlaczego? Dlatego, że chcę cały proces przeprowadzić możliwie jak najbardziej koszernie: aktualne mirrory, aktualna baza, aktualne pakiety. Nie dlatego, że jestem bojaźliwy, czy nadmiernie ostrożny, tylko wręcz odwrotnie – zazwyczaj niezbyt agresywnie, ale jednak systematycznie experymentuję z systemem i staram się ograniczyć zbędne ryzyko. Porównując, to do jazdy samochodem: jeżdżę dynamicznie, przekraczam dozwoloną prędkość, agresywnie wyprzedzam, omijam wysepki z lewej, ale zapinam pasy, zachowuję właściwą postawę, dbam o stan płynów w wozie, pilnuję odpowiedniego ciśnienia w oponach, nie przekraczam podwójnej ciągłej, nie ścinam zakrętów bez widoczności.

    # Zapewne nie zmienię postępowania, bo przemyślałem sprawę i nie widzę ku temu powodów (póki co), ale dzięki za spojrzenie z innej strony i zwrócenie na to uwagi. Poza tym, nasza interesująca wymiana zdań, może być czysto akademicka – zakładając, że mówimy o Manjaro i wykorzystaniu pamac’a. Łaj? Bikoz pamac, gdy sprawdzamy dostępność aktualizacji (ręcznie lub auto), to ściąga na swoje potrzeby aktualne pliki *.db do lokalizacji /tmp/pamac/dbs-mnjr/sync/, podobnie czyni komenda $ pamac checkupdates (tyle, że ściąga również *.files), jak i komenda $ checkupdates (do lokalizacji /tmp/checkup-db-mnjr/sync/). Tak więc, moje potencjalne oszczędności nijak się mają do ruchu standardowo generowanego przez systemowe, standardowe narzędzia.

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

Oglądasz 5 posty - 1 do 5 (z 5 ogółem)

Musisz być zalogowany aby odpowiedzieć w tym wątku.