AUR - odpowiedzialność zbiorowa, czy jednostkowa?

[MSki]

Off-top wydzielony  z  tematu "No właśnie, który?"

Ja się nie znam, ale się wypowiem   :)
Jedną z cenniejszych informacji, jakie @pavbaranov zawarłeś w powyższym wpisie, jest sposób partycjonowania dysku - raczej nie "z automatu", a przeważnie "ręcznie".
Chociaż, jak na /home jeszcze nic nie ma, to można to zrobić "z automatu", bo przy kolejnej próbie instalacji kolejnego systemu można przez nieuwagę usunąć to co mamy na /home. I jest to też sposób na w miarę proste i "bezmyślne" postawienie TYLKO jednego systemu.

Nie mogę się natomiast zgodzić co do wyboru dystrybucji - wydawniczy vs semi-rolling vs rolling.
Na przykład, w przypadku Fedory, gdzie jej okres wydawniczy (kolejnych wersji) przypada dwa razy w ciągu roku, jest najnieszczęśliwszym rozwiązaniem z uwagi na to, że przejście z wcześniejszej wersji na kolejną, może wiązać się z problemami. Bo to, że deweloperzy zapewniają, że proces ten odbędzie się "bezboleśnie" dla użytkownika, wcale nie jest regułą.
Sadzę, że najbliższe ideałowi są jednak dystrybucje rolling, a zwłaszcza Arch, w którym na bieżąco jest aktualizowany cały system.
Wyłączenie procesu aktualizacji jest olbrzymim błędem użytkownika, z uwagi na to, że aktualizacji podlegają również pakiety odpowiadające za bezpieczeństwo systemu.
Czy zmiana kernela na wyższą wersję może wiązać się z "wyłożeniem się" systemu ? - może, ale ja nie potwierdzam tych rewelacji  ;)
Po instalacji Manjaro, aktualizacji systemu i informacji, że jest nowsza wersja kernela dokonałem tej zamiany.. świadomie usuwając wersję starszą (LTS) - system uruchomił się bez żadnych problemów i z kernelem 5.5.7-1. Nic nie miałem (oprócz czasu) do stracenia, dlatego poszedłem "na żywioł".

Czy instalowanie paczek, ich budowanie z AUR, PPA jest bezpieczne ? - z PPA nie korzystałem, bo wszystkie potrzebne programy/pakiety znajdywałem w Synaptic'u.
W Manjaro i za pomocą Pamac'a system zbudował mi Stecer'a, którego lubię używać. Pod koniec budowy tego pakietu, system przeprowadził "testy zgodności", włączył zaczepy pooperacyjne.. i poinformował mnie, że instalacja pakietu zakończyła się powodzeniem.
Jeśli zatem Stacer stał się jednym z programów użytkowych, to chyba system (a nie użytkownik) bierze na siebie odpowiedzialność jego aktualizacji.. tym bardziej, że w Archu i pochodnych tej dystrybucji, aktualizowany jest cały system (tak zrozumiałem), a nie "jakiś" pakiet/program, który tej aktualizacji potrzebuje.

[pavbaranov]

Na przykład, w przypadku Fedory, gdzie jej okres wydawniczy (kolejnych wersji) przypada dwa razy w ciągu roku, jest najnieszczęśliwszym rozwiązaniem z uwagi na to, że przejście z wcześniejszej wersji na kolejną, może wiązać się z problemami. Bo to, że deweloperzy zapewniają, że proces ten odbędzie się "bezboleśnie" dla użytkownika, wcale nie jest regułą.

Niemniej jednak nie jest regułą, że aktualizacja do nowszego wydania rozwali coś. Fakt - bywa z tym problem. Względną alternatywą jest jakaś dystrybucja LTS. Tu aktualizację do nowszego wydania zrobi się niekiedy za taki czas, że komputer już będzie do wymiany :)

Sadzę, że najbliższe ideałowi są jednak dystrybucje rolling, a zwłaszcza Arch, w którym na bieżąco jest aktualizowany cały system.

