Zrozumieć niezrozumiałe: instalacja programów w wersjach rozwojowych (git)

W AUR sporo jest skryptów umożliwiających budowę paczek w wersjach rozwojowych. Zwykle noszą one dodatkowe oznaczenia dev/devel, git, bzr, svn, cvs, hg itp. Odróżnijmy wpierw paczki *-dev/devel. Z takim rozszerzeniem winny pojawiać się takie wersje rozwojowe programów, które są w jakiś sposób "ustabilizowane" przez twórców. Innymi słowy - "numerowane" wersje rozwojowe. Przykładem takim niech będzie GIMP, który stosuje bardzo stary system oznaczania swoich wersji, gdzie pierwsza cyfra oznacza wersję, druga cyfra wskazuje na wydanie, a trzecia wskazuje na wersję poprawkową. Dodatkowo jeszcze wydania uważane za deweloperów za stabilne oznaczane są kolejną parzystą liczbą, zaś wydania rozwojowe, które prowadzą do następnych wydań stabilnych oznaczane są liczbą nieparzystą. Stąd GIMP 2.8.22, to ostatnia wersja stabilna (8) drugiego (2) wydania GIMPa, będąca dwudziestą drugą wersją poprawkową dla wydania 2.8. Niedawno ogłoszona wersja 2.9.8 jest rozwojową (9) wersją, która po zakończeniu nad nią prac ukaże się w przyszłości jako wersja 2.10.0. W AUR temu wydaniu odpowiada gimp-devel. Obecnie to 2.9.8, ale w tym roku mieliśmy już i 2.9.4 i 2.9.6. Jeśli się pokaże 2.9.10, to i taką tam wersję otrzymamy. Do czasu ogłoszenia nowego "ustabilizowanego" wydania wersji rozwojowej, ostatnią taką wersją będzie 2.9.8. Opiekun takiej paczki w AUR przez cały okres funkcjonowania takiej wersji winien dbać o spełnienie jej zależności. Jeśli odpowiednich paczek (w odpowiednich wersjach) nie ma w repozytoriach, to winien tak skonstruować PKGBUILD by umożliwił zbudowanie programu, także zapewniając również w AUR odpowiednie paczki stanowiące zależności. Zasadniczo też, w przypadku wydania nowej wersji rozwojowej powinien on zapewnić aktualizację PKGBUILDu do tej wersji. Jeśli tego nie zrobi to możemy ją oflagować jako nieaktualną. Inaczej przedstawia się sprawa w przypadku pozostałych wersji rozwojowych (dla uproszczenia będę je zwał "paczkami GIT"). Paczki tego typu nie mają wersji w tym rozumieniu, które wskazałem wyżej. One podlegają mniej lub bardziej intensywnemu, jednakże ciągłemu rozwojowi. Oczywiście tak program w AUR, jak i otrzymana paczka będzie mieć jakiś numer. Niemniej jednak należy sobie uzmysłowić kilka rzeczy. W dalszej części, niech za przykład takiej paczki posłuży gimp-git. Prawidłowo skonstruowana paczka GIT winna automatycznie generować numer wersji podcza"as swej budowy. Dlaczego? Otóż w zasadzie wszystkie paczki z repozytoriów kontroli wersji są budowane w taki sposób, że w pierwszej kolejności dokonywane jest klonowanie repozytorium, czyli pobieranie na komputer lokalny aktualnego w tym momencie stanu ("migawki") repozytorium, gdzie składowany jest kod tej aplikacji. Zwróćmy uwagę - gimp-git nosi w AUR numer wersji 1:2.9.4.1760.g2a7a53b384-1 (pomińmy pierwszą i ostatnią jedynkę, bo nie mają one tu znaczenia). Ta wersja sugerowałaby, że gimp-git jest zasadniczo w wersji 2.9.4, a zatem jest "starszy" od gimp-devel (2.9.8). Nic bardziej mylącego. Otóż wersja jaką widzimy w AUR to jest wersja, która odpowiada wersji, jaka posłużyła opiekunowi tej paczki do stworzenia PKGBUILDu w chwili, gdy zbudował sobie lokalnie taką paczkę. Dzieje się tak dlatego, że pole pkgver w PKGBUILD (linia 7) jest automatycznie generowane na podstawie sklonowanego repozytorium z GIT w dacie budowy paczki. Za wygenerowanie tej wersji odpowiada sekcja pkgver (linie 35-38, a dokładnie w tym przypadku linia 37). Kiedy w sklonowanym repozytorium GIT wydamy to samo polecenie, to otrzymamy również jakiś nr wersji (np. gdybym budował gimp-git podczas pisania tego tekstu, to otrzymałbym program ten w "wersji" 2.9.8.11.g6fee1a413f). Zasadniczo nie istnieje żadna potrzeba "podbijania" numeru wersji paczek GIT w AUR wówczas, gdy pojawia się w kodzie źródłowym jakaś zmiana, która powodowałaby, że owa "wersja" będzie się różnić od wersji, jaka jest widoczna w AUR. PKGBUILD winien być natomiast przebudowany gdy ze względu np. na kompilację wymaga on innych zależności. Może być również podbita jego wersja wówczas, gdy program wymaga przebudowania (np. dlatego, że nowe wersje zależności, jakie pojawiły się w systemie skutkować winny przebudowaniem w ich oparciu również takiego programu GIT i to nawet wówczas, gdy nie uzyskamy w ten sposób nowej "wersji" tego programu). Dobrze, ale co to dla Ciebie oznacza Szanowny Czytelniku? W sumie - proste: w przypadku paczek GIT wyłączny ciężar dbania o ich aktualność i działanie spoczywa na Tobie. Niestety na tym nie koniec. Nie koniec na tym, by dbać o aktualność i działanie samej paczki. Musimy również - niekiedy zadbać o aktualność zależności. Te ostatnie mogą występować jako pakiety znajdujące się w repozytorium, ale mogą również występować jako paczki GIT. Weźmy ów przykład gimp-git. Na podstawie PKGBUILDu, który znajduje się w AUR dzisiaj nie zbudujemy GIMPa. Wersja 2.9.8 wymaga jako zależności m.in. gegl w wersji nie niższej niż 0.3.24 oraz babl w wersji nie niższej niż 0.1.38. W repozytorium Archa (nawet uwzględniając testing) mamy dzisiaj gegl 0.3.20 i babl 0.1.30. Jednocześnie PKGBUILD gimp-git został tak napisany, że z jednej strony jako zależności wymaga babl (czyli paczkę z repozytorium) wskazując na minimalną jej wersję 0.1.27, z drugiej strony wymagając gegl-git w wersji nie niższej niż 0.3.15. Wiemy już, że w takich wersjach albo nie buduje się GIMP 2.9.8. Jednocześnie przy sprawdzaniu zależności, w pierwszym przypadku (babl) stwierdzi, że wymagana wersja jest w systemie (lub w repozytorium) zaś w drugim przypadku (gegl) albo stwierdzi, że jej nie ma i wówczas ją trzeba zbudować z AUR, a w takim przypadku otrzymamy wersję wymaganą przez GIMP 2.9.8, choć niewymaganą przez PKGBUILD gimp-git (bo będzie to wersja 0.3.26.1). Gimp-git zbuduje się jednak, gdy będziemy mieć w systemie zainstalowaną babl-git. W przypadku obu tych zależności w wersjach GIT z jednym wszak zastrzeżeniem. Babl-git zbudowaliśmy przynajmniej w chwili gdy pojawiła się wersja 0.1.30, a w przypadku gegl-git, gdy pojawiła się wersja 0.3.20. Może się jednak zdarzyć, że mamy owe paczki zbudowane pomiędzy wersją 0.1.27 a 0.1.30 (babl) lub 0.3.15 a 0.3.20 (gegl) i w takim przypadku program się nie zbuduje, choć teoretycznie - zgodnie z PKGBUILDem - powinien. Fakt dzisiaj ów PKGBUILD gimp-git jest do zmiany (w ogóle jest do zmiany od samego początku), jednakże tak, czy inaczej wskazuje to na możliwe problemy, jakie użytkownik paczki GIT może napotkać. Pamiętać przy tym również należy, że budując paczki w wersjach innych niż te, które są w repozytorium i zastępując te wersje, wersjami zbudowanymi (obojętnie w jaki sposób - mogą to być jakieś paczki GIT, mogą to być paczki, które zaktualizowaliśmy do innej, stabilnej wersji, ale nowszej niż jest w repozytorium) może okazać się, że wprowadzimy do systemu paczki "zbyt nowe". Wprawdzie właśnie budowana paczka będzie działać, ale inna paczka, której zależnościami były te same paczki, które są zależnościami właśnie zbudowanej paczki będzie wymagać przebudowy (w najlepszym razie), albo zbudowania jej również w wersji GIT, albo z jakimiś patchami itd. itp. W ostateczności po prostu w ogóle działać nie będzie. Pamiętajmy jeszcze, że określona wersja paczki GIT będzie aktualna praktycznie stale, nawet jeśli nowsza, stabilna jej wersja będzie dostępna już w repozytorium. Podsumowując krótko. Paczki GIT to zabawa dla bardzo zaawansowanych użytkowników, którzy są bardzo świadomi swego systemu. Wiedzą o nim wszystko co trzeba wiedzieć by... tak na prawdę, by samemu utrzymywać dystrybucję. Wiesz co i jak oraz kiedy należy zbudować, przebudować? Jakie konsekwencje powoduje wprowadzenie nowych wersji paczek do systemu? Które z programów opartych o paczkę w wersji nowszej w sytemie należy przebudować? Jak ewentualnie nakładać patche umożliwiające przebudowanie paczek w oparciu o nowsze zależności? Kiedy przebudować paczki GIT i czy w ogóle o tym będziecie pamiętać? A to dopiero wierzchołek góry lodowej. Innymi słowy - nie wiesz, nie jesteś świadomy konsekwencji używania paczek GIT to ich po prostu nie używaj. Jeśli z jakiegoś powodu musisz, to sensownie jest rozglądnąć się za jakimś appimage czy flatpak, bo tu mogą się one w istocie lepiej sprawdzić. Nawet jeśli nie będzie dostępnego flatpak, czy appimage w wersji, którą chcecie, to na podstawie dostępnych szkieletów zbudować taką paczkę. Paczki GIT pozostawcie osobom, które doprawdy wiedzą co robią. Zwłaszcza, że ewentualna pomoc dla osób, które ich w systemie używają jest bardzo trudna. Nikt nie tylko nie spodziewa się hiszpańskiej inkwizycji, ale nikt nie spodziewa się, że ktoś przedstawia swój system jako np. Arch, ale de facto jest on Archem wyłącznie w jakimś stopniu, czyli... nim po prostu nie jest.