W AUR niektóre aplikacje są budowane na podstawie źródeł będących w stałym rozwoju. Najczęściej są to aplikacje budowane ze źródeł w GIT, SVN, czy BZR. Zgodnie z zasadami nazywania paczek w Archu (i pochodnych, przy czym nie dotyczy to KaOSa, albowiem tutaj zwykle paczki budowane są wprawdzie z GIT, ale z tagiem jakiegoś wydania przedstabilnego, jak beta, czy RC), mają one nazwy kończące się oznaczeniem repozytorium, z którego pochodzą. Stąd też łatwo jest stwierdzić, że zbudowany w oparciu o takie źródła program, czy biblioteka, jest w wersji rozwojowej. Paczki te zatem, noszą nazwy jak dolphin-git, czy smplayer-svn.
Ich budową może zająć się nawet yaourt, czy pacaur. Nie ma tutaj różnicy, choć poniżej prezentuję uzasadnienie dlaczego mimo wszystko w tym przypadku lepiej stosować tradycyjną metodę budowy paczek w AUR.
Wiedzieć o takich "przepisach" trzeba, że:
- Aplikacja budowana w oparciu o źródła z repozytoriów rozwojowych może, ale wcale nie musi dać się zbudować.
- Fakt, że aplikacja zbudowała się w przeszłości nie oznacza, że następna próba jej budowy będzie udana i odwrotnie, fakt, że nie zbudowała się kiedyś nie stanowi o tym, że nie zbuduje się choćby za chwilę (dlaczego, o tym dalej).
- Co do zasady, aplikacje w wersjach rozwojowych winny współpracować z innymi aplikacjami, czy bibliotekami w wersjach rozwojowych, na podstawie których są tworzone i z którymi mają współpracować; innymi słowy jest to zabawa raczej dla dość dobrze zorientowanego użytkownika, który jest w stanie po kodzie PKGBUILDu ocenić, jakie jego system musi spełnić wymogi, by udało się nie tylko aplikację zbudować, ale również, by działała.
- Aplikacja w wersji rozwojowej, najczęściej jest oparta o wcześniejszą wersję stabilną (o ile takowa istnieje) - nic jednakże nie gwarantuje, że w wersji rozwojowej nie doszło do jakichś regresji i że musi ona działać lepiej od swojej stabilnej poprzedniczki.
- Źródła wersji rozwojowej są... w ciągłym rozwoju; numer wersji, który widzicie przy aplikacjach w AUR (i nie tylko), stanowi wyłącznie informację o tym z jakiej rewizji, czy jaki ostatni commit, zawierała wersja w chwili, gdy PKGBUILD był tworzony. Opiekunowie takich aplikacji w AUR nie mają powodów, by zamieszczać nowe wersje PKGBUILDa jak tylko pojawi się nowy commit. Powinni natomiast zamieszczać wówczas, gdy na podstawie dotychczasowego PKGBUILDu paczki już zbudować nie można.
- Sposób numeracji paczek ze źródeł rozwojowych nie został do końca precyzyjnie określony, często jest to zmienna. Szczególnie tam, gdzie narzędzia kontroli wersji (czyli owe "repozytoria") umożliwiają wprowadzanie wielu gałęzi (branch) czy tagów, możliwe jest posługiwanie się taką gałęzią i/lub tagiem. Oznacza to, że jeśli np. autor PKGBUILD odniósł się do którejś gałęzi, bądź któregoś tagu, to paczka zbudowana w oparciu o taki PKGBUILD będzie odnosić się do źródeł w gałęzi bądź z danego tagu, które zostały określone w PKGBUILD. Konsekwencje są takie, że w repozytoriach mogą istnieć źródła nowszej "wersji". Przykładem może być Otter-Browser, który jest w AUR, który w dalszym ciągu odnosi się do wersji rozwojowej 0.9.04, choć obecna to już 0.9.05. Budując na podstawie tego PKGBUILDu Ottera nie uzyskamy wersji odpowiadającej jego aktualnemu rozwojowi.
- Jak już być może domyślacie się, paczka zbudowana lokalnie przez Was, może się różnić numerem wersji od tej, która figuruje w AUR.
- Skoro programy te są budowane ze źródeł będących w ciągłym rozwoju, to warto jest raz na jakiś czas dokonać samodzielnej aktualizacji takiego programu (yaourt/pacaur itp. o tym nie powiadomią). Nie oznacza to, że mamy to robić co godzinę. Zanim zechcemy zaktualizować taki program, warto jest zerknąć w źródła, jakie commity pojawiły się od czasu gdy zbudowaliśmy, ocenić, czy są one dla nas przydatne, potrzebne, czy wręcz niezbędne i budować dopiero wówczas. Nie istnieje tu żadna reguła kiedy należy dokonywać aktualizacji takich paczek - wówczas, kiedy uznacie, że jest to potrzebne.
- Stosowanie aplikacji w wersjach rozwojowych ma swój sens przede wszystkim wówczas, gdy w owych wersjach pojawiają się jakieś funkcjonalności, usunięto jakieś błędy itp., co powodowało, że program, z którego chcecie korzystać nie bardzo nadawał się do tego. Warto przy tym zaznaczyć, że częstokroć lepiej jest nałożyć określoną łatkę (jeden bądź więcej commitów) na stabilne źródła (o ile się da), niż budować wersje rozwojowe. Lepiej, co nie oznacza prościej, albowiem trzeba wiedzieć jak sporządzić łatkę, albo wyszukać taką (co wcale nie jest takie proste; nikt bowiem owych łatek nie publikuje). Pewną podpowiedzią można zauważyć w dystrybucjach "matuzalemowych", które zwykle istnieją przez dłuższy czas w tych samych wersjach aplikacji, na które są nakładane właśnie takie patche (szczególnie bezpieczeństwa). Dotyczy to np. RedHata, Debiana, serwerowego Ubuntu, czy Slackware'a oraz Gentoo. Patche takie również bywają do znalezienia w materiałach Fedory i OpenSUSE.
- Jeśli jakaś aplikacja ze źródeł rozwojowych oparta jest o inną aplikację, czy biblioteki z takich samych źródeł, to najpierw musimy zbudować ową aplikację (bibliotekę) a dopiero potem budować aplikację docelową. Próba budowy aplikacji ze źródeł rozwojowych w oparciu o stabilne źródła zależności (jeśli co innego nie wynika z PKGBUILDu), to jest zabawa dla dość mocno zaawansowanych użytkowników i nie da się dać jednej recepty.
- Jeśli są jakieś repozytoria, w których oferowana jest wersja rozwojowa jakichś aplikacji, to warto pamiętać o tym, co wyżej o numerach wersji i korzystać z takich, które są w miarę rozsądnie prowadzone i przez zaufanych opiekunów takiego repozytorium. Przykładem może być repozytorium [mesa-git], choć fakt, że jest ono budowane przez jednego z opiekunów Archa nie ustrzeże Was w 100% przed ewentualnością zepsucia systemu, po jakiejś aktualizacji (zwłaszcza, że to akurat dotyczy Mesy).
- Paczki znajdujące się w oficjalnych repozytoriach w stabilnej wersji najczęściej w PKGBUILD w żaden sposób nie odnoszą się do swego odpowiednika ze źródeł rozwojowych. Stąd też po pierwsze nie wykryją, że są zbudowane z nowszych źródeł od tej z GIT, ale co gorsza mogą nie mieć informacji o tym, że zastępują, są w konflikcie, bądź dostarczają tej samej aplikacji, co wersja GIT. Próba instalacji zakończy się zatem wyłącznie stwierdzeniem, że określony plik znajduje się już w systemie plików. Chcąc zatem przejść na wersję stabilną, najczęściej będziecie musieli odinstalować aplikację ze źródeł rozwojowych i zainstalować w jej miejsce ze stabilnych.
Teraz zaś, obiecany TIP dotyczący budowania paczek ze źródeł rozwojowych.
Otóż, mimo tego, że wszelkie "wspomagacze" pacmana w budowie z AUR winny sobie poradzić z budową takich paczek, nawet jeśli będą potrzebowały zbudować jakieś paczki wcześniej, to nie pozostawią nigdzie informacji o tym, co zostało zbudowane. Będzie zagmatwane, zatem podam na przykładzie:
- w AUR znajdują się przepisy, które są oznaczone numerem wersji XXX.YYYY,
- w oparciu o te przepisy, zbudowaliście paczkę, która została zainstalowana w systemie; ze względu na to, że w chwili budowy w repozytorium kontroli wersji znajdowały się już nowsze źródła, Wasza paczka nosi numer XXY.ABCD,
- za jakiś czas postanowiliście zaktualizować paczkę, albowiem wydawało się Wam, że długi czas upłynął i jakieś zmiany będą, do czego postanowiliście wykorzystać yaourt,
- yaourt znalazł w AUR przepis na paczkę w wersji XXX.YYYY, w którym znajduje się zmienna wersji, buduje zatem ją pomimo tego, że w Waszym systemie znajduje się paczka XXY.ABCD, na koniec procesu budowy okazać się może, że od czasu ostatniej kompilacji nie zaszły żadne zmiany w repozytorium, wobec powyższego yaourt zbudował paczkę w wersji XXY.ABCD, którą chce ponownie zainstalować.
Szkoda czasu? No, chyba tak.
Lepszym sposobem zatem, zwłaszcza wówczas, gdy jesteśmy zdecydowani na użytkowanie określonej aplikacji w wersji rozwojowej (przynajmniej przez pewien czas), powinni skorzystać z tradycyjnego (czyli za pomocą makepkg) sposobu budowania aplikacji i pozostawić sobie jej źródła (a w zasadzie to sklonowaną informację z repozytorium) oraz zbudowaną paczkę. Wówczas, ponownie próbując stworzyć paczkę za pomocą makepkg, zostaniemy poinformowani, czy mamy zbudowaną już paczkę w oparciu o te same źródła, czy też nie. W pierwszym przypadku makepkg pokaże, że można mimo wszystko wymusić budowę, w drugim przeprowadzi kompilację.
