Instalujemy paczki z nieoficjalnych repozytoriów
No właśnie: instalujemy? Ten wpis nie będzie w ogóle o tym, jak tego dokonać (jest to opisane w wiki Archa dość dokładnie), ale o tym, czy w ogóle warto to robić, kiedy i jakie niesie konsekwencje.
Lektura różnych forów czy blogów związanych z Archem, Manjaro i innymi dystrybucjami korzystającymi z rodowodu Archa pozwala na stwierdzenie, że niektóre osoby, w określonych sytuacjach, mają chęć dodawania do pacman.conf wpisów do tzw. nieoficjalnych repozytoriów. Tych ostatnich cała masa. Kusi i nęci zatem zamiast budowania czegoś ze źródeł korzystając z PKGBUILDu szybka instalacja programu z repozytorium.
Fakt, jest to dobre rozwiązanie, szczególnie dla programów, które się kompilują wieczność. Fakt, ale wyłącznie wówczas, gdy mamy zaufanie do twórcy i opiekuna takiego repozytorium.
Czy jest to jednak dobre rozwiązanie? Powiedzmy tak: i tak i nie. Dla świadomego użytkownika - jak najbardziej. Zwykle bowiem wie jakie i dlaczego repozytorium dodał, co chciał w ten sposób osiągnąć i przede wszystkim - wie jakie paczki mu się z tego repozytorium instalują, jak dowiedzieć się jakie paczki ma z określonego repozytorium oraz potrafi dojść do przyczyn problemów z aktualizacją systemu, konfliktującymi pakietami/plikami, zepsutymi zależnościami itd. Wie w końcu co zrobić w sytuacji, gdy system nie bardzo chce dalej pracować, aktualizować się itd.
Spora część użytkowników wprowadza jednak nieoficjalne repozytoria nie mając pojęcia co robi. Dotyczy to szczególnie osób, które z Archem, czy Manjaro (i pochodnymi) mają do czynienia bardzo krótki czas. Wielu z nich wprowadza te repozytoria bo chce mieć nowsze oprogramowanie (np. wówczas, gdy z jakichś powodów paczki w repozytoriach nie są aktualizowane pomimo tego, że oprogramowanie jest dostępne już w nowszej wersji - tak się działo niedawno np. z MATE) albo chce na siłę utrzymać oprogramowanie, które zostało porzucone w repozytoriach (tak jest w dalszym ciągu z KDE4).
Pamiętajcie zatem, że paczki umieszczane w repozytoriach nieoficjalnych mogą być budowane w inny sposób, niż te dostępne w repozytoriach danej dystrybucji. Przede wszystkim mogą być budowane na innych skryptach, niż te, które są używane w systemie. To oznacza, że mogą one mieć inaczej ustawione zależności. Mogą się w tych repozytoriach pojawić również dodatkowe paczki, które nie są w ogóle dostępne w repozytoriach oficjalnych, powiązane jakoś z tymi, które są w repozytoriach nieoficjalnych. Mogą w końcu jakieś źródła być inaczej paczkowane i zamiast jednej paczki będziemy mieć kilka lub odwrotnie. Jeśli osoba odpowiedzialna za budowę tych paczek w sposób właściwy ustawiła konflikty, informacje co dana paczka dostarcza, co zastępuje, to jeszcze pół biedy. Bardzo często jednakże otrzymujemy paczki zbudowane z przynajmniej jedną wadliwą informacją niesioną przez skrypty służące do budowy paczki w takim repozytorium.
I zaczyna być problem.
Dla przykładu weźmy jakąś "nowszą" wersję programu, od tej, która znajduje się w systemie. Zdarzy się często, że po jakimś czasie oprogramowanie w repozytoriach oficjalnych zostanie zaktualizowane. Ba, często będzie też aktualniejsze od oprogramowania w owych repozytoriach nieoficjalnych. Jednakże próba aktualizacji systemu prowadzić będzie do ciągu nierozwiązywalnych zależności, a w efekcie do braku możliwości zaktualizowania jakiegokolwiek programu (pamiętajmy, że Arch wspiera wyłącznie całościową aktualizację systemu, a nie pojedynczej paczki).
Oczywiście istnieje możiwość "odwrócenia" zaistniałej sytuacji i doprowadzenie do aktualizacji systemu. Zanim jednak przedstawię co należy wówczas zrobić, zastanówmy się nad postawionym na wstępie pytaniem. Oczywiście przedstawię wyłącznie swoje zdanie na ten temat (niby czyje miałbym przedstawiać). Nie uzurpuję sobie prawa do obiektywnych w tym zakresie opinii.
W moim przekonaniu reguła jest dokładnie taka sama, jak w przypadku instalowania czegokolwiek z pomocą AUR: jeśli nie wiesz, nie jesteś świadomy tego co robisz - nie rób. Jeśli nie wiesz w jaki sposób budowane są programy w takim repozytorium - nie wprowadzaj go do systemu. Jeśli nie wiesz jakie konsekwencje niesie za sobą instalacja paczek z takiego repozytorium - nie jest ono dla Ciebie. I w końcu - jeśli nie znasz na tyle Archa, by dać sobie radę z ewentualnymi problemami aktualizacyjnymi w przyszłości - nie wprowadzaj takich repozytoriów do systemu. Tylko i wyłącznie wówczas możesz je dodać, gdy stwierdzisz, że przedstawione wyżej problemy nie są Ci obce, dasz sobie radę w przyszłości, możesz się pokusić o dodanie nieoficjalnych repozytoriów do systemu i korzystać z nich. Inaczej sam się prosisz o problemy, destabilizację, a być może nawet - zepsucie systemu. Nadto jeszcze - w przypadku instalacji paczek w wersjach nieoficjalnych musisz trzymać rękę na pulsie i wiedzieć kiedy pojawi się nowa, już stabilna wersja takiego programu i podjąć odpowiednie kroki. Dla przykładu, część oprogramowania występującego w ramach tzw. kde-applications daje się już budować na KF5 i nadaje się do codziennego używania. Niemniej jednak w oficjalnych wydaniach tego zbioru aplikacji nie występują one jeszcze w takich wersjach. To nowe oprogramowanie często - dla odróżnienia od wersji w repozytoriach - miewa (podobnie jak ma to miejsce w AUR) inne nazwy paczek (np. okular i okular-frameworks-git). Gdy wejdzie już stabilne oprogramowanie do repozytoriów, taka paczka może - i najczęściej tak się stanie - pozostać w wersji "starszej", niż paczka oficjalna (w przypadku omawianego tu oprogramowania KDE dzieje się tak zwykle dlatego, że paczki *-kf5/frameworks itp. są budowane z gałęzi noszącej taką nazwę, która w przypadku wydania oficjalnej wersji opartej o KF5 jest łączona z gałęzią master; dotychczasowa gałąź nadal istnieje, ale nie jest już aktualizowana, bowiem akutalizacji podlega wyłącznie gałąź master; prześledźcie sobie np. rozwój gwenview w GIT KDE).
Jeśli jednak mimo wszystko zdecydujesz się na dodanie nowego repozytorium, to musisz wiedzieć co robić, gdy system przestaje się aktualizować, zaczynają występować problemy z instalacją paczek w systemie itd. itp.
Przyjąć należy, że deweloperzy tak Archa, jak i Manjaro (i pozostałych forków) wiedzą co robią i przynajmniej starają się dbać o to, by aktualizacja systemu wykonywana w dowolnym momencie była możliwa. Podobnie ma być możliwość dodania w dowolnym momencie jakiegoś programu do systemu i nie ma prawa wystąpić sytuacja, w której występuje jakiś problem z zależnościami. Gdy zatem próba aktualizacji, bądź instalacji jakiegoś programu powoduje informacje o braku możliwości ich dokonania, to jest to znak, że prawdopodobnie nasz system nie jest w pełni kompatybilny z oficjalnymi repozytoriami. Przyczyny - co do zasady - mogą być dwie (wykluczam dla ułatwienia błąd po stronie deweloperów):
- albo w systemie mamy jakieś oprogramowanie, które nie jest już dalej wspierane przez Archa (tak np. było z chwilą porzucenia KDE4 i przejścia wyłącznie na Plasma 5; ktoś, kto ma jeszcze KDE4 będzie miał problem z aktualizacją systemu),
- albo problem jest wywołany przez paczki wprowadzone do systemu spoza oficjalnych repozytoriów (może to również dotyczyć paczek zbudowanych z AUR).
Pierwsza sytuacja nie jest przedmiotem niniejszego wpisu, niemniej jednak zawsze należy ją rozważyć i wykluczyć. Z pomocą winny przyjść informacje, jakie pojawiają się na głównej stronie Archa (i Manjaro, a także innych dystrybucji).
Jeśli wykluczymy pierwszy z możliwych problemów, przyczyną braku możliwości aktualizacji systemu (czy nawet dodania pojedynczej paczki) szukać musimy raczej w owych "obcych" paczkach. Najczęściej objawi się to wpisem, że pacman nie mógł dokonać aktualizacji (instalacji) albowiem napotkał problem z zależnościami lub, że nie mógł zainstalować jakiejś paczki, albowiem jakieś pliki istnieją już w systemie.
Jeśli instalowane obecnie paczki są również w repozytoriach nieoficjalnych, które podłączyliśmy do systemu, to najprawdopodobniej tu leży przyczyna. W pierwszej kolejności należy zatem zewidencjonować paczki, które są zainstalowane z takiego repozytorium nieoficjalnego. Pomocne okazać się może polecenie:
pacman -Sl nazwa_repozytorium
Po jego wydaniu pojawi się lista paczek w repozytorium, ich wersji oraz informacja, czy dana paczka jest zainstalowana w systemie. Jeśli pośród tych zainstalowanych paczek znajdziemy choćby jedną, która bądź to ma być zainstalowana obecnie, bądź to "należy" do grupy oprogramowania, które chcemy instalować, to sugerowałbym w pierwszej kolejności odinstalowanie wszystkich tych paczek. Nawet bowiem jeśli paczka z repozytorium oficjalnego będzie mieć dokładnie taką samą nazwę i taką samą wersję jak paczka z repozytorium nieoficjalnego, to może się ona różnić skryptem, który ją zbudował i istniejącymi w nim informacjami np. o zależnościach. Oczywiście można sobie zautomatyzować odinstalowanie takich paczek. Polecam jednak ręczne wpisanie listy tych paczek, które wymagają odinstalowania (dbajmy przy tym w pierwszej kolejności o odinstalowanie jakichś metapaczek, albowiem to one są bardzo często powodem problemów). Dlaczego "ręczne", a nie automatyczne? Bowiem - może mi się wydaje - ale mam nad tym procesem większą kontrolę. Łatwiej widzę i ogarniam co się w systemie dzieje. Automat jest fajny, pod jednym warunkiem - robi dokładnie to co zostało zaplanowane i dokładnie to i tylko to, czego od niego chcę i oczekuję. Osobiście słabo ufam nawet najlepszym automatyzacjom działań na paczkach.
Po odinstalowaniu paczek z repozytoriów nieoficjalnych (oczywiście tych kolidujących, uniemożliwiających aktualizację, czy instalację), należy usunąć (bądź zakomentować) takie repozytorium w /etc/pacman.conf i doknać synchronizacji repozytoriów oraz akutalizacji systemu. Przed aktualizacją (a po synchronizacji repozytoriów), warto jeszcze wykonać polecenie:
pacman -Qm
Da ono nam odpowiedź na pytanie jakie paczki mamy zainstalowane spoza repozytoriów (czyli wyświetli wszystkie te paczki, których nie ma w repozytoriach umieszczonych w /etc/pacman.conf, w tym także te instalowane z AUR). Takim paczkom również należy się przyglądnąć. Tu pomocne będzie polecenie:
pacman -Qi nazwa_paczki
W wyniku jego działania dowiemy się m.in. jakich zależności wymaga określona paczka. Pamiętajmy jednak, że w Archu wyświetlane są co do zasady wyłącznie te zależności, które są wymagane bezpośrednio przez tę paczkę (np. jesli jakaś paczka należąca do KDE wymaga jakiejś paczki z KF5, to nie zostaną już wyświetlone zależności owej paczki z KF5, jak np. należące do Qt5, choć te ostatnie są wymagane do prawidowego działania paczki poddanej inspekcji). W ten sposób niekiedy uda się również wyśledzić, co jest przyczyną braku możliwości aktualizacji systemu.
Powinno działać.
Czy stosować zatem, czy nie nieoficjalne repozytoria - pozostawiam Wam, łącznie z odpowiedzą na pytanie na ile to jest bezpieczne.
Lektura różnych forów czy blogów związanych z Archem, Manjaro i innymi dystrybucjami korzystającymi z rodowodu Archa pozwala na stwierdzenie, że niektóre osoby, w określonych sytuacjach, mają chęć dodawania do pacman.conf wpisów do tzw. nieoficjalnych repozytoriów. Tych ostatnich cała masa. Kusi i nęci zatem zamiast budowania czegoś ze źródeł korzystając z PKGBUILDu szybka instalacja programu z repozytorium.
Fakt, jest to dobre rozwiązanie, szczególnie dla programów, które się kompilują wieczność. Fakt, ale wyłącznie wówczas, gdy mamy zaufanie do twórcy i opiekuna takiego repozytorium.
Czy jest to jednak dobre rozwiązanie? Powiedzmy tak: i tak i nie. Dla świadomego użytkownika - jak najbardziej. Zwykle bowiem wie jakie i dlaczego repozytorium dodał, co chciał w ten sposób osiągnąć i przede wszystkim - wie jakie paczki mu się z tego repozytorium instalują, jak dowiedzieć się jakie paczki ma z określonego repozytorium oraz potrafi dojść do przyczyn problemów z aktualizacją systemu, konfliktującymi pakietami/plikami, zepsutymi zależnościami itd. Wie w końcu co zrobić w sytuacji, gdy system nie bardzo chce dalej pracować, aktualizować się itd.
Spora część użytkowników wprowadza jednak nieoficjalne repozytoria nie mając pojęcia co robi. Dotyczy to szczególnie osób, które z Archem, czy Manjaro (i pochodnymi) mają do czynienia bardzo krótki czas. Wielu z nich wprowadza te repozytoria bo chce mieć nowsze oprogramowanie (np. wówczas, gdy z jakichś powodów paczki w repozytoriach nie są aktualizowane pomimo tego, że oprogramowanie jest dostępne już w nowszej wersji - tak się działo niedawno np. z MATE) albo chce na siłę utrzymać oprogramowanie, które zostało porzucone w repozytoriach (tak jest w dalszym ciągu z KDE4).
Pamiętajcie zatem, że paczki umieszczane w repozytoriach nieoficjalnych mogą być budowane w inny sposób, niż te dostępne w repozytoriach danej dystrybucji. Przede wszystkim mogą być budowane na innych skryptach, niż te, które są używane w systemie. To oznacza, że mogą one mieć inaczej ustawione zależności. Mogą się w tych repozytoriach pojawić również dodatkowe paczki, które nie są w ogóle dostępne w repozytoriach oficjalnych, powiązane jakoś z tymi, które są w repozytoriach nieoficjalnych. Mogą w końcu jakieś źródła być inaczej paczkowane i zamiast jednej paczki będziemy mieć kilka lub odwrotnie. Jeśli osoba odpowiedzialna za budowę tych paczek w sposób właściwy ustawiła konflikty, informacje co dana paczka dostarcza, co zastępuje, to jeszcze pół biedy. Bardzo często jednakże otrzymujemy paczki zbudowane z przynajmniej jedną wadliwą informacją niesioną przez skrypty służące do budowy paczki w takim repozytorium.
I zaczyna być problem.
Dla przykładu weźmy jakąś "nowszą" wersję programu, od tej, która znajduje się w systemie. Zdarzy się często, że po jakimś czasie oprogramowanie w repozytoriach oficjalnych zostanie zaktualizowane. Ba, często będzie też aktualniejsze od oprogramowania w owych repozytoriach nieoficjalnych. Jednakże próba aktualizacji systemu prowadzić będzie do ciągu nierozwiązywalnych zależności, a w efekcie do braku możliwości zaktualizowania jakiegokolwiek programu (pamiętajmy, że Arch wspiera wyłącznie całościową aktualizację systemu, a nie pojedynczej paczki).
Oczywiście istnieje możiwość "odwrócenia" zaistniałej sytuacji i doprowadzenie do aktualizacji systemu. Zanim jednak przedstawię co należy wówczas zrobić, zastanówmy się nad postawionym na wstępie pytaniem. Oczywiście przedstawię wyłącznie swoje zdanie na ten temat (niby czyje miałbym przedstawiać). Nie uzurpuję sobie prawa do obiektywnych w tym zakresie opinii.
W moim przekonaniu reguła jest dokładnie taka sama, jak w przypadku instalowania czegokolwiek z pomocą AUR: jeśli nie wiesz, nie jesteś świadomy tego co robisz - nie rób. Jeśli nie wiesz w jaki sposób budowane są programy w takim repozytorium - nie wprowadzaj go do systemu. Jeśli nie wiesz jakie konsekwencje niesie za sobą instalacja paczek z takiego repozytorium - nie jest ono dla Ciebie. I w końcu - jeśli nie znasz na tyle Archa, by dać sobie radę z ewentualnymi problemami aktualizacyjnymi w przyszłości - nie wprowadzaj takich repozytoriów do systemu. Tylko i wyłącznie wówczas możesz je dodać, gdy stwierdzisz, że przedstawione wyżej problemy nie są Ci obce, dasz sobie radę w przyszłości, możesz się pokusić o dodanie nieoficjalnych repozytoriów do systemu i korzystać z nich. Inaczej sam się prosisz o problemy, destabilizację, a być może nawet - zepsucie systemu. Nadto jeszcze - w przypadku instalacji paczek w wersjach nieoficjalnych musisz trzymać rękę na pulsie i wiedzieć kiedy pojawi się nowa, już stabilna wersja takiego programu i podjąć odpowiednie kroki. Dla przykładu, część oprogramowania występującego w ramach tzw. kde-applications daje się już budować na KF5 i nadaje się do codziennego używania. Niemniej jednak w oficjalnych wydaniach tego zbioru aplikacji nie występują one jeszcze w takich wersjach. To nowe oprogramowanie często - dla odróżnienia od wersji w repozytoriach - miewa (podobnie jak ma to miejsce w AUR) inne nazwy paczek (np. okular i okular-frameworks-git). Gdy wejdzie już stabilne oprogramowanie do repozytoriów, taka paczka może - i najczęściej tak się stanie - pozostać w wersji "starszej", niż paczka oficjalna (w przypadku omawianego tu oprogramowania KDE dzieje się tak zwykle dlatego, że paczki *-kf5/frameworks itp. są budowane z gałęzi noszącej taką nazwę, która w przypadku wydania oficjalnej wersji opartej o KF5 jest łączona z gałęzią master; dotychczasowa gałąź nadal istnieje, ale nie jest już aktualizowana, bowiem akutalizacji podlega wyłącznie gałąź master; prześledźcie sobie np. rozwój gwenview w GIT KDE).
Jeśli jednak mimo wszystko zdecydujesz się na dodanie nowego repozytorium, to musisz wiedzieć co robić, gdy system przestaje się aktualizować, zaczynają występować problemy z instalacją paczek w systemie itd. itp.
Przyjąć należy, że deweloperzy tak Archa, jak i Manjaro (i pozostałych forków) wiedzą co robią i przynajmniej starają się dbać o to, by aktualizacja systemu wykonywana w dowolnym momencie była możliwa. Podobnie ma być możliwość dodania w dowolnym momencie jakiegoś programu do systemu i nie ma prawa wystąpić sytuacja, w której występuje jakiś problem z zależnościami. Gdy zatem próba aktualizacji, bądź instalacji jakiegoś programu powoduje informacje o braku możliwości ich dokonania, to jest to znak, że prawdopodobnie nasz system nie jest w pełni kompatybilny z oficjalnymi repozytoriami. Przyczyny - co do zasady - mogą być dwie (wykluczam dla ułatwienia błąd po stronie deweloperów):
- albo w systemie mamy jakieś oprogramowanie, które nie jest już dalej wspierane przez Archa (tak np. było z chwilą porzucenia KDE4 i przejścia wyłącznie na Plasma 5; ktoś, kto ma jeszcze KDE4 będzie miał problem z aktualizacją systemu),
- albo problem jest wywołany przez paczki wprowadzone do systemu spoza oficjalnych repozytoriów (może to również dotyczyć paczek zbudowanych z AUR).
Pierwsza sytuacja nie jest przedmiotem niniejszego wpisu, niemniej jednak zawsze należy ją rozważyć i wykluczyć. Z pomocą winny przyjść informacje, jakie pojawiają się na głównej stronie Archa (i Manjaro, a także innych dystrybucji).
Jeśli wykluczymy pierwszy z możliwych problemów, przyczyną braku możliwości aktualizacji systemu (czy nawet dodania pojedynczej paczki) szukać musimy raczej w owych "obcych" paczkach. Najczęściej objawi się to wpisem, że pacman nie mógł dokonać aktualizacji (instalacji) albowiem napotkał problem z zależnościami lub, że nie mógł zainstalować jakiejś paczki, albowiem jakieś pliki istnieją już w systemie.
Jeśli instalowane obecnie paczki są również w repozytoriach nieoficjalnych, które podłączyliśmy do systemu, to najprawdopodobniej tu leży przyczyna. W pierwszej kolejności należy zatem zewidencjonować paczki, które są zainstalowane z takiego repozytorium nieoficjalnego. Pomocne okazać się może polecenie:
pacman -Sl nazwa_repozytorium
Po jego wydaniu pojawi się lista paczek w repozytorium, ich wersji oraz informacja, czy dana paczka jest zainstalowana w systemie. Jeśli pośród tych zainstalowanych paczek znajdziemy choćby jedną, która bądź to ma być zainstalowana obecnie, bądź to "należy" do grupy oprogramowania, które chcemy instalować, to sugerowałbym w pierwszej kolejności odinstalowanie wszystkich tych paczek. Nawet bowiem jeśli paczka z repozytorium oficjalnego będzie mieć dokładnie taką samą nazwę i taką samą wersję jak paczka z repozytorium nieoficjalnego, to może się ona różnić skryptem, który ją zbudował i istniejącymi w nim informacjami np. o zależnościach. Oczywiście można sobie zautomatyzować odinstalowanie takich paczek. Polecam jednak ręczne wpisanie listy tych paczek, które wymagają odinstalowania (dbajmy przy tym w pierwszej kolejności o odinstalowanie jakichś metapaczek, albowiem to one są bardzo często powodem problemów). Dlaczego "ręczne", a nie automatyczne? Bowiem - może mi się wydaje - ale mam nad tym procesem większą kontrolę. Łatwiej widzę i ogarniam co się w systemie dzieje. Automat jest fajny, pod jednym warunkiem - robi dokładnie to co zostało zaplanowane i dokładnie to i tylko to, czego od niego chcę i oczekuję. Osobiście słabo ufam nawet najlepszym automatyzacjom działań na paczkach.
Po odinstalowaniu paczek z repozytoriów nieoficjalnych (oczywiście tych kolidujących, uniemożliwiających aktualizację, czy instalację), należy usunąć (bądź zakomentować) takie repozytorium w /etc/pacman.conf i doknać synchronizacji repozytoriów oraz akutalizacji systemu. Przed aktualizacją (a po synchronizacji repozytoriów), warto jeszcze wykonać polecenie:
pacman -Qm
Da ono nam odpowiedź na pytanie jakie paczki mamy zainstalowane spoza repozytoriów (czyli wyświetli wszystkie te paczki, których nie ma w repozytoriach umieszczonych w /etc/pacman.conf, w tym także te instalowane z AUR). Takim paczkom również należy się przyglądnąć. Tu pomocne będzie polecenie:
pacman -Qi nazwa_paczki
W wyniku jego działania dowiemy się m.in. jakich zależności wymaga określona paczka. Pamiętajmy jednak, że w Archu wyświetlane są co do zasady wyłącznie te zależności, które są wymagane bezpośrednio przez tę paczkę (np. jesli jakaś paczka należąca do KDE wymaga jakiejś paczki z KF5, to nie zostaną już wyświetlone zależności owej paczki z KF5, jak np. należące do Qt5, choć te ostatnie są wymagane do prawidowego działania paczki poddanej inspekcji). W ten sposób niekiedy uda się również wyśledzić, co jest przyczyną braku możliwości aktualizacji systemu.
Powinno działać.
Czy stosować zatem, czy nie nieoficjalne repozytoria - pozostawiam Wam, łącznie z odpowiedzą na pytanie na ile to jest bezpieczne.
"która w przypadku wydania oficjalnej wersji opartej o KF5 jest łączona z gałęzią master; dotychczasowa gałąź nadal istnieje, ale nie jest już aktualizowana, bowiem akutalizacji podlega wyłącznie gałąź master; prześledźcie sobie np. rozwój gwenview w GIT KDE)."
OdpowiedzUsuńCóż, nie zawsze. Zdarzają się wyjątki, tak jak w przypadku k3b. Gałąź "kf5" została usunięta.
Analogicznie jest w przypadku libkcddb :D
OdpowiedzUsuńI wielu innych. To co opisałem nie jest zasadą. Napisałem, by osoby, które budują z GIT z branch kf5 lub frameworks nie były zdziwione, że w pewnym momencie wersja "master" jest "wyższa". Po prostu trzeba sprawdzać.
OdpowiedzUsuń