Witaj na Forum Linuxiarzy
Zanim zalogujesz się, by pisać na naszym forum, zapoznaj się z kilkoma zasadami savoir-vivre'u w dziale Administracja.
Wiadomości z problemami zamieszczone w wątku "Przywitaj się" oraz wszelkie reklamy na naszym forum będą usuwane.

[ROZWIĄZANY] Nie mogę zainstalować gnome-builder

Zaczęty przez funn, Wrzesień 16, 2019, 08:15:45 PM

Poprzedni wątek - Następny wątek

robson75

Cytat: robson75 w Wrzesień 16, 2019, 10:07:06 PM
Radziłbym jeszcze zrobić backup systemu przed usunięciem tego katalogu.
Przecież ja o tym pisałem, najpierw zrobić migawkę, a dopiero potem wykonać te działania.
Arch Linux Xfce - 64Bit Linux User #621110

pavbaranov

Robert, ja już nie wiem, jak Ci to wytłumaczyć.
I. Konflikt plików występuje w kilku przypadkach:
1. wadliwie zrobione paczki, które dostarczają tych samych plików i jednocześnie pozwalają na zainstalowanie się w systemie (czyli nie mają się w polu conflict),
2. jedna z paczek jest z nieoficjalnego źródła i nie uwzględnia paczki z repozytorium (w zasadzie to samo co wyżej, ale inaczej postępujemy),
3. wadliwie przeprowadzone usunięcie jakiejś paczki, kiedy w systemie zostały jakieś pozostałości, które winny zostać usunięte,
4. ewentualnie wadliwe hooks dla pacmana,
5. aplikacja zainstalowana z pominięciem pacmana,
6. inne jeszcze, które są w zasadzie do pominięcia.
W zależności od tego, która z sytuacji występuje postępujemy odmiennie, ale do tego potrzebna jest diagnostyka, czyli
II. ustalenie:
1. które paczki z powodu istnienia już w systemie plików są ze sobą w "konflikcie" uniemożliwiającym instalację później instalowanej paczki,
2. czy istnieje w systemie, a jeśli tak, to jaka paczka, która jest właścicielem plików, które uniemożliwiają instalację.
W odpowiedzi uzyskamy
III. informację, że:
1. jakaś paczka jest właścicielem tych plików,
2. żadna paczka nie jest ich właścicielem.
Sytuacja z pkt. III.2 oznacza wystąpienie którejś z sytuacji opisanych w pkt. I.3 lub I.5(i w zasadzie żadna inna). Jeśli jest to przypadek I.3 wówczas i wyłącznie wówczas możemy skasować konfliktujące pliki z systemu, a katalog wyłącznie wówczas, gdy nie zawiera innych jeszcze plików (!!!) i nie należy (nawet pusty) do jakiejś innej paczki, co sprawdzamy tak samo jak sprawdza się właściciela pliku. Na temat przypadku I.5 niżej.
W przypadku pkt. III.1 jeśli występuje sytuacja opisana:
1. w pkt. I.1 - przechodzimy na główną stronę Archa i/lub forum i szukamy rozwiązania; jeśli go nie ma - zgłaszamy na bugs.archlinux.org i powstrzymujemy się z instalacją. Zanim zrobimy cokolwiek, co opisałem niżej, sprawdzamy jeszcze czy mamy aktualną listę serwerów źródlanych, a dla pewności generujemy nową i próbujemy ponowić proces instalacji. Jeśli się nie powiedzie i jeśli bardzo potrzebujemy paczkę, którą chcemy zainstalować - szukamy czy nie istnieje ona w appimage i/lub flatpak itp. lub nie istnieje możliwość jej uruchomienia np. z lokalnego katalogu. Jeśli nie mamy takiej możliwości, a koniecznie musimy zainstalować taką paczkę, to w pierwszej kolejności należy zobaczyć, czy nie można owych paczek przebudować (tj. zrobić dla nich odpowiedni PKGBUILD) i usunąć konflikt. Jeśli nie potrafimy tego zrobić - prosimy o pomoc kogoś, kto się na tym lepiej zna. Jeśli się na to decydujemy niekiedy może okazać się konieczne przebudowanie obu paczek będących w konflikcie. Jeśli jesteśmy w stanie ponieść ryzyko destabilizacji systemu, upewniamy się na 100%, że obie paczki zostały stworzone na podstawie tych samych narzędzi, z wykorzystaniem tych samych bibliotek i możemy wówczas jeśli są one na tych samych możemy dokonać nadpisania bądź sforsowania instalacji, czyli:
pacman -Syu --overwrite ścieżka/do/konfliktującego/pliku
lub
pacman -Syu --force
Ewentualnie - jeśli potrzeba - wskazujemy jeszcze na paczkę do instalacji. Uwaga - system, choć nie powinien, to jednak sporadycznie może ulec jakiejś destabilizacji po takim manewrze.
2. w pkt I.2 lub I.5 - odinstalowujemy paczkę pochodzącą z nieoficjalnego źródła, powiadamiamy opiekuna takiej paczki (gdy I.2), instalujemy paczkę z repozytorium. Jeśli obie paczki są z nieoficjalnych źródeł (AUR to źródło nieoficjalne również) musimy zdecydować na której nam bardziej zależy. Można też dysponując odpowiednią wiedzą pokusić się o przerobienie PKGBUILDu jednej lub większej ilości paczek, tak, by zapobiec dostarczaniu tych samych plików przez konkurujące ze sobą paczki.
3. w pkt. I.5 usuwamy aplikację zainstalowaną "ręcznie", tworzymy dla niej poprawny PKGBUILD i próbujemy instalacji.
Proponowane przez Ciebie rozwiązanie jest zatem właściwe wyłącznie - a i to nie do końca - w jednym przypadku. Rozwiązania w postaci backup, timeshift itp. itd. są oczywiście fajne, backup jest zwykle bardzo fajną i polecaną rzeczą, jednakże jest to tylko i wyłącznie - w tym przypadku - środek do rozwiązania kłopotów, do których prowadzi wadliwy sposób postąpienia z opisanym problemem, a nie jest usunięciem jego przyczyny.
I dla mnie to EOT do czasu, gdy @funn się nie zdecyduje cokolwiek powiedzieć.

