Udzielone Odpowiedzi
- Posty
pacui, czy pacli – obojętne – raczej nie do używania. Raz – w niektórych miejscach z automatu daje na przełącznik –noconfirm (co jest kompletnym idiotyzmem, jeśli chodzi o jakiekolwiek „helpery”), dla niektórych funkcji obniża bezpieczeństwo pacmana (#1219 i n.) co jest głupim obejściem problemu, dla którego funkcja ta jest tu użyta i zawiera kilka innych jeszcze „sztuczek”, które należy odsądzić od czci i wiary, a w zakresie interesującym autora wątku absolutnie niczego nie zmienia – podobnie jak yaourt-gui również odnosi się do pacman-optimize (#376-#378). Dodatkowo posługuje się yaourt (także), który delikatnie mówiąc nie należy do narzędzi dorobionych.
Nie, nie jestem purystą, który pierze w rękach, gdy pralka stoi w kącie. Niemniej jednak używanie tego typu narzędzi jak pacui wymaga przeglądnięcia tego kodu (jest tego ponad 2500 linii – ręka w górę, kto to uczynił w dodatku ze zrozumieniem).
Jeśli chodzi zaś o sam wątek, z którego chyba autor się wycofał, to dla podsumowania:
1. Wszelkie narzędzia, które odnoszą się do pacman-optimize, bo aktualizacji systemu do pacman 5.1.x zgłoszą po wybraniu „optymalizacji” (lub w innych przypadkach, bo w pacui wygląda na to, że to jakaś „ukryta” funkcja, wykonywana przy wyborze innej) brak tej paczki. Informacja jak najbardziej prawidłowa, albowiem skrypt pacman-optimize został usunięty i nie jest zawarty ani w pacman, ani w pacman-contrib.
2. Pacman-optimize był w wiki Archa wymieniany jako jeden ze sposobów na przyspieszenie działania pacmana, ale w tym zakresie absolutnie nic nie robił. Tego typu cel osiąga się w inny sposób.Jeśli zatem autor zgłaszał jedynie „błąd”, to żadnego błędu nie ma. Informacja uzyskiwana z yaourt-gui jest obecnie jak najbardziej prawidłowa. Jeśli chciał zoptymalizować działanie pacmana, to musi wskazać pod jakim kątem i co chciał uzyskać, albowiem inaczej nie istnieje możliwość pomocy (z wyjątkiem odesłania do wiki Archa, gdzie dość dobrze opisane są różne przypadki takie optymalizacji).
@azja – yaourt-gui, gdy wybierzesz w nim „optymalizację” wywołuje… pacman-optimize. Program nie rozwijany od marca 2016 i niedostosowany do obecnej wersji pacmana. Jedyne co można doradzić:
pacman -R yaourt-gui
(chyba, że to wersja yaourt-gui-manjaro, to nazwa paczki się lekko zmieni, a sama paczka z AUR do wylotu).To, że coś się przez przypadek dzieje, gdy korzystamy z czegoś, to nie oznacza jeszcze, że jest to na tę przypadłość remedium. Pacman-optimize porównywał bazę lokalną, czy zawiera dodatkowe jeszcze repozytoria oprócz aktualnie wykorzystywanych i jeśli tak było, to usuwał te, z których nie korzystamy, przebudowywał ją i tworzył dla niej nową sumę kontrolną. Co to ma wspólnego z optymalizacją, która miała skracać czas niezbędny przy korzystaniu z pacmana?
Tutaj możesz się zapoznać ze skryptem pacman-optimize.
PS: W dalszym ciągu to co robił pacman-optymize :)The people who believe that pacman-optimize is actually doing something
useful are the same people who are voting for Trump.Allan McRae (to główny maintainer pacmana obecnie).
O dżiza…
1. @warsztat-dom – nie korzystaj z rozwiązań niesystemowych (debtap), chyba że doskonale wiesz co robisz, a – o ile się nie mylę – doskonale nie wiesz.
2. @Robert75 – To co proponuję, to nie są kombinacje, a jedynie po prostu umożliwienie korzystania z nowszej wersji w odpowiedzi na informację @warsztat-dom. Niestety – oprogramowanie zamknięte i bóg jedyny raczy wiedzieć jakie są różnice.
3. @warsztat-dom – Nie „przerabiaj” na własną rękę, nawet debtapem itp., czegokolwiek. Nawet w AUR są doskonalsze paczki. Skoro widzisz, że Twoja paczka jest „starsza”, to skądś się to bierze – raczej AUR gdzieś włączony, ale to nie ma znaczenia. Info o „zagrożeniu stabilności” jakie się pojawia to idiotyzm yaourta itp. Generalnie „stabilność” to idiotyzm – odsyłam do dyskusji z @azja. Owa „stabilność” – to pierdoła wprowadzona wadliwym tłumaczeniem Debian Stable.Ostatnia dostępna 4kvideodownloader to 4.4.6.2295-2. Taka paczka jest w AUR od 25.03.2018. Paczki z serii 4.4.1 w AUR w ogóle nie było (więcej tu), a z tego co widzę, to w repozytoriach Manjaro też tej aplikacji nie ma. Skąd zatem wziąłeś taką wersję?
Budowanie paczke z AUR jest dość dobrze wytłumaczone. Polecam też wątek na tym forum, choć to wierzchołek góry dopiero.
Przy minimalnej ingerencji (czyli odpowiedzi wyłącznie na pytanie o nazwę paczki i licencję) debtap tworzy paczkę o nazwie 4kvideodownloader-4.4-1-x86_64.pkg.tar.xz (i m.in. dlatego nie polecam takich narzędzi), która przez pamac/octopi/yaourt/trizen itd. będzie widziana jako starsza (4.4) od wersji dostępnej w AUR (4.4.6.2295-2). Polecam korzystać z możliwości jakie są wbudowane w system (pacman+pacman-contrib), bowiem masz zdecydowanie lepszą kontrolę, a tworzona paczka (jeśli nie popełniasz błędów) ma m.in. prawidłową nazwę. Gotowiec dostępny tutaj. Przy korzystaniu z tego repozytorium musisz ściągnąć wszystkie 3 pliki jako „raw” lub sklonować całe repozytorium. Oczywiście przebudowanie ffmpeg2.8 jest konieczne.
1. Ściągasz PKGBUILD.
2. Edytujesz i zmieniasz pkgver z obecnej na 4.4.7.2307, a pkgrel na 1. Reszta bez zmian.
3. Wydajesz:
updpkgsums && makepkg -si
(możesz również z rc). I chodzi. debtap prawdopooobnie, o ile Cię rozumiem, wadliwie zinterpretował numer wersji. Sprawdź jaki masz zainstalowany w systemie.Cóż… mniejsza o to.
Zobaczcie sobie na PKGBUILD
Pośród różnych rzeczy, które tam są jest m.in. pole validpgpkeys=. To jest właśnie to pole, które „krzyczy” o podpis PGP. W każdym takim przypadku powinniśmy albo dodać klucz (tak jak to wskazał @czapnaper, albo pominąć walidację przez –skippgpcheck).
I cóż – mówiąc brutalnie – kolejny przykład, gdzie brak informacji w user-friendly dystrybucji, która korzysta z cudzych repozytoriów. A szkoda bo Manjaro mogłoby być super.Masz jeszcze inne sposoby.
@azja – Dla mnie to również ciekawa wymiana poglądów, poznanie innego punktu widzenia (choć przecież również i mi i to z własnego doświadczenie z systemem, o którym piszemy, znanego). Nie – nie zakazuję niczego, choć wprost mówię: AUR nie jest dla Manjaro pomimo „pomocnictwa” (wracając na chwilę do prawniczego żargonu), jakie jest udzielane przez jego twórców (w istocie w Manjaro nie ma wsparcia dla paczek z AUR na poziomie „supportu” udzielanego – przynajmniej oficjalnie – przez twórców; dostarczanie wraz z systemem /i to od samego początku/ narzędzi dla korzystania z AUR ja rozumiem jednak jako „wsparcie” dla AUR; takie samo znajdziemy choćby w Antergosie, w Anarchy-Arch, RebornOS itd.; to nie jest wyłączna domena Manjaro i także tam opiekunowie tych dystrybucji „nie udzielają wsparcia” :)).
To, co napisałem powyżej traktuję właśnie w kategoriach… hmmm… edukacyjnych (nie Ciebie, ale w ogóle użytkowników Manjaro, którzy hurra optymistycznie podchodzą do możliwości instalowania z AUR. Te wywody, czy polemika z Tobą, to tylko unaocznienie pewnego problemu pn. „piekło zależności”, który jest zresztą moim zdaniem nadużywany.
Podsumowując swoje zdanie:
– tak, uważam, że w żadnym przypadku AUR nie jest stworzone do bezpośredniego korzystania z niego w Manjaro,
– tak, można na podstawie tych przepisów skonstruować paczkę dla Manjaro, która może w nim działać prawidłowo.
Najważniejsze, czego może nie powiedziałem (choć wiem, że Twoje zdanie tu jest takie samo), że Manjaro (choć w zasadzie dowolna dystrybucja, włączając Archa), w którym znajduje się paczka budowana z AUR jest systemem, którego osoba, która tego dokonała jest całkowitym i wyłącznym opiekunem. Bierze na swoje bary odpowiedzialność za to, czy będzie to działać, czy nie. Taką paczką, którą zbudował musi się samodzielnie opiekować i wiedzieć, czy dostarczenie do systemu nowej wersji jej zależności wymaga, czy też nie wymaga jej co najmniej przebudowania, bądź sięgnięcia po jakieś patche (przykład pierwszy z brzegu: octopi-git, które nie zadziała w tym momencie w Archu, oraz octopi-git z dodatkowym alpm_octopi_utils, które zadziała /pewnie to jeszcze zmodyfikuję, by octopi wymagało podbicia alpm_octopi_utils; choć napisałem to w wątku, gdzie POLAUR jest opisywany/). Przede wszystkim jednak będzie musiał też wiedzieć, czy zbudowana z AUR paczka ma wpływ na to, czy system uruchomi się po aktualizacji (chodzi o repozytoria), czy też nie. Przykład z octopi jest banalny (a i tak w Manjaro pewnie dostaniecie go w nowej wersji, gdy wejdzie pacman 5.1 oraz Qt5.11) – tu nie zadziałałaby jedna aplikacja, która nawet nie jest w ogóle wymagana do działania systemu. Problem zaczyna się choćby w prozaicznych paczkach, o których wiele osób nawet nie ma świadomości, że mają one wpływ na działanie systemu (przynajmniej DE) jak choćby tematy, wystroje, pluginy itp. itd. dla używanego środowiska. Tu jest pies pogrzebany.I w kwestii owych kontenerów jeszcze. Dla mnie w tej chwili istnieją dwa: AppImage i flatpak. Ich podstawową bolączką jest, że… oferują mniej niż to, co mamy w repozytoriach (tak w Twoich, jak i moich). Jeśli flatpak w istocie się przyjmie, to być może będzie to jakaś dobra alternatywa dla AUR w Manjaro (choć najlepszą – moim zdaniem – byłoby powstanie „MUR”). W przypadku AppImages – nie ma róży bez kolców. Na kilkanaście paczek, jakie próbowałem, uruchamiała się mniej więcej połowa. Wynika to ze sposobu ich budowania i tego konsekwencji (a zwykle budowane są na jakichś mocno – w stosunku do naszych systemów – „starych” już Debianach, czy CentOSach). W takim przypadku pozostaje przebudować taki AppImage samemu na podstawie podobnych przepisów jak PKGBUILDy (a jest ich dostępnych w sieci nawet więcej niż zbudowanych paczek). To jak się wydaje jednak droga dla lekko bardziej zaawansowanego użytkownika, choć problemu wielkiego nie ma: ściągnąć *.appimage, wykonać budowanie lokalnie – winno zadziałać.
Będąc raczej ograniczonym entuzjastą rozwiązań kontenerowych (z bardzo wielu powodów) – uważam, że może się ono okazać dobrym wyłącznie dla bardzo mało doświadczonych użytkowników. Ci, którzy dysponują odpowiednią wiedzą winni się jednak wziąć z bykiem za rogi i spróbować budować paczki we własnym zakresie nawet na podstawie PKGBUILDów w AUR, ale… nie z wykorzystaniem AUR :) (innymi słowy – uważam, że dopiero w przypadku Manjaro wychodzi kompletna nieprzydatność jakichkolwiek aurhelperów). No i niestety potem dbać.
PS: Już śpieszę wyjaśnić to, co sygnalizowałeś, że jest niezrozumiałe. Otóż art. 148 k.k. nie zawiera żadnej pozytywnej normy. Jest wyłącznie sankcją. Prawnik to rozróżnia. Nie znajdziesz w polskim prawie normy, jak katechetyczne V przykazanie Dekalogu. Jak polskie prawo długie i szerokie, niestety, nie istnieje norma mówiąca: Zakazuje się zabijać inną osobę (pomijam kwestie związane z aborcją; nie mieszajmy tu tego). Taka norma byłaby pozytywna. Art. 148 k.k. mówi jedynie o konsekwencjach zabicia innego człowieka (sama sankcja).
Przekładając to na „nasze”. Nie istnieje „pozytywna” norma mówiąca, że AUR w Manjaro stosować nie wolno (ba, jak wspomniałem wręcz istnieje ku temu całe, dość rozwinięte „pomocnictwo”). Masz natomiast sankcję – stosowanie paczek zbudowanych z AUR w Manjaro jest źródłem problemów w działaniu tej paczki bądź całego systemu, do braku możliwości jego uruchomienia włącznie.
No i dzięki za pogaduchy.@azja – Bardziej staram się wytłumaczyć jakie problemy rodzi korzystanie z AUR w Manjaro (pominąłem jeszcze jeden oczywisty, choć go gdzieś zaznaczyłem – dodać do nich należy „zwykłe” problemy z AUR w Archu), bowiem to nie jest nigdzie napisane.
Manjaro jest dystrybucją adresowaną m.in. do ZU. Tu nie ma „ostrzeżenia”, jak w przypadku Archa, że to dystrybucja dla co najmniej średnio zaawansowanych. Jest deklaracja, że jest przyjazna użytkownikowi. I zwróćmy uwagę: w Archu nie istnieje żadne wsparcie dla AUR. Jest oczywiście strona wiki (ale wiki Archa jest społecznościowe), ale np. narzędzia automatyzujące korzystanie z AUR (w tym budowanie paczek), dopóki AUR nie otrzyma oficjalnego wsparcia ze strony Archa (a pewnie długo tak się nie stanie, o ile w ogóle) są w… AUR :) One również w żaden sposób nie są wspierane, a info odnośnie kompilacji z AUR jest od dawna niezmienne: ściągnij źródła, przeglądnij pliki, w katalogu wydaj polecenie makepkg, sprawdź co powstało, zainstaluj. W przypadku Manjaro otrzymujesz te narzędzia przy pierwszej instalacji. Pamac zawiera, Octopi po zainstalowaniu jednego z trzech (w tym jednego porzuconego helpera), w tym jednego – i to najgorszego z możliwych – instalowanego również bodaj z systemem, również.
Skoro ZU otrzymuje taki system OTB, to myślisz, że zastanowi się jakie konsekwencje niesie paczka z AUR? Szczerze wątpię. Skoro jest taka możliwość dawana przez twórców, to oznacza, że… jest ona przez nich zaplanowana i uznawana za możliwą i bezpieczną (inaczej to jak siedzenie na gałęzi i jej podcinanie). Dodatkowo dochodzą informacje o 100% kompatybilności z Archem, co nie jest prawdą (kompatybilne w ten sposób są np. Calculate, czy Sabayon z Gentoo, ba można nawet stwierdzić, że kompatybilny jest np. Antergos z Archem, ale nie Manjaro z Archem). Innymi słowy – wg mnie – użytkownicy Manjaro przez twórców tej dystrybucji są nabijani w butelkę.
Ok, można powiedzieć – nie moja dystrybucja, cóż mi do tego co w niej robicie. Tyle, że moją jest Arch i potem otrzymuję w komentarzach instalowanych, albo nawet tworzonych przeze mnie paczek jakieś bzdurne komentarze, że coś nie działa, jest popsute… Potem to mój czas jest marnotrawiony, bo nikt nawet nie stwierdzi: mam Manjaro (wówczas, sorry – radź sobie sam, to nie dla ciebie). To oczywiście nie ma większego znaczenia dla użytkownika Manjaro. Ba, nawet jestem w stanie go zrozumieć, albowiem w jego dystrybucji zostało stwierdzone, że dostęp do AUR ma zagwarantowany. Nieistotne.
Wracając do tego czy można, czy nie. Oczywiście na poziomie możliwości jest to w Manjaro dostępne. Narzędzia, jakie otrzymuje Manjaro, które są wprost przejęte z Archa (cały pacman), czy korzystające z rozwiązań w AUR (yaourt, octopi), czy też nawet jego własne oczywiście, że umożliwiają korzystanie z AUR. Ba, zakazu nie ma, wręcz odwrotnie. Tyle, że… odpowiedz sobie na pytanie:
Czy istnieje w Manjaro możliwość:
– dodania do listy jego repozytoriów repozytoriów Archa, w tym np. kde-unstable lub gnome-unstable?
– dodania repozytoriów nieoficjalnych Archa, bądź np. Antergosa i innych jego pochodnych?
– instalacji paczek deb bądź rpm narzędziami, które znajdziesz – jeśli nie w repozytorium Manjaro, to w AUR?
Pytanie retoryczne, bo oczywiście, że to wszystko jest możliwe. Pytanie zasadnicze, czy choć jedną z tych opcji poleciłbyś komuś. Czy w ogóle, ktokolwiek rozwijający Manjaro taką opcję by scharakteryzował jako np. „access to Arch repository”, „possibility to install rpm or deb packages” itp.
Ty patrzysz przez pryzmat możliwości, ja przez pryzmat konsekwencji dla użytkownika. O ile na pierwsze pytanie odpowiedź jest także oczywista – tak istnieje, to w przypadku przyjęcia tego drugiego spojrzenia oczywistość ta nie jest już tak klarowna. A skoro przy różnych przypowiastkach o kołach od roweru w motocyklu, to podam Ci jedną z innej branży. Argumentacja: nie jest zabronione, to jest możliwe niekoniecznie musi być właściwa. W polskim prawie nigdzie nie znajdziesz pozytywnej normy, że nie wolno zabijać. Pomimo tego kodeks karny przewiduje konsekwencje takiego czynu.
Podobnie z AUR, czy opisanymi przeze mnie w pytaniach powyżej możliwościami. Tak, to wszystko jest możliwe, ale konsekwencją jest wadliwie działający system. I tylko o to mi chodzi, że w imię PR ktoś, gdzieś, w Manjaro zadeklarował: dajemy możliwość mieszania dystrybucji, zamiast pójść własną drogą i w istocie zrobić dystrybucję, która jest bezpieczna dla swego użytkownika. A na ile ów „AUR dla Manjaro” tkwi w głowach jego użytkowników (tkwił w mej również, gdy z niego korzystałem, wszak używałem część programów z AUR, dlaczego nie? :)), to zobacz sobie na swoją odpowiedź w jednym z wątków. Tutaj twierdzisz, że „AUR nie jest dla Manjaro” (pkt. 1 w Twojej odpowiedzi powyżej). We wspomnianym wątku natomiast, w kolejności „poszukiwania” paczek, na drugim miejscu sugerujesz właśnie paczki z AUR.
I powtórzę: tak, zgadzam się z Tobą. Istnieje możliwość zbudowania w Manjaro paczki na podstawie PKGBUILDu zawartego w AUR. Co do tego nie ma żadnej kontrowersji między nami – gdybym robił PKGBUILD dla Manjaro, to prawdopodobnie wyglądałby on tak samo jak dla Archa (pomijając pewne okresy, gdzie takiego samego zbudować się po prostu nie da). Natomiast samo AUR, a w szczególności umożliwiony przez Manjaro sposób korzystania z AUR jest – wg mnie – całkowicie niedostosowany do… Manjaro, a konsekwencje tego prowadzić mogą do wadliwego działania systemu. I jeszcze by postawić kropkę nad „i” – jeśli w Manjaro zostanie zbudowana jakakolwiek paczka na podstawie jakiegokolwiek PKGBUILDu, który w chwili jego stworzenia był do Manjaro dostosowany, a następnie osoba, która to zrobiła przejmie kontrolę nad taką paczką (czyli stanie się jej, w swoim systemie, deweloperem), to nie istnieje żadne zagrożenie. System będzie działać poprawnie i bez żadnych konsekwencji w postaci jego destabilizacji. Problem leży gdzie indziej, ale to już wiesz.Cóż.. Ze stosunkiem Manjaro do AUR to różnie bywało, a byłem jedną z pierwszych osób (na pewno w Polsce), które zainstalowały tę dystrybucję. Pamiętam też co było napisane na byłym już, nieistniejącym forum Manjaro. W PRowych tekstach pochodzących od jego twórców pojawiały się wówczas informacje o tym, że Manjaro „daje łatwe wsparcie instalacji z AUR” (yaourt instalowany OTB). Pewnie t rudno mi będzie to teraz udowodnić, albowiem strony te przepadły, ale nie czuję się w ogóle do tego zobowiązany. To nie moja obecnie dystrybucja i w istocie można sobie przyjąć radosne stwierdzenie: róbta co chceta.
Odnosząc się do Twoich słów – otóż właśnie Manjaro „tak nie robi”. W swoim wiki nt. AUR w części przenosi tekst z wiki Archa na ten temat, w części pisze bzdury. Natomiast ani jednym słowem nie zająknął się tam nikt, że to nie pakiety z AUR mogą być za stare (to jest drugi z wymienianych powodów, jakie problemy mogą być z paczkami budowanymi z AUR), ale że to… Manjaro (stable) jest często za stare. Nikt nie zająknął się też na temat tego, że paczka z AUR może zostać przebudowana za wcześnie w stosunku do Manjaro. Problem nie leży w tym, że to są „paczki potencjalnie niebezpieczne”, albowiem nikt jeszcze nie wykazał ich niebezpieczeństwa, pomimo że istnieją już kilka ładnych lat, ale w tym, że to nie są pakiety przeznaczone dla Manjaro. Zamiast tego wprowadza się dodatkowo jeszcze kompletnie nieuprawnione i nieprawdziwe stwierdzenia, jak to, że Manjaro jest w 100% kompatybilne z Archem. Nie jest i nigdy nie będzie. Fakt, że paczki w Manjaro w znakomitej większości są – bardzo często bezrefleksyjnie – przenoszone do Manjaro, fakt, że są tak samo budowane nie uprawnia do tego typu twierdzenia. 100% kompatybilność to m.in. możliwość dołączenia do repozytoriów Manjaro stable podstawowych repozytoriów Archa (oczywiście damy je na niższej pozycji w pacman.conf) i możliwość bezkolizyjnego zainstalowania paczek oraz ich w pełni sprawnego działania. Powtarzam: to może się udać, ale to jest przypadek (a sam miałem coś, co można było nazwać ManjArch – właśnie mieszane repozytoria, ale nie o tym).
Jeśli uważasz, że używanie paczek z AUR jest prawidłowe (nie „możliwe”, a „prawidłowe”) to udowodnij proszę tę tezę odnosząc się nie do praktyki („bo mi to działa”), ale uzasadnij teoretyczne aspekty tej tezy. Inaczej pozostanę faszystą, skoro już byłeś mnie do nich przyrównać i będę twierdzić: AUR nie jest przeznaczone dla użytkowników Manjaro, niezależnie od tego co oni sobie o tym wyobrażają. IMO – nic nie przeszkadza korzystać z PKGBUILDów z AUR w Manjaro, ale aby to działało prawidłowo, to Manjaro winno mieć swoją bazę – nazwijmy ją MUR – gdzie będzie miało owe PKGBUILDy dostosowane do stabilnej wersji swego systemu (ta wersja jest przeznaczona dla ZU, a nie testing, czy unstable, gdzie potencjalne kłopoty mogą być mniejsze lub nie będą występować wcale).I popatrz jeszcze raz. Z Twojego wpisu wynika, że zawsze dokonujesz aktualizacji całego systemu, także z AUR. No to raz jeszcze zobacz (to akurat przykład mojej paczki, która absolutnie nie jest dla Manjaro). Jestem opiekunem m.in. plasma-frameworks, która oferuje bugfiksy (głównie) z nadchodzących wydań. Commit, który wskazuję był akurat powiązany z testing Archa, ale wkrótce – po przetestowaniu bodaj przez z górą miesiąc wydań beta i RC Qt5.11, oraz krótkim okresie testowym w testing – ta wersja trafiła do „zwykłego” repozytorium Archa. U mnie pojawiło się podbicie tej paczki ze względu na konieczność przebudowania z uwagi na jej pewną zależność tego wymagającą (to nie jest reguła; nie wszystkie zależności wymagają przebudowania paczki). Załóżmy teraz, że to jest w AUR i że korzystasz z tej paczki. Dokonując „graficzno-tekstowej” aktualizacji systemu, także w stosunku do tego co w AUR (nie wiem z czego korzystasz, ale to nie jest istotne kompletnie), jeśli korzystasz z jakiegoś AUR-helpera/wrappera otrzymasz informację, że plasma-frameworks (której przecież używać jest nieakualna i wymaga budowy). Co zrobi 99% użytkowników (tak Manjaro, jak i Archa, ale w tym drugim przypadku nie jest to wrażliwe)? Prawdopodobnie dokona budowy nowej wersji paczki (zwróć uwagę, że w przypadku mojego PKGBUILDu masz wersję paczki z „.” -> X.Y, gdzie X zawsze odpowiada wersji w repozytorium, Y zaś jest kolejną wersją tej właśnie paczki; gdy pojawia się nowa paczka w Archu, czyli będzie to coś co jest >X.Y, to zostanie w systemie zainstalowana właśnie ona – cały system będzie działać, a ktoś, kto używa mojej paczki jedynie zostanie ewentualnie przez pewien czas pozbawiony jakiejś funkcjonalności, bugfiksu; w przypadku paczek z AUR najczęściej tak to nie wygląda). Kilka dni temu dowiedziałbyś się zatem o istnieniu nowej wersji plasma-frameworks i najprawdopodobniej dokonasz jej zbudowania (ile osób czyta changelogi?). Dokonasz tego zupełnie zbędnie, albowiem do dzisiaj w stable, a nawet w testing Manjaro nie istnieje paczka, ze względu na którą konieczne jest dokonanie przebudowy plasma-frameworks. Tu jeszcze nic się złego nie dzieje – przebudujesz po prostu bez sensu, ale system będzie działać prawidłowo. Kiedy jednak do stable (czy nawet testing) trafi już paczka, ze względu na którą wymagane jest przebudowanie, to już w żaden sposób nie zostaniesz poinformowany o takiej potrzebie (wszak użytkownicy Archa zostali poinformowani wcześniej, a nikt kto tworzy paczki dla AUR nie tworzy ich z myślą o Manjaro, ba sam uczestniczyłem w ich usuwaniu :)). Dokonując zatem aktualizacji systemu dokonasz aktualizacji systemu z repozytoriów (prawidłowo), nie dokonasz natomiast koniecznej aktualizacji (czy jak w tym przypadku choćby przebudowania) paczek z AUR i… system po reboocie może nie wystartować wcale.
Oczywiście z tym samym problemem spotykają się użytkownicy Archa, ale tam to jest ewentualne zaniedbanie użytkownika – w przypadku Manjaro to błąd systemowy.
Opisany powyżej przykład to jedynie jedna z postaci błędu, jakiego doświadcza nieświadomy mniej lub bardziej, czy nawet świadomy użytkownik Manjaro korzystający z AUR (teraz mówię sprawdzam: jesteś doświadczonym użytkownikiem paczek z AUR, powiedz mi proszę, które z nich wymagają przebudowania po dostarczeniu nowej wersji zależności do repozytorium, które nie wymagają przebudowania pomimo, że dostały nową wersję?). Dodatkowo dochodzą pewne rozwiązania, które nie są kompatybilne ze sobą. AUR nie uwzględnia istnienia czegoś jak mhwd (i jego pochodne, bo zostało to już sforkowane do kilku innych dystrybucji), a z drugiej strony rozwiązania Manjaro nie uwzględniają tego co w AUR itd. Paczka z AUR w Manjaro jest równie wadliwa w nim jak paczka z dowolnego innego systemu.
Niemniej jednak, jeśli wykażesz mi, że pomimo tego wszystkiego AUR jest składnicą, z której w sposób bezpieczny dla siebie mogą korzystać ZU (przypominam główną tezę Manjaro: Manjaro is a user-friendly Linux), przy czym nawet w podstawowej informacji o Manjaro, jego twórcy chwalą się, że dystrybucja ta zapewnia dostęp do AUR: (Access to the Arch User Repository (AUR), czyli tam gdzie PR – zapewniamy AUR, tam, gdzie szczegóły do których stosunkowo mało kto sięgnie, z uwagi na to, że AUR w Manjaro działa OTB – to jednak obecnie – umywamy ręce), to zrobię uszy po sobie. Jak na razie nie widzę nigdzie żadnego merytorycznego argumentu, który od bodaj 6 lat używania Manjaro i Archa uzasadniłby tę tezę.No to jeszcze co do AUR :) i raz jeszcze. Dokładnie rzecz biorąc AUR to zbiór przepisów na zbudowanie paczki dla Archa. Nic więcej! Każdy taki przepis m.in. dwa „pola”: depends i makedepends. Z punktu widzenia tzw. dystrybucji pochodnych, istotne jest głównie pierwsze. To pole deklaruje jakie zależności są wymagane do uruchomienia i działania paczki zbudowanej w oparciu o taki „przepis”. Z pewnych względów leżących po stronie sposobu budowania paczek dla Archa zasadniczo nie deklaruje się tutaj wersji oprogramowania. „Przepis” ma uwzględniać aktualną wersję paczki, która jest przez nią wymagana, a która znajduje się w repozytorium Archa (ewentualnie w innej paczce w AUR, która też musi być zbudowana na powyższej zasadzie). Arch jednocześnie zakłada pewien idealizm – system jest zawsze aktualny (stąd też moje wieczne boje, by każdą instalację przeprowadzać z opcjami -Syu dla pacmana, a nie -S jedynie). Tak skonstruowana paczka ma działać, czyli uwzględniać to co w Archu jest.
Spośród dystrybucji, które opierają się na paczkach Archa, praktycznie wyłącznie gałąź stable (oraz w pewnej mierze testing) Manjaro jest jedyną, która w danym momencie czasowym nie oferuje (bądź może nie oferować) tych samych wersji paczek „depends” dla „przepisów” w AUR. Jedna jedyna – innej nie ma. Nie istnieje jak dotychczas taka dystrybucja. Chakra uniezależniła się na tyle, że mieszanie repozytoriów Archa i Chakry jest praktycznie niemożliwe. Wszystkie inne dystrybucje pochodne, korzystające z tych samych rozwiązań (np. systemd), jak np. Antergos, Namib, Obarun, Revenge itd. korzystają bezpośrednio z repozytoriów Archa. Antergos zaktualizowany na 28.05.2018, 17:43 ma te same paczki, jakie ma Arch. W przypadku Manjaro tak może być, ale niekoniecznie.
Dodatkowo dochodzi konieczne podbijanie wersji paczek, które opisałem wyżej.
Korzystanie z AUR we wszystkich tych bezpośrednio pochodnych, czyli oferujących w tym samym momencie te same paczki, dystrybucji jest takie samo w przypadku Archa, jak w nich. W przypadku Manjaro tak nie jest.
I teraz – wykaż mi proszę, że AUR jest w ogóle repozytorium dla Manjaro. Jedynie osoby korzystające z Manjaro Testing, przy zachowaniu pewnej roztropności mogą korzystać. Zwróć przy tym uwagę, że Manjaro – zgodnie z deklaracjami twórców – jest adresowane także do mniej obeznanych użytkowników.
Oczywiście możemy doprowadzać dyskusję do absurdu i dyskutować o tym, że nikt nikomu niczego nie zabroni. To idźmy na całość. Nie istnieje żadna, ale to absolutnie żadna przeszkoda, by instalować w Manjaro i to bezpośrednio paczki rpm, czy deb. Wszak oba narzędzia umożliwiające to znajdują się w repozytorium.
