Jak nie używać IgnorePkg
Pacman - przynajmniej wg mnie - jest bardzo dobrym menedżerem pakietów. Jest też - za pomocą pliku /etc/pacman.conf - dość konfigurowalny.
Jedną z opcji, jaką możemy tam ustawić, jest ignorowanie aktualizacji paczki. Za funkcję tą odpowiada pole IgnorePkg. Tu możemy wpisywać nazwy paczek, których nie chcemy aktualizować.
Teraz muszę coś przypomnieć. Arch Linux jest tak pomyślany, że domyślnym i jedynie wspieranym sposobem aktualizacji, jest aktualizacja globalna. Aktualizujemy zatem cały system, a nie poszczególną paczkę. Także do wyjątków winna należeć systuacja, w której aktualizacja systemu nie obejmuje jakiejś paczki. O prawidłowość działania tego mechanizmu dbają opiekunowie systemu. Czasem jest lepiej - czasem gorzej, ale zaangażowania w prawidłowość działania systemu jako całości, nie możemy odmówić.
Powrócę zatem do ignorowania aktualizacji poszczególnej paczki. Jak wspomniałem należy to traktować jako wyjątek. Systemu z niezaktualizowaną paczką opiekunowie Archa nie przewidzieli. Ignorowanie aktualizacji jest natomiast przez niektórych użytkowników traktowane jako remedium na kłopoty z działaniem systemu. Nic w tym dziwnego - sposób jest nawet opisany w wiki Archa. Zastanówmy się jednakże, czy w każdym przypadku jest to wybór paczki przeznaczonej do ignorowania podczas aktualizacji systemu jest prawidłowy.
Przypomnijmy sobie jak jest konstruowany linux. Jakaś aplikacja zwykle czerpie z czegoś (bibliotek), które są dostępne również innym programom. Aplikacja X jest zatem zależna od biblioteki Y. Ta natomiast może być zależna od jeszcze innej itd. W Archu informacje o zależnościach - często - przekazywane są jedynie jako nazwy programów, bez podania wersji (fakt zdarzają się i takie sytuacje, ale sporadycznie). System wszak ma być zawsze zaktualizowany jako całość. Pół biedy zatem, jeśli do pominięcia przy aktualizacji wybierzemy jakąś paczkę, która jest niezależna od innych. Pół biedy - jeśli wybierzemy taką, która prawidłowo działa w oparciu o inną, jednakże w dość dowolnej wersji. Gorzej, jeśli do ignorowania przeznaczymy paczkę "ze środka".
Oczywiście przykładem będzie nowe środowisko od KDE. Jak wiecie składa się ono z 2 elementów: bibliotek, zwanych KDE Frameworks 5 oraz samego środowiska Plasma 5. Owe biblioteki budowane są w pewien hierarchiczny sposób. Do prawidłowego działania wszystkie wymagają oczywiście Qt 5 w odpowiedniej wersji minimalnej (obecnie - ze względu na Debiana jest to wersja, która jest w nim dostępna). Komponenty składające się na KF5 podzielone są na 3 poziomy (en. tier). Na poziom pierwszy składają się te elementy KF5, które nie są zależne od innych elementów KF5 oraz budowane wyłącznie o zależności w Qt5. Poziom 2 to elementy, których zależnościami są wyłącznie elementy z Poziomu 1 (oczywiście dalszymi zależnościami będą ich zależności). Poziom 3 to elementy zależne od tych, które należą do Poziomu 1 i 2. Oczywiście Poziom 2 zależy od Poziomu 1 w odpowiedniej wersji i podobnie Poziom 3 od odpowiedniej wersji Poziomu 1 i 2. Całość KF5 jest pomyślana natomiast w taki sposób, by zawsze działała jako całość. Wszystkie jej komponenty winny być w tej samej wersji. Elementów wyższych poziomów nie jesteśmy w stanie zbudować zarówno w nowszej, jak i w starszej wersji w stosunku do elementów z niższego poziomu (i to nawet, jeśli się zdarzy, że jakiś element nie został pomiędzy wydaniami zmieniony).
Podobnie dzieje się z Plasmą, która również budowana jest w oparciu o określoną wersję minimalną. Dla przykładu minimalne wymagania nadchodzącego wydania 5.8 to KF 5.26 oraz Qt 5.6.1. Są to wymagania minimalne, które oznaczają, że Plasma 5.8 będzie pracować z KF 5.26 oraz Qt 5.6.1, ale będzie pracować również z KF i Qt w wersjach wyższych niż te deklarowane, natomiast nie ma żadnej gwarancji prawidłowego działania z KF i Qt w wersji niższej. Gdybyśmy budowali to środowisko we własnym zakresie ze źródeł, to musimy mu zapewnić elementy, na których jest budowane przynajmniej w tych minimalnych wersjach. Inaczej budowa się nie powiedzie.
Wrócę do Archa i przypomnę to co napisałem na początku: Arch wspiera wyłącznie pełną aktualizację systemu, a nie aktualizację poszczególnych paczek w nim zawartych oraz zależnością jest "nazwa" określonej paczki, ale już - najczęściej - bez podania jej wersji. Powoduje to, że Archa można oszukać. Można sobie "skonstruować" taki system, w którym będą istniały wszystkie komponenty wymagane przez system, ale niekoniecznie już wszystkie one będą w tej samej (czyt. najnowszej) wersji.
Wprowadzanie do linii IgnorePkg poszczególnych paczek jest typowym zachowaniem osób, które na siłę chcą np. pozostawić sobie starszą wersję jakiegoś oprogramowania bądź też uznają, że jakaś paczka powoduje komplikacje w systemie. Nawet nie dochodząc tego, czy przez przypadek problem nie leży w niewłaściwej konfiguracji systemu.
Niestety, w przypadku takim jak opisany wyżej - ignorowanie aktualizacji poszczególnych paczek KF5 to prośba o destabilizację pracy całego środowiska. Im więcej tych paczek tam się znajdzie, tym bardziej praca w Plasmie będzie przypominać grę na loterii. To może "działać" (tzn. może nam się wydawać, że działa), ale wcale nie musi. Jeśli "działa", to oznacza wyjątkową odporność Plasmy.
Oczywiście opisany tu problem nie dotyczy wyłącznie Plasmy i KF5. Spotkamy się z nim praktycznie w każdym większym środowisku, które są pomyślane właśnie w taki sposób, by były budowane jako całość (w jednej wersji), na podstawie określonych bibliotek w określonych wersjach, które w tych samych wersjach winny być w systemie.
Wracając do środowiska KDE. Jeśli już musimy z jakichś przyczyn "zastabilizować" jego element, to wymaga to od nas odpowiedniej wiedzy i roztropności. KF5 winno być zawsze w tej samej wersji, zatem jeśli musimy mieć jakiś jego element w wersji wcześniejszej niż w repozytorium, to nie należy wpisywać tego elementu do IgnorePkg, ale całą grupę kf5 oraz kf5-aids przeznaczyć jako wyłączoną z aktualizacji i umieścić obie w IgnoreGroup. Jednocześnie wolno zignorować wyłącznie takie wersje KF5, które nie są wymagane do budowy Plasma 5 w określonej wersji. Oznacza to, że musimy mieć świadomość jakiej minimalnej wersji KF5 wymaga Plasma, a to powoduje, że musimy przeglądnąć zawartość plików CMakeLists.txt tej wersji Plasmy. Niekiedy będzie też może zajść potrzeba jej przebudowania w oparciu o KF5 znajdujące się lokalnie w systemie.
Pamiętajmy jednak, że ze względu na cykl wydawniczy KDE możemy w takim przypadku stracić możliwość wsparcia, zaś w przypadku Archa, gdy zgłosimy problem na jakimś forum, czy jego bugzilli, praktycznie jedyna porada jaką uzyskamy, to: zakutalizuj system.
Jedną z opcji, jaką możemy tam ustawić, jest ignorowanie aktualizacji paczki. Za funkcję tą odpowiada pole IgnorePkg. Tu możemy wpisywać nazwy paczek, których nie chcemy aktualizować.
Teraz muszę coś przypomnieć. Arch Linux jest tak pomyślany, że domyślnym i jedynie wspieranym sposobem aktualizacji, jest aktualizacja globalna. Aktualizujemy zatem cały system, a nie poszczególną paczkę. Także do wyjątków winna należeć systuacja, w której aktualizacja systemu nie obejmuje jakiejś paczki. O prawidłowość działania tego mechanizmu dbają opiekunowie systemu. Czasem jest lepiej - czasem gorzej, ale zaangażowania w prawidłowość działania systemu jako całości, nie możemy odmówić.
Powrócę zatem do ignorowania aktualizacji poszczególnej paczki. Jak wspomniałem należy to traktować jako wyjątek. Systemu z niezaktualizowaną paczką opiekunowie Archa nie przewidzieli. Ignorowanie aktualizacji jest natomiast przez niektórych użytkowników traktowane jako remedium na kłopoty z działaniem systemu. Nic w tym dziwnego - sposób jest nawet opisany w wiki Archa. Zastanówmy się jednakże, czy w każdym przypadku jest to wybór paczki przeznaczonej do ignorowania podczas aktualizacji systemu jest prawidłowy.
Przypomnijmy sobie jak jest konstruowany linux. Jakaś aplikacja zwykle czerpie z czegoś (bibliotek), które są dostępne również innym programom. Aplikacja X jest zatem zależna od biblioteki Y. Ta natomiast może być zależna od jeszcze innej itd. W Archu informacje o zależnościach - często - przekazywane są jedynie jako nazwy programów, bez podania wersji (fakt zdarzają się i takie sytuacje, ale sporadycznie). System wszak ma być zawsze zaktualizowany jako całość. Pół biedy zatem, jeśli do pominięcia przy aktualizacji wybierzemy jakąś paczkę, która jest niezależna od innych. Pół biedy - jeśli wybierzemy taką, która prawidłowo działa w oparciu o inną, jednakże w dość dowolnej wersji. Gorzej, jeśli do ignorowania przeznaczymy paczkę "ze środka".
Oczywiście przykładem będzie nowe środowisko od KDE. Jak wiecie składa się ono z 2 elementów: bibliotek, zwanych KDE Frameworks 5 oraz samego środowiska Plasma 5. Owe biblioteki budowane są w pewien hierarchiczny sposób. Do prawidłowego działania wszystkie wymagają oczywiście Qt 5 w odpowiedniej wersji minimalnej (obecnie - ze względu na Debiana jest to wersja, która jest w nim dostępna). Komponenty składające się na KF5 podzielone są na 3 poziomy (en. tier). Na poziom pierwszy składają się te elementy KF5, które nie są zależne od innych elementów KF5 oraz budowane wyłącznie o zależności w Qt5. Poziom 2 to elementy, których zależnościami są wyłącznie elementy z Poziomu 1 (oczywiście dalszymi zależnościami będą ich zależności). Poziom 3 to elementy zależne od tych, które należą do Poziomu 1 i 2. Oczywiście Poziom 2 zależy od Poziomu 1 w odpowiedniej wersji i podobnie Poziom 3 od odpowiedniej wersji Poziomu 1 i 2. Całość KF5 jest pomyślana natomiast w taki sposób, by zawsze działała jako całość. Wszystkie jej komponenty winny być w tej samej wersji. Elementów wyższych poziomów nie jesteśmy w stanie zbudować zarówno w nowszej, jak i w starszej wersji w stosunku do elementów z niższego poziomu (i to nawet, jeśli się zdarzy, że jakiś element nie został pomiędzy wydaniami zmieniony).
Podobnie dzieje się z Plasmą, która również budowana jest w oparciu o określoną wersję minimalną. Dla przykładu minimalne wymagania nadchodzącego wydania 5.8 to KF 5.26 oraz Qt 5.6.1. Są to wymagania minimalne, które oznaczają, że Plasma 5.8 będzie pracować z KF 5.26 oraz Qt 5.6.1, ale będzie pracować również z KF i Qt w wersjach wyższych niż te deklarowane, natomiast nie ma żadnej gwarancji prawidłowego działania z KF i Qt w wersji niższej. Gdybyśmy budowali to środowisko we własnym zakresie ze źródeł, to musimy mu zapewnić elementy, na których jest budowane przynajmniej w tych minimalnych wersjach. Inaczej budowa się nie powiedzie.
Wrócę do Archa i przypomnę to co napisałem na początku: Arch wspiera wyłącznie pełną aktualizację systemu, a nie aktualizację poszczególnych paczek w nim zawartych oraz zależnością jest "nazwa" określonej paczki, ale już - najczęściej - bez podania jej wersji. Powoduje to, że Archa można oszukać. Można sobie "skonstruować" taki system, w którym będą istniały wszystkie komponenty wymagane przez system, ale niekoniecznie już wszystkie one będą w tej samej (czyt. najnowszej) wersji.
Wprowadzanie do linii IgnorePkg poszczególnych paczek jest typowym zachowaniem osób, które na siłę chcą np. pozostawić sobie starszą wersję jakiegoś oprogramowania bądź też uznają, że jakaś paczka powoduje komplikacje w systemie. Nawet nie dochodząc tego, czy przez przypadek problem nie leży w niewłaściwej konfiguracji systemu.
Niestety, w przypadku takim jak opisany wyżej - ignorowanie aktualizacji poszczególnych paczek KF5 to prośba o destabilizację pracy całego środowiska. Im więcej tych paczek tam się znajdzie, tym bardziej praca w Plasmie będzie przypominać grę na loterii. To może "działać" (tzn. może nam się wydawać, że działa), ale wcale nie musi. Jeśli "działa", to oznacza wyjątkową odporność Plasmy.
Oczywiście opisany tu problem nie dotyczy wyłącznie Plasmy i KF5. Spotkamy się z nim praktycznie w każdym większym środowisku, które są pomyślane właśnie w taki sposób, by były budowane jako całość (w jednej wersji), na podstawie określonych bibliotek w określonych wersjach, które w tych samych wersjach winny być w systemie.
Wracając do środowiska KDE. Jeśli już musimy z jakichś przyczyn "zastabilizować" jego element, to wymaga to od nas odpowiedniej wiedzy i roztropności. KF5 winno być zawsze w tej samej wersji, zatem jeśli musimy mieć jakiś jego element w wersji wcześniejszej niż w repozytorium, to nie należy wpisywać tego elementu do IgnorePkg, ale całą grupę kf5 oraz kf5-aids przeznaczyć jako wyłączoną z aktualizacji i umieścić obie w IgnoreGroup. Jednocześnie wolno zignorować wyłącznie takie wersje KF5, które nie są wymagane do budowy Plasma 5 w określonej wersji. Oznacza to, że musimy mieć świadomość jakiej minimalnej wersji KF5 wymaga Plasma, a to powoduje, że musimy przeglądnąć zawartość plików CMakeLists.txt tej wersji Plasmy. Niekiedy będzie też może zajść potrzeba jej przebudowania w oparciu o KF5 znajdujące się lokalnie w systemie.
Pamiętajmy jednak, że ze względu na cykl wydawniczy KDE możemy w takim przypadku stracić możliwość wsparcia, zaś w przypadku Archa, gdy zgłosimy problem na jakimś forum, czy jego bugzilli, praktycznie jedyna porada jaką uzyskamy, to: zakutalizuj system.
Komentarze
Prześlij komentarz