Octopi a sprawa Arch Linux
Octopi jest dość popularnym i chyba najlepiej dopracowanym graficznym menedżerem paczek dla systemów zarządzanych przez pacmana. Obecnie octopi, to już nie tylko sam menedżer pakietów, ale również cały zestaw aplikacji, które pozwalają na śledzenie zmian w repozytoriach i informowanie użytkownika o pojawiających się nowych wersjach paczek zainstalowanych w systemie, zarządzanie listą repozytoriów (dokładnie ich listą w pacman.conf), czyszczenie cache pacmana itp. Pomimo tego, że pacman jest doskonałym narzędziem, to jednak w XXI w. chęć zarządzania swoim oprogramowaniem w wygodnej, graficznej formie, nie jest żadną fanaberią.
W przeciwieństwie do dystrybucji pochodnych, oraz np. KaOSa, czy Chakry, w repozytoriach Archa nie znajdziemy octopi (podobnie zresztą jak innych nakładek na pacmana). Skoro przyroda nie znosi próżni, to nic dziwnego, że stosowny skrypt (a nawet skrypty) budujące octopi znajdziemy w AUR. Co do zasady są takie dwa: octopi oraz octopi-git. Drugi z nich nie dostarcza wszystkich programów składających się na grupę octopi - pomija octopi-notifier, czyli oprogramowanie, które informuje o możliwych aktualizacjach oprogramowania. Pierwszy... Cóż, wydaje się, że opiekun PKGBUILDu niedokładnie go przemyślał. Otóż skrypt ten w istocie buduje całą gamę programów z grupy octopi. Ba, buduje nawet aż trzy programy octopi-notifier, oparte na trzech różnych bibliotekach (Qt4, Qt5 oraz KF5) i przeznaczone dla trzech różnych środowisk graficznych. I w tym leży problem. Ze względu na konflikt pomiędzy tymi trzema wersjami programu, paczki octopi wprawdzie zbudujemy przy pomocy jakiegoś wrappera AUR, ale ich nie zainstalujemy (być może taką możliwość daje bauerbill, ale nie próbowałem). Nadto jeszcze bezsensownie ściąga zależności konieczne do budowy każdej z tych paczek, pomimo tego, że nie są one nam potrzebne. Wersja Qt4 ściąga oczywiście całą grupę qt4, choć możemy sobie łatwo wyobrazić system wolny już od tego porzuconego oprogramowania. Wersja frameworks ściąga natomiast knotifications i wszystkie jego zależności (w praktyce całą grupę kf5 i jeszcze trochę). Nie sądzę, by te biblioteki były komuś potrzebne do szczęścia w środowisku innym niż Plasma 5. Ten ostatni problem pozostaje, gdy będziemy próbować zbudować octopi lokalnie z pomocą makepkg (tak wiem, niepotrzebne po budowie paczki można usunąć, jednakże po co powodować niepotrzebny ruch w sieci, co jest bardzo istotne dla osób o ograniczonych łączach).
Jeśli zatem dochodzicie do wniosku, że właśnie napiszę: PKGBUILD octopi w AUR jest bez sensu, to macie rację.
Prezentuję zatem dwa PKGBUILDy, które umożliwiają budowę zestawów odpowiednich dla Plasma 5 (to PKGBUILD.kf5) oraz dla innych środowisk (to PKGBUILD.qt5). Wersji Qt4 nie przedstawiam, albowiem może ona mieć znaczenie chyba wyłącznie dla osób, które korzystają jeszcze z KDE4, które nie jest już wspierane w Archu. Wszystkie inne środowiska graficzne, które są w repozytorium Archa oraz w AUR wykorzystują już Qt5 lub KF5. W środowiskach opartych o Gtk lepiej winno się natomiast sprawdzić inne oprogramowanie, jak np. pamac, czy tkPacman.
Jednocześnie, prezentowana przeze mnie wersja umożliwia budowę wersji deweloperskiej (z GIT), a nie wersji "stabilnej". Z tą ostatnią jest bowiem pewien szkopuł. Według twórcy tego oprogramowania, ostatnia wersja stabilna to 0.8.1. Niemniej jednak w dystrybucjach, które dostarczają octopi w repozytoriach, pojawiła się już wersja 0.8.3 (a w przypadku KaOSa to nawet 0.8.92). Takie samo oznaczenie nosi wersja w AUR. Repozytorium programu w GIT nie ma tak otagowanej wersji. Są one tworzone przez "uzupełnienie" wersji 0.8.1 do określonego commitu przez opiekunów tego oprogramowania w dystrybucjach. Zdaje się, że "ton" narzuciło tu Manjaro. W efekcie, gdybym chciał trzymać się prawidłowej wersji stabinej, to musiałbym ją zrobić w oparciu o 0.8.1 (jak wspomniałem, to jest wersja stabilna). Takie oznaczenie jednak, powodowałoby, że próba aktualizacji systemu (z AUR) narzuciłaby konieczność aktualizacji również octopi, albowiem w AUR jest wersja wyższa. Oczywiście nie ma przeszkód dla stworzenia wersji oprogramowania z dokładnie tym samym commitem, jaki jest uwzględniony w AUR. Nie widzę jednak sensu tworzenia bytów, które nie istnieją. Jeśli jednak znajdą się chętni na taką wersję, to jeśli sami nie będą w stanie stworzyć sobie PKGBUILDu, jestem gotowy pomóc.
Jeszcze drobna uwaga: paczka zawiera - jak wspomniałem - dwa PKGBUILDy o nazwach PKGBUILD.kf5 oraz PKGBUILD.qt5. Chcąc zbudować sobie octopi w wybranej wersji albo należy zmienić nazwę odpowiedniego pliku na PKGBUILD, albo wykorzystać możliwości makepkg i wykonać:
makepkg -p PKGBUILD.kf5 - dla Plasma 5
albo
makepkg -p PKGBUILD.qt5 - dla pozostałych środowisk
Oczywiście istnieją alternatywy dla proponowanego rozwiązania. Dla przykładu kuszącą propozycją wydaje się być wprowadzenie jednego PKGBUILD dla wszystkich paczek oprócz octopi-notifier i dwu PKGBUILD dla octopi-notifier, po jednym dla wersji Qt5 i KF5. Ze względu jednak na to, że wszystkie składniki octopi wykorzystują jeden kod źródłowy, takie rozwiązanie dwa razy ściągałoby kod programu. Są jeszcze inne, ale te wymagałyby ingerencji w PKGBUILD przez użytkownika. Najsensownie rozwiązanie wydaje się takie, by sam PKGBUILD prowadził do sprawdzenia, czy w systemie znajduje się knotications i wówczas budował wersję dla Plasma 5, a w przeciwnym przypadku wersję "pure-Qt5". Nie jestem jednak pewny, czy w innych środowiskach, jako zależność na pewno nie pojawi się knotifications, którego jednak środowisko to nie będzie potrafiło wykorzystać. Z tych powodów zatem prezentuję takie rozwiązanie jak wyżej.
EDIT:
Dzięki uwadze użytkownika marekmm, oba PKGBUILDy zostały lekko zmienione (usunięty został błąd przy octopi-notifier).
W przeciwieństwie do dystrybucji pochodnych, oraz np. KaOSa, czy Chakry, w repozytoriach Archa nie znajdziemy octopi (podobnie zresztą jak innych nakładek na pacmana). Skoro przyroda nie znosi próżni, to nic dziwnego, że stosowny skrypt (a nawet skrypty) budujące octopi znajdziemy w AUR. Co do zasady są takie dwa: octopi oraz octopi-git. Drugi z nich nie dostarcza wszystkich programów składających się na grupę octopi - pomija octopi-notifier, czyli oprogramowanie, które informuje o możliwych aktualizacjach oprogramowania. Pierwszy... Cóż, wydaje się, że opiekun PKGBUILDu niedokładnie go przemyślał. Otóż skrypt ten w istocie buduje całą gamę programów z grupy octopi. Ba, buduje nawet aż trzy programy octopi-notifier, oparte na trzech różnych bibliotekach (Qt4, Qt5 oraz KF5) i przeznaczone dla trzech różnych środowisk graficznych. I w tym leży problem. Ze względu na konflikt pomiędzy tymi trzema wersjami programu, paczki octopi wprawdzie zbudujemy przy pomocy jakiegoś wrappera AUR, ale ich nie zainstalujemy (być może taką możliwość daje bauerbill, ale nie próbowałem). Nadto jeszcze bezsensownie ściąga zależności konieczne do budowy każdej z tych paczek, pomimo tego, że nie są one nam potrzebne. Wersja Qt4 ściąga oczywiście całą grupę qt4, choć możemy sobie łatwo wyobrazić system wolny już od tego porzuconego oprogramowania. Wersja frameworks ściąga natomiast knotifications i wszystkie jego zależności (w praktyce całą grupę kf5 i jeszcze trochę). Nie sądzę, by te biblioteki były komuś potrzebne do szczęścia w środowisku innym niż Plasma 5. Ten ostatni problem pozostaje, gdy będziemy próbować zbudować octopi lokalnie z pomocą makepkg (tak wiem, niepotrzebne po budowie paczki można usunąć, jednakże po co powodować niepotrzebny ruch w sieci, co jest bardzo istotne dla osób o ograniczonych łączach).
Jeśli zatem dochodzicie do wniosku, że właśnie napiszę: PKGBUILD octopi w AUR jest bez sensu, to macie rację.
Prezentuję zatem dwa PKGBUILDy, które umożliwiają budowę zestawów odpowiednich dla Plasma 5 (to PKGBUILD.kf5) oraz dla innych środowisk (to PKGBUILD.qt5). Wersji Qt4 nie przedstawiam, albowiem może ona mieć znaczenie chyba wyłącznie dla osób, które korzystają jeszcze z KDE4, które nie jest już wspierane w Archu. Wszystkie inne środowiska graficzne, które są w repozytorium Archa oraz w AUR wykorzystują już Qt5 lub KF5. W środowiskach opartych o Gtk lepiej winno się natomiast sprawdzić inne oprogramowanie, jak np. pamac, czy tkPacman.
Jednocześnie, prezentowana przeze mnie wersja umożliwia budowę wersji deweloperskiej (z GIT), a nie wersji "stabilnej". Z tą ostatnią jest bowiem pewien szkopuł. Według twórcy tego oprogramowania, ostatnia wersja stabilna to 0.8.1. Niemniej jednak w dystrybucjach, które dostarczają octopi w repozytoriach, pojawiła się już wersja 0.8.3 (a w przypadku KaOSa to nawet 0.8.92). Takie samo oznaczenie nosi wersja w AUR. Repozytorium programu w GIT nie ma tak otagowanej wersji. Są one tworzone przez "uzupełnienie" wersji 0.8.1 do określonego commitu przez opiekunów tego oprogramowania w dystrybucjach. Zdaje się, że "ton" narzuciło tu Manjaro. W efekcie, gdybym chciał trzymać się prawidłowej wersji stabinej, to musiałbym ją zrobić w oparciu o 0.8.1 (jak wspomniałem, to jest wersja stabilna). Takie oznaczenie jednak, powodowałoby, że próba aktualizacji systemu (z AUR) narzuciłaby konieczność aktualizacji również octopi, albowiem w AUR jest wersja wyższa. Oczywiście nie ma przeszkód dla stworzenia wersji oprogramowania z dokładnie tym samym commitem, jaki jest uwzględniony w AUR. Nie widzę jednak sensu tworzenia bytów, które nie istnieją. Jeśli jednak znajdą się chętni na taką wersję, to jeśli sami nie będą w stanie stworzyć sobie PKGBUILDu, jestem gotowy pomóc.
Jeszcze drobna uwaga: paczka zawiera - jak wspomniałem - dwa PKGBUILDy o nazwach PKGBUILD.kf5 oraz PKGBUILD.qt5. Chcąc zbudować sobie octopi w wybranej wersji albo należy zmienić nazwę odpowiedniego pliku na PKGBUILD, albo wykorzystać możliwości makepkg i wykonać:
makepkg -p PKGBUILD.kf5 - dla Plasma 5
albo
makepkg -p PKGBUILD.qt5 - dla pozostałych środowisk
Oczywiście istnieją alternatywy dla proponowanego rozwiązania. Dla przykładu kuszącą propozycją wydaje się być wprowadzenie jednego PKGBUILD dla wszystkich paczek oprócz octopi-notifier i dwu PKGBUILD dla octopi-notifier, po jednym dla wersji Qt5 i KF5. Ze względu jednak na to, że wszystkie składniki octopi wykorzystują jeden kod źródłowy, takie rozwiązanie dwa razy ściągałoby kod programu. Są jeszcze inne, ale te wymagałyby ingerencji w PKGBUILD przez użytkownika. Najsensownie rozwiązanie wydaje się takie, by sam PKGBUILD prowadził do sprawdzenia, czy w systemie znajduje się knotications i wówczas budował wersję dla Plasma 5, a w przeciwnym przypadku wersję "pure-Qt5". Nie jestem jednak pewny, czy w innych środowiskach, jako zależność na pewno nie pojawi się knotifications, którego jednak środowisko to nie będzie potrafiło wykorzystać. Z tych powodów zatem prezentuję takie rozwiązanie jak wyżej.
EDIT:
Dzięki uwadze użytkownika marekmm, oba PKGBUILDy zostały lekko zmienione (usunięty został błąd przy octopi-notifier).
Komentarze
Prześlij komentarz