I tu mamy "zonk". Mając za plecami kilkanaście lat na linuksie i wiedząc to co wiem, to do wyboru dystrybucji podszedłbym inaczej. No, ale ów "zonk" - na początku nie potrafi się użytkownik określić czego chce i co wymaga, albowiem po prostu są mu to rzeczy nieznane. Niemniej jednak, jeśli ktoś ma sporo zapału, chce choć trochę poznać system, wiedzieć jak on funkcjonuje (i dobrze byłoby choć w części wiedzieć dlaczego tak, a nie inaczej), to można się rzucać na Archa. Pewnie dzisiaj w ciemno bym go wybrał i pewnie byłbym zadowolony (zwłaszcza, że nie miałbym początkowych "narzutów" z debianowatych, czy nawet z rpmów). Z drugiej strony mamy jednak na forum użytkownika tego typu rozwiązań, który po prostu nie wie kompletnie co czyni, a jednocześnie twierdzi, że tak należy i jeszcze to proponuje innym, dodatkowo popierając to kilkuletnim, swoim,  doświadczeniem użytkownika linuksa. Dla kogoś, kto startuje, tego typu rozwiązania będą jak "objawienie", a postępując zgodnie z nimi - prędzej, czy później - rozwali sobie system i będzie twierdzić, że Arch/PArch/LArch :) czy inna cholera, to jest do d... system i on ma tego dość.

Wyłączenie procesu aktualizacji jest olbrzymim błędem użytkownika, z uwagi na to, że aktualizacji podlegają również pakiety odpowiadające za bezpieczeństwo systemu.

Absolutnie tak, ale jeśli chodzi o dystrybucje oparte o pacmana to ma znaczenie z jeszcze innego powodu i jest związane ze sposobem paczkowania, a przede wszystkim jest pochodną utrwalonego sposobu pisania PKGBUILDów i przyjęcia sobie zasady: "pacman nie wspiera częściowej aktualizacji". O tym nasz forumowy kolega chyba w ogóle jeszcze nie wie.

Jeśli zatem Stacer stał się jednym z programów użytkowych, to chyba system (a nie użytkownik) bierze na siebie odpowiedzialność jego aktualizacji.. tym bardziej, że w Archu i pochodnych tej dystrybucji, aktualizowany jest cały system (tak zrozumiałem), a nie "jakiś" pakiet/program, który tej aktualizacji potrzebuje.

No właśnie. Wprowadzenie paczki z AUR powoduje, że to Ty bierzesz odpowiedzialność za to, że przynajmniej ów program będzie działać (i pół biedy, jeśli to jest jakiś "końcowy" program, a nie coś, co jest jakąś zależnością, na której opiera się coś innego itd.). Teoretycznie opiekun takiego PKGBUILDu w AUR winien sprawę "kontrolować" i dokonywać odpowiednich w nim zmian jeśli zajdzie taka potrzeba. To jednakże teoria, a praktyka wskazuje, że niekoniecznie tak bywa.

[MSki]

Jeśli zatem Stacer stał się jednym z programów użytkowych, to chyba system (a nie użytkownik) bierze na siebie odpowiedzialność jego aktualizacji.. tym bardziej, że w Archu i pochodnych tej dystrybucji, aktualizowany jest cały system (tak zrozumiałem), a nie "jakiś" pakiet/program, który tej aktualizacji potrzebuje.

No właśnie. Wprowadzenie paczki z AUR powoduje, że to Ty bierzesz odpowiedzialność za to, że przynajmniej ów program będzie działać (i pół biedy, jeśli to jest jakiś "końcowy" program, a nie coś, co jest jakąś zależnością, na której opiera się coś innego itd.). Teoretycznie opiekun takiego PKGBUILDu w AUR winien sprawę "kontrolować" i dokonywać odpowiednich w nim zmian jeśli zajdzie taka potrzeba. To jednakże teoria, a praktyka wskazuje, że niekoniecznie tak bywa.

