EDIT: Pierwszy z błędów
nie występuje przy aktualizacji systemu, a wyłącznie, gdy będziemy chcieli zainstalować (reinstalować) grupę kf5.
Dzisiaj w repozytorium [testing] pojawiła się nowa wersja KDE Frameworks 5.9. Zainteresowanych zmianami odsyłam tu:
https://www.kde.org/announcements/kde-frameworks-5.9.0.php. Wersja jak zwykle wprowadza pewne zmiany, poprawki itp. Zmiany wprowadzono m.in. w zakresie NetworkManager-Qt, które teraz stało się częścią KDE Frameworks. Widoczną dla użytkownika konsekwencją jest... brak możliwości pełnej instalacji nowego KF5.9. Próba jego instalacji kończy się bowiem nierozwiązywalnymi zależnościami pomiędzy modemmanager-qt, libmm-qt i plasma-nm. Ten ostatni aplet jest obecnie niezgodny z API modemmanager-qt, które zastępuje libmm-qt. Rozwiązań jest kilka.
- Przede wszystkim, repozytorium [testing] jest raczej dla bardzo zaawansowanych użytkowników - nie musimy go użwać.
Jeśli już jednak chcemy, to:
- Instalujemy pozostałe paczki składające się na KF5.9 i cierpliwie czekamy na nałożenie patcha (dostępny) na plasma-nm lub pojawienie się w repozytoriach co najmniej plasma-nm 5.3 beta, lub
- Odinstalowujemy paczkę plasma-nm, instalujemy całe, nowe KF5.9 (zasygnalizuje sprzeczność między modemmanager-qt i libmm-qt oraz networkmanager-qt i libnm-qt, gdzie zezwalamy na odinstalowanie tych paczek i zainstalowanie nowych).
Cieszymy się (prawie) nowym KF5.9. Z jednym wyjątkiem. Nie będziemy mieć apletu umożliwiającego łatwe zarządzanie połączeniami sieciowymi z poziomu pulpitu (GUI).
Zanim podrzucę spatchowane plasma-nm 5.2, proponuję instalację plasma-nm-git z AUR w następujący sposób:
Ściągamy źródła z AUR i przechodzimy do katalogu:
yaourt -G plasma-nm-git && cd plasma-nm-gitEdytujemy plik PKGBUILD i w miejsce:
depends=('networkmanager-qt-git' 'modemmanager-qt-git' 'plasma-workspace-git')wstawiamy:
depends=('networkmanager-qt' 'modemmanager-qt' 'plasma-workspace')Budujemy i instalujemy aplet:
makepkg -sircpotwierdzając usunięcie plasma-nm i zainstalowanie plasma-nm-git (obecnie odpowiada ono mniej więcej Plasma 5.3 Beta1). Jak powiedziałem, w wolnej chwili postaram się przedstawić bardziej konserwatywne rozwiązanie polegające na nałożeniu patcha:
http://quickgit.kde.org/?p=plasma-nm.git&a=commitdiff&h=4d72cb7966edda33bc72c77fc2a126844fc1f134&o=plain) na obecną wersję plasma-nm 5.2.2, proszę jednak o cierpliwość.
Drugi problem, jaki się pojawia, to upgrade systemu chce instalacji kxmlrpcclient 5.9.0 (obecnie -3), który zgłasza konflikt z plasma-workspace i pacman zadaje nam pytanie, czy usunąć to ostatnie (wprawdzie z domyślnym "Nie", ale zawsze). W żadnym przypadku nie próbujemy odpowiedzieć na nie twierdząco, bo inaczej pozbędziemy się Plasma5 z systemu. Dzieje się tak dlatego, że w PKGBUILD kxmlrpcclient ma wpisany konflikt z plasma-workspace w wersji niższej niż 5.3 (choćby beta), albowiem obecnie ten pakiet, a nie plasma-workspace dostarczać będzie pliki lokalizacyjne. Obecnie pliki lokalizacyjne ma zarówno kxmlrpcclient, jak i plasma-workspace 5.2.2 i pacman nie dopuszcza do instalacji, a w konsekwencji do jakiejkolwiek aktualizacji systemu.
Mamy dwa wyjścia:
- albo do czasu pojawienia się w [kde-unstable] (o ile korzystamy) plasma-workspace 5.2.95, co powinno nastąpić około połowy przyszłego tygodnia, do IgnorePkg w /etc/pacman.conf dopisujemy kxmlrpcclient,
- albo... wymuszamy instalację kxmlrpcclient (nazwijmy to opcją dla hardcorowca
), co generalnie nie jest polecane, ale w tym przypadku krzywdy nie powinien zrobić.
PS: Drobna uwaga: bezproblemowe używanie KF5.9 z Plasma5 będzie możliwe dopiero gdy Plasma5 pojawi się w wersji 5.3, co nastąpi z końcem kwietnia. Miejmy nadzieję, że osoby decydujące o przesunięciu KF5.9 z [testing] do [extra] będą mieć na tyle oleju w głowie, by zrobić to dopiero wówczas.
