Linux i błędy „Package system is broken” oraz „Unmet dependencies”

Przedstawiam kolejny mikroporadnik poświęcony konkretnemu, irytującemu problemowi, z jakim mogą się czasem zetknąć osoby korzystające z otwartych systemów na bazie Linuksa.

Dzisiaj będzie o tytułowych komunikatach z błędem, które następują podczas próby instalacji programów. Wynikają z niekompletnej instalacji w przeszłości i pojawiają się rzadko, ale mogą skutecznie popsuć przyjemność korzystania z Linuksa.

Ostatnio spotkałem taki błąd podczas próby zainstalowania polskich pakietów językowych przez dość przyjemny interfejs systemu Linux Mint. Najpierw poprawnie zaktualizował swoje informacje (cache), a potem rzucił mi w twarz takim komunikatem grozy:

The package system is broken
Check if you are using third party repositories. If so disable them…

Brzmi to złowieszczo, tak jakby coś się strasznie popsuło.

I można odnieść wrażenie, że faktycznie tak jest. Gdyby po ujrzeniu błędu spróbowało się zainstalować jakikolwiek pakiet z zewnątrz przez konsolę (apt install PAKIET), to pewnie też wyskoczyłby błąd:

To może instalacja ręczna? Przez pobranie z sieci i dwukrotne kliknięcie pliku .deb?
Również enigmatyczny błąd (na Mincie wyświetli nam go program Captain, odpowiedzialny za obsługę takich plików):

Broken dependencies
To fix this run ‘sudo apt-get install -f’ in a terminal window.

Nie było to moje pierwsze spotkanie z tym błędem. Ale tym razem miałem więcej motywacji, żeby dokładniej go poznać. I pokonać.

Uwaga

Piszę z perspektywy użytkownika systemu Linux Mint, ale intuicja podpowiada, że wiele przemyśleń powinno mieć przełożenie na inne Linuksy oparte na Debianie, jak Zorin czy Ubuntu. Nie mogę tego jednak zagwarantować.
Ponadto w moim przypadku błąd wynikał z tego, że podczas próby pierwszej instalacji nie miałem potrzebnych plików (zależności). Przy innych przyczynach opisane tu rozwiązanie może się nie sprawdzić.

Spis treści

• Zasięg i waga błędu
• Przyczyna błędu
• Rozwiązanie 1: podążanie za instrukcjami spod błędu
• Rozwiązanie 2: użycie graficznego Menedżera Oprogramowania
• Rozwiązanie 3: reset stanu DPKG
• Parę słów na koniec

Zasięg i waga błędu

Jak pokazałem wyżej – jeśli błąd pojawi się w jednym miejscu, to od momentu wystąpienia zapewne pojawi się przy każdej kolejnej próbie instalacji czegoś z zewnątrz.

Nieważne, czy instalujemy przez interfejs graficzny, czy konsolę. Możemy nawet sięgać po całkiem inne, niezwiązane pakiety. Prawie wszystko skończy się błędem.

Co gorsza, błąd na pewno występuje na Mincie, a prawdopodobnie również na Ubuntu czy Zorinie. Wszystkie te odmiany Linuksa są popularne i często polecane osobom migrującym z Windowsa (co jest teraz na czasie).

Wszystkie te cechy sprawiają, że warto wziąć błąd na cel, spróbować go zrozumieć i rozbroić. Co niniejszym zrobię.

Przyczyna błędu

Wymieniłem wyżej kilka popularnych systemów, których dotyka błąd. Ich wspólny mianownik? Wykorzystują do instalacji znane programy, APT oraz DPKG.

Na takich systemach programy dzielą się odpowiedzialnością:

• Jest jakaś przystępna graficzna nakładka, pozwalająca instalować różne rzeczy (są nią m.in. ustawienia pakietów językowych z pierwszego screena).
• APT to program, któremu takie graficzne nakładki podzlecają różne zadania. Odpowiada za pobieranie rzeczy (zwykle plików DEB) z internetu oraz wydawanie poleceń DPKG.
• DPKG to wykonawca najniższego szczebla, który odczytuje z plików DEB ich rolę, po czym umieszcza je w odpowiednich miejscach, integrując je z systemem.