Czyli jednak nie jest to takie jednoznaczne, że to użytkownik instalując jakąś paczkę/program staje się za jego funkcjonalność odpowiedzialny.
Użytkownik jest tylko odpowiedzialny za instalację/deinstalację pakietu spoza oficjalnego repozytorium dystrybucji i nic poza tym, gdyż pakiet nie został stworzony przez użytkownika.
To tak jakby winą obarczać użytkownika za to, że Pacman/Pamac błędne zbudował pakiet nie będący częścią oficjalnego repozytorium dystrybucji.
I gdyby tak było, że wina, w każdym z wymienionych przypadków, leżałaby po stronie użytkownika, to tenże użytkownik w obawie przed wykrzaczeniem się systemu nie zainstalowałby nic z AUR.
Nie zainstalowałby również nic z POLAUR.. cytuję za
https://forum.archlinux.org.pl/viewtopic.php?id=615
"W przypadku zaobserwowania błędnego działania tak zbudowanej paczki, czy błędnego działania środowiska itp. w pierwszej kolejności zalecamy powrócenie oryginalnej paczki z repozytorium." - czy i w tym przypadku winą należy obarczyć użytkownika ?   

[pavbaranov]

@Moderator - Chyba część tej rozmowy winna iść w inne miejsce, ale niczego nie narzucam.

@MSki - Jest, jest jednoznaczne, albowiem AUR... nie jest wspierany przez Archa. Instalujesz - robisz to na własne ryzyko. O ile paczki z repozytorium są/winny być przetestowane przed ich wrzuceniem do repozytorium, tak w przypadku AUR - różnie to bywa (w przypadku POLAUR oczywiście również). I tak jeśli zainstalujesz sobie np. makemkv (pierwsza z brzegu obecnie paczka), to w przypadku np. aktualizacji systemu, w którym w miejsce qt5-base (zależność) w obecnej wersji 5.14 pojawi się nadchodząca już wersja 5.15, to ryzykujesz wyłącznie, że makemkv po takiej aktualizacji przestanie działać. Jednakże jeśli np. w miejsce takiego qt5-base z repozytorium zainstalujesz sobie qt5 w wersji rozwojowej (qt5-base-git), to ryzykujesz to, że wszystko to co oparte na niej (aplikacje, środowisko graficzne) przestanie funkcjonować poprawnie. Ba, może się zdarzyć, że w momencie instalacji wszystko zadziała, ale chwilę później, po jakiejś aktualizacji już się wysypie. AUR to na prawdę wyższa szkoła jazdy. Niemniej jednak - jak wspomniałem - to nie dyskusja na ten wątek. Chcesz kontynuować - przenieśmy, a z przyjemnością podzielę się doświadczeniem w tym zakresie (a raczej spore mam, skoro od kilku lat użytkowania Archa mój Arch przez znajomych niekiedy zwany jest PArchem :) albowiem w stosunku do oryginału mogę mieć nawet i grubo więcej niż 60% programów "własnych" i to wyłącznie jeśli chodzi o ilość).

PS: Między "odpowiedzialnością" użytkownika za jego system, a "winą" za ten system jest doprawdy ogromna różnica.

[MSki]

PS: Między "odpowiedzialnością" użytkownika za jego system, a "winą" za ten system jest doprawdy ogromna różnica.

Naprawdę ?
To może zacznijmy winić użytkownika za to, że w ogóle jakikolwiek system zainstalował, a nawet za samą myśl jaka mu w głowie zaświtała ;)
Nie popadajmy w skrajności i nie występujmy w rolach "prokurator-obrońca".
Ale skora masz wiedzę, w co nie wątpię, to może wyjaśnij mi/nam dlaczego odpowiedzialność za zainstalowanie pakietu z AUR/POLAUR ma brać użytkownik, zwłaszcza że pacman/pamac buduje taki pakiet i wdraża go w system bez problemu ?
Już na tym etapie instalator powinien jednoznacznie ostrzegać użytkownika o konsekwencjach instalacji.
A jeśli tego nie robi, to taki pakiet powinien podlegać (jak w tytule) odpowiedzialności zbiorowej, a nie użytkownika.. zwłaszcza że system aktualizowany jest w całości, a więc i zainstalowany pakiet podlega wówczas tej aktualizacji.. a przynajmniej i wg polityki Archa powinien.
Byłoby to nawet bez sensu i blokowałoby drogę rozwoju, a nawet wstrzymywało proces ewolucji dystrybucji (tej czy innej), gdyby nowe, a potrzebne użytkownikom pakiety nie były wdrażane do oficjalnego repozytorium.

[PomPom]

