Przejdź do głównej zawartości

Dlaczego nie instalować pojedynczych paczek innych gałęzi systemu

Dystrybucje linuksowe zwykle zawierają "przejściowe" repozytoria, gdzie testowane są nowe paczki. Niektóre dystrybucje, z owych repozytoriów tworzą nawet niemal oddzielne gałęzie swych dystrybucji, a społecznościowa gawiedź dośpiewuje całą resztę, upatrując np. w Debian Testing ucieleśnienia dystrybucji rolling release. Zostawmy jednak Debiana, skupmy się na Archu i pokrewnych. W Archu dostępnych jest kilka repozytoriów. Podobnie w Manjaro. W strukturze repozytoriów tego pierwszego znajdziemy repozytoria z "dopiskiem" testing i dwa repozytoria z "dopiskiem" unstable (kde i gnome). Struktura gałęzi Manjaro jest praktycznie przeniesiona z Debiana, choć absolutnie niewiele ma z nim wspólnego. Ograniczę się do omówienia Archa, jednakże to samo ma zastosowanie do innych dystrybucji rolling release (to jest kluczowe), na pewno natomiast ma to 100% zastosowanie do dystrybucji, gdzie paczki zarządzane są przez pacmana. Otóż pojawiają się wpisy omawiające sposób zainstalowania pojedynczej paczki z innej gałęzi (repozytorium testowego, niestabilnego) danej dystrybucji. Jest to bardzo nieodpowiedzialny pomysł, choć realizowany wg zasady: chcącemu nie dzieje się krzywda. Oczywiście, że istnieje możliwość zainstalowania czegokolwiek, skądkolwiek i w jakiejkolwiek wersji. Zastanówmy się jednak co to oznacza i czy na pewno "możliwość" oznaczna, że "można". Przede wszystkim należy przypomnieć jedną sprawę: pacman nie wspiera częściowej aktualizacji. Uświadomijmy sobie również, że taka instalacja nowej wersji z testowego repozytorium jest niczym innym, jak właśnie dokonaniem częściowej aktualizacji. Operacja może się udać. Program zainstalowany w ten sposób może działać prawidłowo. Może jednakże nie działać wcale, może okazać się działającym wadliwie (np. niestabilnie). Może też doprowadzić do destabilizacji całego systemu, a w skrajnych przypadkach po prostu go nie uruchomimy ponownie (w obu przypadkach, gdy np. zmieniliśmy jakiś kluczowy jego element, bibliotekę, na która jest zależnością innych paczek). Dlaczego tak się dzieje? Otóż dystrybucje takie jak Arch są robione w taki sposób, że ich deweloperzy starają się zapewnić właściwą pracę zaktualizowanego systemu. Paczki znajdujące się w określonym repozytorium są budowane w taki sposób, że ich zależności znajdują się w tym właśnie repozytorium. Owe zależności oznaczają nie tylko "nazwę paczki", ale też jej określoną wersję, która w tym repozytorium się znajduje. Paczki w repozytorium "stabilnym" winny zatem być w korelacji ze sobą. W repozytorium testowym będą paczki skorelowane ze sobą. Jeśli zatem jakaś paczka będzie wymagała jakiejś zależności w określonej wersji, to owa paczka w takiej wersji się znajdzie. I odwrotnie - jeśli jakaś zależność spowoduje konieczność przebudowania jakiejś paczki, to taka przebudowana paczka tam się znajdzie. To właśnie dlatego pacman nie wspiera częściowej aktualizacji. Musimy sobie uświadomić jeszcze jedną rzecz. Otóż w przeciwieństwie np. do APTa, w PKGBUILD bardzo rzadko znaleźć można określenie wersji konkretnej paczki stanowiącej zależność. Przy instalacji poszczególnej paczki nie zostajemy zatem powiadomieni o tym, że jakaś paczka nie jest kompatybilna z wersją instalowaną. Arch (Manjaro) - to Arch. Bardzo prosta w budowie dystrybucja, jednak trzeba o nią dbać, a nie gwałcić ją na siłę. Chyba, że doskolane wiemy co robimy, wiemy, że instalacja czegoś pociąga konieczność zmiany innej paczki itd. itp. Co zatem zrobić, jeśli z jakiejś przyczyny bardzo musimy mieć wersję paczki znajdującej się w gałęzi (repozytorium) innym niż używane? Trudno - innej drogi nie ma - choćby czasowo musimy zainstalować wszystkie paczki w tej samej wersji (testowej), w jakiej potrzebujemy mieć określoną (jedną) paczkę. W Archu robimy to "ręcznie" udostępniając repozytoria testowe. W Manjaro możemy wydać polecenie:
sudo pacman-mirrors -g -b testing (lub unstable)
I dokonać pełnej aktualizacji:
sudo pacman -Syu
Jeśli później zechcemy wrócić do "gałęzi" poprzedniej, powinniśmy w Archu zakomentować repozytoria testowe, w Manjaro wykonać:
sudo pacman-mirrors -g -b stable (lub testing)
I... dokonać pełnej aktualizacji systemu z jednoczesnym wgraniu w miejsce istniejących lokalnie wersji paczek, tych, które znajdują się na serwerze, nawet jeśli są one w wersji niższej od lokalnej:
sudo pacman -Syuu