Po wystąpieniu błędu nieco poeksperymentowałem i doszedłem do wniosku, że wynika on z niedokończonych spraw podczas poprzedniej instalacji.

Był sobie jakiś etap pierwszy, kiedy próbowałem zainstalować pakiet. Jaki? W sumie nieistotne; ważniejszy jest fakt, że instalacja nie doszła do skutku. W zapiskach DPKG pakiet pozostał niedokończonym zadaniem.

Później – może nawet znacznie później – nastąpił etap drugi. Spróbowałem zainstalować pakiet językowy przez graficznego instalatora („program od języków”). I tu nastąpił swoisty głuchy telefon:

• program od języków poprosił APT-a o instalację wskazanego pakietu;
• APT zapytał DPKG o aktualny stan rzeczy;
• usłyszał w odpowiedzi o niewykonanych zadaniach;
• zamiast sprawdzić, czy stoją na drodze obecnego zadania – spanikował i wyemitował konkretny błąd Unmet dependencies („niespełnione zależności”);
• program od języków odebrał ten błąd – a że nie ma wbudowanej dokładnej obsługi błędów, to wrzucił go do zbiorczego wora o apokaliptycznej nazwie Package system is broken.

Wiele różnych programów zderzało się z błędem, bo jego źródłem jest APT, do którego kieruje się większość zadań związanych z instalacją. Program od języków dodawał do tego własną eskalację, ale pierwotnym błędem pozostaje tu Unmet dependencies.
Za faktyczne źródło problemu uważam natomiast alergiczną reakcję APT-a na dawne niedokończone zadania DPKG.

Jak celowo wywołać błąd

Użyję tutaj sposobu konsolowego, bo niektóre graficzne interfejsy są dość odporne i trudniej celowo coś popsuć. Dlatego najpierw uruchamiam sobie konsolę skrótem Ctrl+Alt+T.

Na początku warto zaktualizować listę dostępnych źródeł:

sudo apt update

Następnie należy pobrać sam plik główny jakiegoś większego pakietu, niewystarczający do pełnej instalacji. Może być taki:

apt-get download kde-spectacle

Spectacle to narzędzie do screenshotów typowe dla systemów opartych na środowisku KDE.
Wiele systemów opiera się na czymś innym. Instalacja rzeczy tak im obcej wiąże się z pobraniem mnóstwa plików.

To ważne, żeby użyć w tym miejscu apt-get – sam apt pobrałby cały pakiet razem z jego zależnościami, zaś użyty program jest aktualnie „głupszy” i pobiera jedynie plik główny, niewystarczający do działania.

Następnie można spróbować zainstalować pobrany większy pakiet:

sudo dpkg -i kde*.deb

Wyskoczy nasz błąd Unmet dependencies, związany z brakiem zależności. Innych pakietów, mniejszych lub większych, na których opiera się ten instalowany. A ten błąd, jak już widzieliśmy, blokuje wiele innych metod instalacji.

Ciekawostki na temat błędu

Jeśli już pojawi nam się błąd – wywołany celowo albo nieświadomie – to można go sobie poanalizować. I potwierdzić sobie empirycznie, że błąd zachodzi na styku APT-a i DPKG. Przestaje zachodzić, gdy tylko jeden z nich jest w grze.

Jak już wiemy, dotyka wielu rzeczy:

• gdyby spróbowało się zainstalować jakiś pakiet językowy, to wyskoczy groźny komunikat wspomniany na początku;
• gdyby dwukrotnie kliknąć jakiś plik DEB, to Captain wyświetli błąd;
• gdyby spróbować coś zainstalować konsolowo, np. apt install xclip – błąd.

Gdyby natomiast użyć polecenia:

apt-get download xsel

…To APT pobierze wskazany programik. Bez żadnego błędu – bo samo pobieranie nie wymaga interakcji z DPKG.

