Więcej aplikacji na KF5 - mniej kompilacji

Od roku używam nowej wersji KDE, czyli czegoś, co w zasadzie nie wiadomo nawet jak się nazywa. Środowisko jest budowane m.in. w oparciu o Qt5 oraz specjalnie stworzony na potrzeby Plasmy 5, zestaw bibliotek o nazwie KDE Frameworks 5. Choć doczekaliśmy się praktycznie już ich 17 wydania  (czyli powstają od półtora roku), choć przedłużone już wsparcie dla Qt4 niebawem się skończy, to nie wszystkie jeszcze aplikacje ze świata KDE zostały przeportowane do nowych bibliotek.
Z różnych względów używam wersji przeportowanych do Qt5/KF5. Do tej pory odbywało się to poprzez ich kompilowanie z GIT. W części opierając się o AUR, w części tworząc własne PKGBUILDy. Człowiek jest jednak leniwy, a pojawiło się nowe repozytorium, w którym dość dużo jest aplikacji zbudowanych praktycznie w ten sam sposób, którego używałem dotąd. Zanim jednak przedstawię odpowiednie wpisy do pacman.conf kilka uwag ogólnych.
Aczkolwiek aplikacje, o których mowa nie zostały jeszcze uznane przez zespół tworzący oprogramowanie dla KDE, to znakomita większość spośród nich działa prawidłowo. Niekiedy nie ma wszystkich funkcjonalności znanych ze swoich odpowiedników dla KDE4, sporadycznie wprawdzie budują się, ale nie działają (tak jest od jakiegoś czasu z KGet opartym na KF5). Czy stosować, czy też nie takie aplikacje, pozostawiam oczywiście Waszemu wyborowi. To co można zwykle zauważyć w porównaniu do aplikacji opartych na KDE4/Qt4 używanych w Plasma 5, to nieco mniejsze zapotrzebowanie na zasoby komputera. Nie jest to jednak reguła, a sam zwykle nie przejmuję się ile pamięci mi jakiś program zżera, czy też jaki ma apetyt na CPU do chwili, gdy wszystko działa prawidłowo. Nie ślęczę zatem przy monitorze systemu śledząc czy lepiej jest, czy gorzej. Jeśli u Was aplikacje KDE4 w Plasma 5 działają sprawnie, to nie namawiam do eksperymentów.
Jeśli jednak ktoś by chciał...
Skąd zatem brać aplikacje dla Plasma 5? Pomijam w tej chwili AUR. Pomijam też te, które znajdują się już w repozytoriach "stabilnych" Archa. Źródła repozytoriów, co do zasady mamy dwa.
Pierwszym jest testowe repozytorium kde-unstable. Jest to królestwo Antonio Rojasa, opiekuna KDE w Archu. Tutaj pojawiają się wersje aplikacji, które udostępnione są przez zespół KDE w repozytorium unstable projektu KDE. Informacje o nich najczęściej można przeczytać na stronie projektu KDE, można też śledzić te nowości w repozytorium. W kde-unstable nigdy nie pojawią się wersje aplikacji, które nie zostały w nim udostępnione. W tym repozytorium Archa pojawiają się natomiast testowe wersje zarówno samego środowiska Plasma 5, jak i testowe wydania KDE Applications. Te ostatnie w wersjach opartych o KF5 o tyle, o ile w przeportowanej wersji zostały umieszczone we wspomnianym repozytorium KDE. Ważną informacją dla chcących uruchomić możliwość instalacji z kde-unstable jest to, że budowane są one w oparciu o repozytorium testing Archa, zatem powinniśmy udostępnić dla pacmana oba te repozytoria. Biorąc pod uwagę, że Arch nie wspiera częściowej aktualizacji, oznacza to konieczność przejścia na testową wersję oprogramowania tego systemu. Nie chcę słuchać, że to są "niestabilne" wersje. Nikt nikogo nie zmusza do pracy na paczkach testowych. Mogę powiedzieć natomiast jedno o aplikacjach w KDE umieszczanych w jego repozytorium unstable. Oprogramowanie to znajduje się tu w co najmniej wersji beta i z reguły, tak sama Plasma, jak i aplikacje (szczególnie te, które są jedynie aktualizowane z wcześniej wydanych wersji) często okazują się "lepsze" od tzw. wersji stabilnych. Reguły jednak nie ma i nie daję żadnej gwarancji, że tak za każdym razem będzie.
Jeśli zatem zdecydujecie się uruchomić programy KDE dostępne w kde-unstable musicie w pliku /etc/pacman.conf dokonać następujących wpisów:

[kde-unstable]
Include = /etc/pacman.d/mirrorlist
[testing]
Include = /etc/pacman.d/mirrorlist