Arch ma fajne ostrzeżenia. Instalacja to dobre ostrzeżenie przed niecierpliwymi klikaczami, a instalacja paczki z AUR bez helpera też wymaga poczytania o tym i poznania choć podstaw. Jak coś jest nieoficjalnego, to już z problemami proszę do tego jednego człowieka, co taki ułatwiacz stworzył :)

Użytkownicy powinni sobie brać do serca to, co im opiekunowie danej dystrybucji piszą. Dlaczego opiekunowie mają przejmować się użytkownikami, którzy nie przejmują się zupełnie tym, co opiekun mówi.

[pavbaranov]

@MSki - Miałem zamiar napisać długo i wyjaśnić o co chodzi, ale... Może lepiej najkrócej jak się da.
1. Zacznijmy od tego, że pacman niczego nie buduje. Pacman to menedżer paczek, który je m.in. instaluje, zarządza nimi itp. Od budowania paczek są inne narzędzia. Pamac w istocie pozwala zbudować paczkę z AUR i ją zainstalować, ale rozmowa miała być o Archu, a nie o Manjaro. "Wspieranie" przez Manjaro budowy paczek z AUR samo w sobie jest idiotyzmem.
2. AUR - pomimo tego, że jest udostępniany przez Archa - nie jest przez niego wspierany. Na pierwszej stronie AUR stoi jak byk: "ZRZECZENIE: Pakiety w AUR są tworzone przez użytkowników. Używasz ich na własne ryzyko."
3. Arch jest "dystrybucją użytkownika". To on decyduje jakie elementy z dostarczonych przez opiekunów i TU, a znajdujących się w repozytorium zbuduje sobie system. Opiekunowie i TU dbają jedynie o to, by te klocki w danym momencie ze sobą działały. Oznacza to m.in. to, że jeśli istnieje taka potrzeba, to są one przebudowywane nawet wówczas, gdy nie zachodzi potrzeba dostarczenia nowej wersji paczki (ot, niedawno LO zostało "podbite", albowiem pojawiła się nowa wersja popplera w repozytorium; bez przebudowy LO przestałoby ono działać).
4. AUR jest oddany społeczności. Wystarczy jedynie chcieć umieścić tam PKGBUILD i to wystarczy. Repozytorium AUR nie znajduje się pod kontrolą opiekunów Archa w tym sensie, że nie ingerują oni w nie, gdy zachodzi np. potrzeba dostarczenia nowego PKGBUILDu (z dowolnego powodu). Nie instalują też paczek zbudowanych z AUR (a w każdym bądź razie wszystkich) i nie testują, czy i jak to działa i funkcjonuje.
5. Wprowadzając jakąkolwiek paczkę z AUR do swojego Archa, wprowadzasz tu "obce" ciało, które może z pozostałymi paczkami funkcjonować prawidłowo, ale wcale nie musi. To jest Twoja decyzja, że chcesz taki obcy element wprowadzić. Kto zatem, jak nie użytkownik, ma dbać o to, by tak skonstruowany system działał prawidłowo?
6. O ile w przypadku paczek z repozytorium i prawidłowego zarządzania swoją instalacją Archa, o aktualizacje dba z jednej strony zespół opiekunów (i TU) tej dystrybucji, a z drugiej strony pacman, tak w przypadku AUR takiego mechanizmu nie ma. Opiekun "paczki" z AUR może dobrze wypełniać swoje zadanie i w istocie dokonać zmian, gdy są one niezbędne, ale teoria rozmija się z praktyką. Spora część "paczek" w AUR jest również porzucona (orphaned) - tu już absolutnie nikt nie dba o aktualizowanie PKGBUILDów. Tak, wiem, że są różne aurhelpery, ale i one nie poradzą sobie z sytuacją, w której PKGBUILD nie został dostosowany do aktualnego stanu repozytoriów Archa.
7. I jak powiedziałem: pół biedy, gdy instalowana paczka jest np. "ostatnim ogniwem", aplikacją, gdzie wskutek zmian w repozytorium Archa i aktualizacji systemu, po prostu nie zadziała. Gorzej, gdy ktoś - z różnych powodów - do swojego systemu wprowadza jakąś paczkę, która jest zależnością innych. Tu, gdy ona po jakiejś aktualizacji nie zadziała, system, środowisko itd. itp. po prostu może się rozlecieć i potem taki użytkownik ma pretensje do Archa. Bardzo często tak się natomiast dzieje, gdy instalowane paczki są z tzw. wersji deweloperskich (np. *-git), których PKGBUILDy zwykle w ogóle nie są "rozwijane" po ich udostępnieniu. To użytkownik musi wiedzieć zatem co i dlaczego wprowadził do Archa oraz jak postępować, gdy inne jego elementy zostaną zmienione.
Dlaczego zatem to użytkownik odpowiada za swoją instalację Archa, w której znajdują się paczki z AUR? Najprościej, najkrócej - albowiem opiekunowie Archa "nie wiedzą" nic o takiej instalacji.