Można teraz użyć „czystego” DPKG do zainstalowania pobranego pliku DEB:

sudo dpkg -i xsel*.deb

Wyświetli się informacja o poprawnym zainstalowaniu, zaś xsel powinien normalnie działać w konsoli. Bo to APT był panikarzem, zaś w takich interakcjach nie bierze udziału.

Nie traktowałbym tej właściwości jak jakiegoś sposobu na rozwiązanie błędu. Ale potencjalne obejście? Być może.

Problem opisany, to czas na jego rozwiązanie.

Rozwiązanie 1: podążanie za instrukcjami spod błędu

O ile sam błąd brzmi groźnie, o tyle w każdym z omawianych tu przypadków było proponowane jakieś rozwiązanie. Program od instalacji pakietów językowych wyświetla na przykład:

run the following command in a Terminal: apt-get install -f

Trochę mnie drażni taka porada w graficznym programie, bo skoro już ktoś używa takiej nakładki, to może reagować na konsolę bardziej alergicznie niż APT na niedokończone sprawy DPKG. Poza tym utrwala to stereotyp, że na Linuksie bez niej ciężko.

No ale ten jeden raz można się przełamać. Konsolę można uruchomić kombinacją Ctrl+Alt+T, można też ikonką z dolnego paska. Następnie można tam wpisać podany tekst:

apt-get install -f

…Gdyby ktoś jednak nacisnął teraz Enter, wykonując (ang. run) całe polecenie, to zderzyłby się z błędem:

Informacja zawiera wprawdzie mocną sugestię co do przyczyny (are you root?), ale nie sądzę, żeby to pojęcie było znane wielu osobom. A zatem – kolejny wybój na drodze, konieczność zapoznania się z linuksową terminologią, utrwalenie stereotypu.

W każdym razie, po ludzku, root oznacza administratora. Potrzebujemy większych uprawnień, bo polecenie zmieni parę rzeczy w plikach systemowych. Żeby je sobie nadać, trzeba dopisać sudo na początku komendy:

sudo apt-get install -f

Powinna się wyświetlić informacja, że w kolejce na instalację czekają różne pakiety, a także pytanie, czy chcemy pobrać X megabajtów, które zajmą Y miejsca na dysku.

Można to potwierdzić klawiszem Y, po czym nacisnąć Enter. Zaczną się instalować różne rzeczy – i jest spora szansa, że po tym wszystkim DPKG się odkorkuje, zaś instalowanie różnych rzeczy zacznie działać.

Rozwiązanie 2: użycie graficznego Menedżera Oprogramowania

Linux Mint zawiera zestaw różnych przydatnych programów. Jednym z nich jest Menedżer Oprogramowania.

To właściwie graficzna nakładka na APT-a, pozwalająca przeglądać bazy programów oraz je instalować. Coś jak linuksowy odpowiednik Play Store’a (choć tego drugiego nie lubię i uważam za narzędzie monopolizacji).

Menedżer zapewnia również coś znacznie cenniejszego niż graficzny intefejs – potrafi wyłapywać przypadki błędów i nie rozsypać się jak konsolowy apt czy interfejs od języków. Zamiast tego wykonuje zakulisowo kroki potrzebne do uporządkowania sytuacji.

W praktyce: jeśli otworzymy Menedżera i klikniemy przycisk Install przy dowolnym systemowym pakiecie (nawet najmniejszym), to wyświetli listę zakolejkowanych pakietów oraz pytanie o zgodę na ich zainstalowanie.

Komunikat nie wspomina, że to pliki, których zabrakło podczas poprzedniej instalacji, a nie coś związanego z aktualnie wybranym pakietem (którym był tu malutki xclip).

Jeśli ją wyrazimy, to pliki zostaną pobrane. Odkorkuje to DPKG i zażegna irytujące komunikaty również dla wszystkich pozostałych metod instalacji.

Rozwiązanie 3: reset stanu DPKG