robson75

Pawle
To ja Ci powiem jak to było z update Bleachbit. (wiem że to nie ma związku z tym wątkiem, ale to tylko przykład)
A wiec przyszło do mnie update systemu, w tym Bleachbit, wiec uruchamiam terminal i wklepuje
pacman -Syu
I się okazuje że pliki Blaechbit znajdują się w systemie plików i update zostaje przerwane.
Więc odinstalowuje Bleachbit
pacman -Rs bleachbit
I robię reboot systemu.
Po reboocie aktualizuje system, aktualizacja przebiega bez problemów.
I chcąc na nowo zainstalować Bleachbit, znowu wyskakuje mi info że w systemie istnieją już pliki Bleachbit, i instalacja zostaje przerwana.
To wiec uruchamiam managera plików jako root, i usuwam konfliktujący katalog,
I po tym zabiegu Bleachbit się instaluje bez problemów.

Wiem że w Arch Linux takie przypadki zdarzają się bardzo rzadko, ale jednak się zdarzają.
Arch Linux Xfce - 64Bit Linux User #621110

funn

Przykra sprawa, że muszę to polecenie pacman -Qo wykonać ponad 200 razy.

pacman -Qo /usr/lib/python3.7/site-packages/pytz/__init__.py
błąd:  Żaden pakiet nie jest właścicielem /usr/lib/python3.7/site-packages/pytz/__init__.py


Jest jakiś dobry poradnik co zaznaczyć w Bleachbit, aby nie usunął mi potrzebnych plików i nie rozwalił systemu?

robson75

#19
Cytat: funn w Październik 14, 2019, 01:04:42 PM
Jest jakiś dobry poradnik co zaznaczyć w Bleachbit, aby nie usunął mi potrzebnych plików i nie rozwalił systemu?
Zaznacz to co u mnie, i na pewno nie rozwalisz sobie systemu




Ja jeszcze od czasu do czasu uruchamiam Bleachbit jako root.

Arch Linux Xfce - 64Bit Linux User #621110

pavbaranov

Cytat: funn w Październik 14, 2019, 01:04:42 PM
Przykra sprawa, że muszę to polecenie pacman -Qo wykonać ponad 200 razy.

pacman -Qo /usr/lib/python3.7/site-packages/pytz/__init__.py
błąd:  Żaden pakiet nie jest właścicielem /usr/lib/python3.7/site-packages/pytz/__init__.py