[MSki]

@pavbaranov
ad1. Ok, pacman nie buduje, a instaluje.. resztę pominę milczeniem.
ad2. Nie wiem jak jest z AUR w Archu i czy jest tam owo zastrzeżenie, ale wierzę Ci na słowo.
ad.3 Zrozumiałem.
ad4. Czyli jednak jakieś, pojedyncze dopuszczają do instalacji ?
ad5. Ja też byłbym niezadowolony z tego, jak ktoś podrzucałby mi dodatkową robotę.. dlatego rozumiem dewów Archa ;)
ad6. Również i to zagadnienie zrozumiałem.
ad7. Ten punkt Twojej wypowiedzi niejako podsumowuje całość i w zasadzie mógłby występować jako jedyny.
Mnie "rzuciły się w oczy" ostatnie dwa zdania - "Dlaczego zatem to użytkownik odpowiada za swoją instalację Archa, w której znajdują się paczki z AUR? Najprościej, najkrócej - albowiem opiekunowie Archa "nie wiedzą" nic o takiej instalacji." - i stąd kolejne już moje pytanie..
..To może i dobrze, że deweloperzy nie wiedzą z których paczek/programów korzysta użytkownik.. ale o tym wie chyba system ? ;)

[pavbaranov]

@MSki - Nie bardzo ja natomiast rozumiem o co Ci chodzi z komentarzem do mojego pkt. 4 (bo chyba się pomieszały numerki). Jeśli jednak dobrze się domyślam, to nie istnieje żadne przeciwwskazanie w instalacji paczek, które znajdują się w AUR. Trzeba to jednak robić rozsądnie oraz posiąść wiedzę umożliwiającą prostą choćby diagnostykę co się stało, że coś co jeszcze niedawno działało poprawnie zaprzestało działać. Także kierując pytania na forum o pomoc w takich przypadkach należy napisać, że korzysta się z paczek z AUR i jakich (oczywiście z sensem).

System "wie", że ma jakąś paczkę zainstalowaną. To oczywiste, ale ów system nie ma jak się "naprawić", gdy PKGBUILD z AUR, który wymaga poprawki jej nie otrzymał. Ot, przykład. Oprócz repozytoriów stabilnych, Arch ma również repozytoria testowe oraz dwa "unstable" (dla KDE/Qt oraz GNOME). Załóżmy, że ktoś używa takich repozytoriów oraz używa paczki calligra-git zbudowanej z... no właśnie - raczej z POLAUR niż z AUR, albowiem ta ostatnia nie buduje się. Do repozytorium testing dwa dni temu trafiła nowa wersja poppler. Paczka calligra-git w AUR nie została "podbita", bowiem zasadą jest, że paczki z AUR winny być dostosowane do repozytoriów stabilnych. Niemniej jednak, gdy ktoś używa calligra-git oraz repozytorium testing, to po dokonaniu aktualizacji systemu wprowadzona do niego zostanie paczka poppler w wersji 0.86.1, która spowoduje, że calligra-git przestanie działać (co najmniej poprawnie). I to użytkownik w takim przypadku musi wiedzieć, że calligra-git po prostu wymaga przebudowy, by znów działała. Są pewne narzędzia, które mają to użytkownikowi ułatwić, ale nie są one doskonałe (np. nie potrafią odróżnić, czy potrzeba przebudowy jest wynikiem nowej zależności, czy też brakiem zależności opcjonalnej). To po prostu trzeba wiedzieć, zwłaszcza, że istnieje małe nawet prawdopodobieństwo, że calligra-git po przejściu poppler z repozytorium testowego do stabilnego zostanie "podbita".