Oba poprzednie rozwiązania wymagały zainstalowania tego, co się zakolejkowało. Ale co, jeśli nie chcemy niczego instalować? Bo na przykład uznaliśmy, że utknięte pakiety są nam niepotrzebne albo ich instalacja powodowałaby inny błąd?

W takim wypadku przydałoby się zacząć z czystą kartą. Powiedzieć DPKG: „Mistrzu, wywalamy te pliki. Tych plików nie ma”.

Te, czyli które? Warto sobie na początku ustalić, który pakiet nas blokuje. Można przykładowo spróbować zainstalować losowy program:

sudo apt install xclip

Wyskoczy oczywiście komunikat o błędzie. Przewijając go do początku, można znaleźć informację:

Ten konkretny pakiet można następnie spróbować wyczyścić poleceniem konsolowym:

sudo dpkg --purge --force-all PAKIET

Po usunięciu pakietu blokującego kolejkę instalacja innych rzeczy powinna zacząć działać. O ile mieliście ten sam rodzaj błędu co w moim przypadku.

Więcej informacji

W każdej chwili można sobie zajrzeć do pliku, w którym dpkg przechowuje informacje na temat stanu różnych swoich pakietów. Jego ścieżka to:

Plik można otworzyć w dowolny sposób, choćby przez zwykły linuksowy odpowiednik Notatnika. Dla sytuacji z mojego przykładu znaleźlibyśmy taką informację:

Byłby to jedyny plik spośród pakietów znanych DPKG, który ma stan unpacked (inne miały u mnie installed). Pozwala to łatwo go wyodrębnić jako plik do usunięcia.

Gdyby ktoś kiedyś trafił na dziwniejszą sytuację niż ta względnie jasna u mnie, to zawsze można się wspomagać takimi informacjami i ustalić, gdzie tkwi źródło problemu.

Parę słów na koniec

Błąd omówiony w tym wpisie może być bardzo irytujący dla codziennych użytkowników, wpychając ich w labirynt niejasnych komunikatów i poleceń konsolowych. Co gorsza, dotyka Linuksów szczególnie polecanych dla grona mniej konsolowego.

Ze względu na te cechy zaliczyłbym błąd do poważniejszych zadziorów, wartych oszlifowania. Może przez autorów Linuksów, może przez ekipę od programów APT i DPKG.

Oto parę luźnych przemyśleń na temat tego, co mógłby zyskać system, żeby wszystko działało w sposób przyjaźniejszy użytkownikom:

• w razie zakorkowania programu DPKG przez jakiś pakiet – wyraźne diagnozowanie problemu i prosta opcja wyczyszczenia pliku, bez konieczności użycia konsoli;
• automatyczne pobieranie pakietu innym kanałem, jeśli wewnątrz DPKG „utknął” tylko pakiet niezwiązany z obecnie instalowanym;
• wyraźniejsze informowanie przez Menedżera Oprogramowania, że zakolejkowane pliki dotyczą innego pakietu niż ten, który próbujemy instalować;
• lepsze rozpoznawanie błędów na Mincie i niewrzucanie ich do wspólnego worka (albo przynajmniej do worka o mniej groźnej nazwie);
• jeśli już musi być konsola, to niech polecana komenda od razu zawiera sudo na początku (jeśli bez tego i tak się nie obędzie).

W wolnym czasie spróbuję ustalić, jak wygląda sprawa na różnych Linuksach i gdzie byłoby fajnie zgłosić propozycje.
Jeśli na poradnik trafi osoba, która już to wie i ma wtyki (albo nie ma, ale po prostu chce wiecznej chwały w świecie open source) – proszę zgłaszać śmiało Nie zależy mi na żadnym pierwszeństwie.

Publikuję poradnik z nadzieją, że ktoś wklei w wyszukiwarkę treść błędu, zobaczy tu stosunkowo łatwe rozwiązanie – i dzięki temu nie zniechęci się do Linuksa, może w przyszłości poleci go znajomym, a alternatywa będzie rosła w siłę