Paczka nie może być zainstalowana albowiem jakiś plik znajduje się już w systemie.

Zdarza się, że przy aktualizacji lub instalacji jakichś paczek w systemie pojawia się informacja, że jakiś plik znajduje się już w systemie plików. Potem otrzymujemy jedynie informację, że żadna paczka nie została zainstalowana, czy zaktualizowana. Nie jest to żaden problem i gdy tylko będziemy postępować właściwie rozwiązanie zawsze się znajdzie. Wpierw jednak jestem winien jedno wytłumaczenie. Dla użytkowników innych menedżerów paczek dziwnym może się wydawać, że skoro jakiś jeden pakiet nie może być zainstalowany, to inne pakiety również. Otóż pacman nie wspiera aktualizacji pojedynczej paczki. I słusznie - Arch jest dystrybucją ciągłą i paczki dostępne w repozytorium są (winny być) zawsze już przebudowane, gdy nowe wersje ich zależności wprowadzone zostały do repozytorium. Wracamy. Przede wszystkim wszelkie rozwiązania typu skasować plik, który koliduje, sforsować instalację nowej paczki itp., które są niekiedy pokazywane jako remedium na wszystkie bolączki nie są właście. W nieszczęśliwych przypadkach istnieje możliwość, że zepsujemy sobie w ten sposób system, który nie wstanie już przy ponownym uruchomieniu. W mniej nieszczęśliwych nie wstanie środowisko, bądź jakiś jego element, czy aplikacja. Kiedy zatem zobaczymy coś takiego:

error: could not prepare transaction error: failed to commit transaction (conflicting files) package: /path/to/file exists in filesystem Errors occurred, no packages were upgraded.

lub wersji polskiej

błąd: nie można przygotować transakcji błąd: nie udało się wykonać transakcji (konfliktujące pliki) pakiet: /jakaś_ścieżka_do/pliku znajduje się już w sytemie Wystąpiły błędy, żaden pakiet nie został zaktualizowany

to w pierwszej kolejności należy sprawdzić o co chodzi. Przede wszystkim błąd taki oznacza, że jakaś nowa paczka dostarcza jakiś plik, który z jakiegoś powodu (jest zawarty w innej paczce, został stworzony przez użytkownika, jest pozostałością po niedokładnie usuniętej paczce) znajduje się już w systemie. Z powyższej informacji wiemy dwie ważne rzeczy: jaki plik uniemożliwia instalację nowej paczki oraz gdzie się znajduje. W tej chwili z pomocą przychodzi pacman. Wydajemy polecenie:

pacman -Qo /jakaś_ścieżka_do_konfliktującego/pliku

Ową ścieżkę i nazwę pliku znajdziemy w informacji o błędzie. W wyniku działania powyższego polecenia otrzymamy informację jaki pakiet jest właścicielem pliku uniemożliwiającego aktualizację, czy instalację nowej paczki. W zasadzie możliwe rozwiązania są dwa: - albo otrzymujemy informację, że żaden pakiet nie jest właścicielem tego pliku, - jakaś paczka jest właścicielem określonego pliku. Pierwszy przypadek możliwy jest w sytuacji, gdy albo został on stworzony przez użytkownika, albo jest pozostałością jakiegoś programu (np. gdy paczkę usunęliśmy z systemu pozostawiając w nim jego pliki konfiguracyjne), albo... został zainstalowany z pominięciem pacmana (skrypt, "paczka" od producenta oprogramowania, albo "cudowne" rozwiązanie - instalacja za pomocą dpkg lub rpm takich paczek). W pierwszych dwu przypadkach rozwiązanie jest proste - w istocie możemy spokojnie usunąć taki konfliktujący plik i ponowić instalację, która winna przebiegać już prawidłowo. Ostatnie powód konfliktu jest bardziej złożony i w ogóle nie powinien wystąpić, albowiem nie powinniśmy w ogóle zainstalować żadnego programu z ominięciem pacmana (wyjątki to paczki typu appimage, czy flatpak). Jeśli z jakiegoś powodu musimy w systemie zainstalować paczkę, która jest rozpowszechniana w formatach nieobsługiwanych przez pacmana, czy też jest jakimś skryptem, to dla takiej paczki winniśmy wykonać PKGBUILD, by pacman zawarł ją w swej bazie danych. Podobnie dla paczki tworzonej ze źródeł winniśmy zrobić PKGBUILD, a nie instalować jej w "tradycyjny" sposób. Wykonanie PKGBUILDu w takich sytuacjach i stworzenie paczki pacmana oraz jej instalacja z użyciem tego narzędzia spowoduje, że znajdzie się ona w bazie pacmana, a późniejsze odpytanie jej o właściciela pliku (-Qo) zwróci nam informację do jakiej paczki on należy. W tej ostatniej zatem sytuacji najsensowniejszym rozwiązaniem jest odinstalowanie wadliwie zainstalowanej aplikacji w systemie i ponowienie instalacji. Wówczas również nie powinniśmy mieć błędów w instalacji. Co w takim razie w drugiej sytuacji, gdy jakaś paczka jest właścicielem określonego pliku? Proponuję lekko odmienne rozwiązanie niż opisane w wiki Archa. Otóż w takiej sytuacji, w pierwszej kolejności powinniśmy sprawdzić skąd pochodzi paczka zawierająca ten sam plik. Teoretycznie najprościej będzie nam przeszukać repozytoria i AUR jakimś aurhelperem. Może to być graficzny program jak octopi, pamac, czy pkgbrowser, może to być np. trizen, pkgbuilder, czy najpopularniejszy yaourt. W tym ostatnim przypadku po prostu wpisujemy:

yaourt paczka

i w efekcie otrzymamy informację o tym, skąd pochodzi paczka uniemożliwiająca nam instalację (będzie przy niej stosowna informacja). Jeśli paczka nie znajdzie się ani w repozytorium, ani w AUR, a nadto nie zrobiliśmy jej we własnym zakresie, to istnieje prawdopodobieństwo, że z jakiegoś powodu paczka ta wypadła już z repozytorium bądź z AUR. Znów w zależności od pozyskanych informacji postępujemy odmiennie: - jeśli obie paczki zawierające ten sam plik pochodzą z oficjalnych repozytoriów Archa, to w pierwszej kolejności odwiedzamy stronę główną i szukamy informacji, czy błąd taki nie został w jakiś sposób opisany; jeśli tak postępujemy zgodnie ze znalezionym opisem, jeśli nie, to zgłaszamy błąd, występujący zaś problem możemy rozwiązać we własnym zakresie (jeśli potrafimy) odpowiednio przygotowując PKGBUILD dla którejś paczki (bądź obu), albo poczekać na rozwiązanie problemu przez opiekunów, - jeśli jedna paczka pochodzi z AUR, to błąd zgłaszamy opiekunowi paczki w AUR, samą paczkę najlepiej odinstalować i ewentualnie, jeśli nadal nam potrzebna, stworzyć nowy PKGBUILD dla niej bądź poczekać na reakcję opiekuna, - tak samo podchodzimy do sprawy, gdy kolidująca paczka pochodzi z niezależnego repozytorium, - jeśli obie paczki pochodzą z niezależnych repozytoriów - należy zgłosić błąd ich opiekunom, a najlepiej sprawdzić, czy repozytoria te są jeszcze aktywne, albowiem zdarza się, że ich rozwój został porzucony; w takim przypadku najsensowniej jest odinstalować paczkę bądź obie i - jeśli nadal ich potrzebujemy - poszukać nowszego bądź innego rozwiązania np. w AUR bądź stworzyć PKGBUILD samemu; w przypadku gdy paczka pochodzi z porzuconego repozytorium, warto się zastanowić nad usunięciem go w ogóle z systemu. - podobnie podchodzimy do sprawy, jeśli kolidującymi paczkami są paczki z niezależnych repozytoriów i z AUR. Praktycznie w żadnym przypadku natomiast nie stosujemy sforsowania instalacji, używając przełącznika --force, albowiem może to doprowadzić (i zwykle doprowadzi) do uszkodzenia bazy pacmana oraz możliwych i bardzo prawdopodobnych błędów przy późniejszych działaniach na systemie zainstalowanych paczek. Krótkie podsumowanie: 1. Jedynie wówczas usuwamy kolidujący plik i ponawiamy aktualizację, gdy wiemy, że plik ten jest osierocony. 2. Nigdy nie stosujemy pacman -Syu --force lub podobnego rozwiązania. 3. Jeśli błędne paczki pochodzą z repozytorium Archa, a nie istnieje rozwiązanie opisane na jego stronie domowej, to zgłaszamy błąd i wstrzymujemy się z aktualizacją do czasu naprawienia. 4. Niemal w każdej innej sytuacji, odinstalowujemy paczkę, która nie pochodzi z oficjalnego repozytorium, zgłaszamy błąd opiekunowi takiej paczki (w AUR, w niezależnym repozytorium), samą zaś paczkę najsensowniej odinstalować i w zależności od umiejętności bądź to przygotować dla takiej aplikacji nowy PKGBUILD i zbudować od nowa, bądź to poczekać na rozwiązanie przez opiekunów