Raczej nie będziesz tego musiał zrobić. W katalogu /usr/lib/python3.7/site-packages/pytz/ znajdują się chyba wyłącznie pliki należące do python-pytz. Już Ci pokazało, że jeden z plików nie ma żadnego właściciela (czyli żadna paczka nie dostarcza go obecnie do systemu). Sprawdzasz zatem kto jest właścicielem jeszcze z jednego, dwu plików i pewnie wyjdzie Ci to samo. Potem sprawdzasz kto jest właścicielem katalogu, w którym pliki te się znajdują:
pacman -Qo /usr/lib/python3.7/site-packages/pytz/
Prawdopodobnie wyjdzie Ci dokładnie to samo, czyli żadna paczka nie jest właścicielem tego katalogu (czyt.: obecnie nie istnieje w systemie paczka, która odpowiadzialna jest za jego utworzenie).
Sprawdzasz wówczas jeszcze dla porządku, czy python-pytz jest w systemie zainstalowany:
pacman -Q python-pytz
możesz też nieco szerzej:
pacman -Qs pytz
Wobec poprzednich odpowiedzi winno Ci wyjść, że paczki tej nie masz w systemie, a zatem coś te pliki do niego wprowadziło (inna paczka python-pytz, całkiem możliwe, że "ręcznie" zainstalowana) lub też odinstalowanie paczki python-pytz nie przebiegło do końca prawidłowo i pliki te pozostały jako śmieci. W pierwszym przypadku musisz się raczej zdać na swoją pamięć, ewentualnie upewnić jeszcze czy istnieje w systemie paczka /usr/lib/python3.7/site-packages/pytz-2019.3-py3.7.egg-info i kto jest jej właścicielem.
Po wydaniu zatem kilku komend powinieneś mieć mniej więcej pewność, że:
- w systemie nie ma python-pytz,
- żadna paczka nie jest właścicielem katalogu /usr/lib/python3.7/site-packages/pytz/ i plików w nim się znajdujących.
Możesz zatem spokojnie przystąpić do:
1. albo usunięcia tego katalogu (ew. możesz go sobie gdzieś zarchiwizować) i przeprowadzenia aktualizacji systemu oraz instalacji gnome-builder
2. albo do instalacji gnome-builder dodać opcję sforsowania jej (gdzyż override być musiał dać dla każdego pliku oddzielnie, choć też to można "zautomatyzować") - wybieram zwykle pierwszą opcję, bo choć porzucona już nieco, to jest łatwiejsza do zapamiętania, czyli:
pacman -Syu
Jak na razie sama aktualizacja, albowiem chcemy być pewni, że przy okazji instalacji gnome-buildera coś innego jeszcze nie nadpiszemy. I jeśli przebiegnie ona prawidłowo, to wówczas:
pacman -Syu gnome-builder
Jeśli aktualizacja, czyli poprzednia komenda nie przebiegnie prawidłowo, a pojawiają się też paczki z innej lokalizacji niż ów "pytz", to ponownie sprawdzasz wg. powyższego schematu te nowo wykryte lokalizacje. Ponawiasz próbę.
UWAGA - WAŻNE: Przed dokonaniem aktualizacji doprowadź listę mirrorów do stanu aktualnego. Np. jeśli masz zainstalowanego reflector, to:
sudo reflector --verbose --latest 15 --sort rate --save /etc/pacman.d/mirrorlist
Jeśli nie, to ściągnij sobie albo aktualną paczkę archlinux-mirrorlist i zainstaluj (jeśli się da). Jeśli nie, to po prostu ją rozpakuj, a plik mirrorlist umieść jako /etc/pacman.d/mirrorlist i pamiętaj o usunięciu znaku # sprzed kilku ścieżek. Potem dopiero aktualizacja i instalacja gnome-builder.

PS: Bleachbit to zło, którego należy się ustrzegać. Prawdopodbnie istnieje więcej osób niezadowolonych od zadowolonych jego użytkowników.

@robert75 - Wszystko ok, ale Twoja porada jest z gruntu zła (bowiem gdy to proponowałeś, to nie posiadałeś wiedzy, która umożliwiłaby Ci jego zaproponowanie jako właściwego). Może się sprawdzić. Mogła się sprawdzić w przypadku bleachbit, co nie znaczy, że sprawdzi się w każdym przypadku i że proponowane przez Ciebie rozwiązanie jest zawsze prawidłowe, jak również prawidłowe w przypadku @funn (akurat okazało się być może prawidłowe - czysty przypadek). Nie doprowadzajmy naszymi poradami do możliwej degradacji czyjegoś systemu. Akurat granie w czyimś systemie, którego nie znamy ze spójnością paczek, przy braku jakiejkolwiek wiedzy nt. dlaczego ten system szwankuje jest bardzo złym pomysłem. Starajmy się dociec co nie gra w takim systemie i zaproponować rozwiązanie albo uniwersalne (jeśli się da), albo dostosowane do danego przypadku.

funn

No więc usunąłem ten katalog.
rm -r /lib/python3.7/site-packages/pytz
Zainstalowałem gnome-builder, pojawiły się jakieś artefakty w Gnome. Zrestartowałem system i wszystko na to wygląda że działa. Dzięki.

Zobacz najnowsze wiadomości na forum