Wpisy muszą znaleźć się powyżej innych repozytoriów, jak core, extra, czy community. Oczywiście, aby prawidłowo działały programy z repozytorium testing powinniśmy również dokonać odpowiednich wpisów udostępniających community-testing (a używając bibliotek multilib, również multilib-testing). Standardowy plik pacman.conf zawiera już stosowne wpisy, wystarczy jedynie usunąć znak # przed ich nazwą oraz poleceniem Include, udostępniając w ten sposób je systemowi.
Raz jeszcze: są to wpisy udostępniające systemowi testowe oprogramowanie, które co do zasady winno służyć wyłącznie do celów testowania nadchodzących rozwiązań w Archu, a nie do codziennej pracy. Nie chcesz pomagać deweloperom Archa, to otwierając te repozytoria przynajmniej nie marudź, że to nie działa, że Arch nie jest stabilny itp. Nie chcesz pomóc - to w takim razie nie są to rozwiązania dla Ciebie. Nie umiesz sobie poradzić w kłopotach, gdy skutkiem pojawienia się w testing nowej wersji jakiegoś programu system okaże się niesprawny - nie jest to rozwiązanie dla Ciebie.
Drugie repozytorium pojawiło się stosunkowo niedawno i nie jest repozytorium pochodzącym nawet od deweloperów Archa. Znajdują się tu programy, które co do zasady odpowiadają wersjom budowanym z AUR. Praktycznie jedyna różnica, to inne oznaczenia tych paczek, albowiem przyjęta w Archu dla budowy paczek z GIT reguła stanowi, by numer wersji paczki aplikacji znajdującej się w fazie rozwojowej oznaczać przez nr_rewizji.nr_commitu. Numer wersji paczek w omawianym teraz repozytorium najczęściej składa się natomiast z daty_pojawienia_się_commitu.nr_commitu. W ten sposób zawsze "wyprzedzą" one wersje budowane z AUR - dla systemu będą się prezentować jako nowsze wersje, nawet gdy takimi nie są.
Repozytorium dostępne jest po dokonaniu następującego wpisu:

[home_mazdlc_kde-frameworks-5_Arch_Extra]
SigLevel = Never
Server = http://download.opensuse.org/repositories/home:/mazdlc:/kde-frameworks-5/Arch_Extra/$arch

Niestety nie wiem, czy one również wymagają uruchomienia repozytorium testowego i kde-unstable (dla nowych wydań Plasma 5), jednakże należałoby tak przyjąć. Repozytorium powyższe jest bardzo często aktualizowane. Od pojawienia się nowych wersji aplikacji udostępnionych w GIT zwykle nie czeka się dłużej niż 2-3 dni by odpowiadająca im wersja ukazała się w repozytorium. Z reguły aktualizacje odbywają się szybciej.

Jeśli ktoś bardzo chciałby korzystać z aplikacji opartych o KF5, których nie ma jeszcze w repozytoriach stabilnych Archa, ale jednocześnie nie chce mieć testowej wersji Archa, jedna podpowiedź. Aplikacje w obu repozytoriach przedstawionych wyżej są  budowane w oparciu o KF5, Qt5 i ewentualnie inne jeszcze biblioteki. Zespół KDE nie wypuszcza obecnie KF5 w wersjach beta, czy kandydujących. Mniej więcej w comiesięcznym cyklu pojawia się nowa ich wersja. Jeśli zatem szczególnie w repozytorium kde-unstable pojawia się jakiś zestaw aplikacji, a jednocześnie w repozytorium testing nie ma paczek KF5 ani Qt5 (także pozostałych zależności konkretnej paczki), to może okazać się, że aplikacje z tego repozytorium działać będą także w przypadku nieudostępnienia systemowi repozytorium testing. Ze względu na to, że nie jest to polecana metoda w żaden sposób jej ani nie rekomenduję, ani nie namawiam do używania. Pamiętajcie - decydując się na takie rozwiązanie - gwałcicie Archa jak Syfona przez uszy.

Kilka jeszcze uwag o obu repozytoriach i aplikacjach w nich zawartych.
Jak wspomniałem, przynajmniej jedna aplikacja oparta o KF5 nie działa. Jest nią KGet. Wprawdzie uruchomi się, ale nie ściągnie niczego. Czy inne działają? Odpowiem inaczej - nie stosuję wszystkich aplikacji z KDE, ale te, które używam działają. Nie ręczę, że tak będzie w każdym przypadku.
Co do zasady repozytorium Mazdlc nie powielało jak dotąd aplikacji, które zostały już w wersji na KF5 udostępnionych w Archu i to nawet w kde-unstable. Od chwili udostępnienia DigiKam 5.0.0 beta 2 (oraz bibliotek, na których się DigiKam opiera) w repozytorium unstable KDE i z chwilą pojawienia się tej aplikacji w tej wersji w kde-unstable, mamy do czynienia z sytuacją, gdzie w kde-unstable jest  DigiKam 5.0.0beta2 (i biblioteki, na których się opiera w tej wersji bądź w wersji 15.11.90), zaś w repozytorium Mazdlc znajduje się digikam-git. DigiKam 5 w kolejnych wersjach beta będzie prawdopodobnie obecny w kde-unstable aż do chwili jego oficjalnej premiery, która nastąpić ma 30.04.2016 r. Nie wiem jak długo digikam-git będzie dostępny w repozytorium Mazdlc, ale rozsądek podpowiada, by stosować rozwiązania z kde-unstable. Tutaj pojawia się jeden problem. W obu repozytoriach istnieje biblioteka libksane. W kde-unstable w wersji 15.11.90 i niebawem prawdopodobnie ta biblioteka w wersji 15.12 trafi do repozytorium Archa (wpierw testing, potem extra), zaś w Mazdlc jest jej wersja libksane-git. W oparciu o tę ostatnią, w tym repozytorium  zbudowana jest aplikacja do obsługi skanera Skanlite (w wersji skanlite-frameworks-git). Nie istnieje zatem możliwość używania tej aplikacji z biblioteką z kde-unstable. Konieczne jest jej przebudowanie w oparciu o libksane z kde-unstable czyli zbudowanie jej z obecnego skryptu udostępnionego w AUR (aktualizacja 4.12.2015).