Popularne posty z tego bloga

MEGA a sprawa Arch Linux

Mniejsza o to, czy MEGA to popularny, czy godny zaufania itd. itp. dostarczyciel przestrzeni w chmurze. Fakt, że po moich doświadczeniach z dropboksem nie chcę mieć więcej z nim nic wspólnego. Może zatem MEGA, do którego mam dostęp niemal od samego początku? Miłym dodatkiem do MEGA może okazać się uruchomione repozytorium oferujące sam program synchronizujący (megasync) oraz dodatki dla trzech, chyba najpopularniejszych, menedżerów plików: Dolphin, Nautilus i Thunar, umożliwiające synchronizację z plików z ich poziomu. Jest to o tyle miłe, że do tej pory musieliśmy kompilować te programy z AUR, a nadto w przypadku megasync wersja oferowana w repozytorium jest nowsza, zaś dolphin-megasync obecnie w ogóle się nie kompiluje. Chcąc dodać repozytorium MEGA do pacmana, edytujemy plik /etc/pacman.conf i gdzieś na końcu listy dodajemy: [DEB_Arch_Extra]SigLevel = Optional TrustAllServer = https://mega.nz/linux/MEGAsync/Arch_Extra/x86_64/ Nadto musimy jeszcze dodać klucz: gpg --receive-keys BF…

Ostatnia deska ratunku - uruchomienie linuksa z prawami administratora

Kiedyś już pisałem o tym, że warto sobie za wczasu zrobić ratunkowe koło. Niemniej jednak zwykle Polak mądr po szkodzie. Często czytam, że "po aktualizacji system mi się nie uruchamia". Ów system najczęściej jest utożsamiany ze środowiskiem graficznym. No, to nie do końca "system się nie uruchamia", ten najczęściej się uruchomił, jednakże z jakiegoś powodu nie uruchamia się tryb graficzny. Nawet jednak w takiej sytuacji i również wówczas, gdy nie zadbaliśmy wcześniej o ustawienie sobie pozycji recovery w GRUB będziemy mogli uruchomić "sesję ratunkową", która da nam dostęp do trybu konsolowego na prawach administratora. Wówczas już można zrobić z systemem wszystko co niezbędne. Wystarczy bowiem do linii startowej w GRUB dodać polecenie: systemd.unit=rescue.target i system uruchomi się grzecznie prosząc o podanie hasła administratora. Z sesji tej wychodzimy wpisując: exit i nastąpi dalsze podnoszenie systemu już ze środowiskiem. Pamiętać jednak musimy, że…

Paczki deb i rpm w Archu

Co jakiś czas pojawiają się pośród użytkowników Archa, czy Manjaro rozpaczliwe głosy związane z próbą zainstalowania paczek pochodzących z najpopularniejszych dystrybucji, a w zasadzie paczek oferowanych w formacie deb lub rpm. Najczęściej głosy te pochodzą od bardzo świeżych użytkowników naszej dystrybucji. Co gorsza dotyczą one często sterowników, albo aplikacji, które i tak są oferowane w AUR albo w jakchś repozytoriach.
Ze względu na dostępność w repozytoriach Archa dpkg oraz rpm w ślad za takim "lamentem" idzie cudowna podpowiedź: zainstaluj sobie dpkg/rpm i za pomocą tego menedżera zainstaluj paczkę w systemie.
Czy coś takiego ma szansę powodzenia? Oczywiście. Menedżer paczek jest wszak aplikacją wyspecjalizowaną w m.in. ich instalacji.
I wszystko wydaje się wspaniałe.
STOP.
Niestety nic nie jest wspaniałe. Nie tak się to robi i tak instalacji aplikacji pakowanych dla obcych dystrybucji się nie robi. Kiedy o tym pisałem, spotykałem się z najpopularniejszym pytaniem sze…