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ściolatka; dlaczego? Skoro działa, skoro zainstalowało, to dlaczego mi tego robić nie wolno? Wolno. Kto komu zabroni. Niemniej jednak nie licz w takim przypadku, że ktokolwiek potem pomoże, a biorąc pod uwagę co zrobiłeś sam sobie nie pomożesz i zamiast zaktualizować oprogramowanie, za którymś razem okaże się, że będziesz instalować system od początku, oczywiście złożecząc na pacmana, Archa i kogo tylko będziesz chciał obarczać odpowiedzialnością swoich błędów.
Dlaczego zatem rozwiązanie powyższe jest wadliwe?
Niemal każda dystrybucja linuksowa stosuje menedżery paczek. Oczywiście z punktu widzenia użytkownika, szczególnie bardzo "zielonego", jest on traktowany jako uniwersalny instalator oprogramowania. Fakt, każdy menedżer paczek posiada taką funkcjonalność. Jego rola w systemie jest jednak znacznie szersza i m.in. służy zachowaniu w nim porządku. Mówiąc kolokwialnie: po prostu dba, by system działał. Wprowadzając do systemu paczki za pomocą menedżera możemy liczyć na to, że system działał będzie długie lata.
Co się zatem dzieje, gdy do instalacji wykorzystamy obce narzędzie? Otóż nasz menedżer paczek (pacman) nie zostanie o tym powiadomiony. W systemie pojawią się pliki, o których on nic nie wie. Przy jakiejś aktualizacji programów dojść może zatem do sytuacji, w której istniejące, obce pliki, będą kolidować z tymi, które mają zostać zainstalowane. Instalacja nie powiedzie się. Długo sobie będziesz przypominał co zrobiłeś, by utrudnić pacmanowi życie i najczęściej winą obarczysz bogu ducha winny menedżer czy deweloperów oprogramowania.
Jest też druga przyczyna, aktualna szczególnie w przypadku paczek deb. Otóż struktura katalogów Archa i Debiana różni się. Oba te systemy gdzie indziej oczekują istnienia poszczególnych plików, składających się na paczkę. Instalacja przez dpkg oczywiście się uda, wszak z tego punktu widzenia, dokona on rozpakowania paczki deb i umieszczenie wypakowanych plików w strukturze, która została w niej zadeklarowana. Sam program jakiś czas może nawet i działać, ale instalacja w ten sposób to proszenie się o kłopoty.
Jeszcze inna przyczyna, to zwróćmy uwagę, że instalujemy w ten sposób paczki binarne, już skompilowane na jakimś systemie i dla określonego systemu tworzone. W tym, docelowym dla takiej paczki systemie znajdować się mogą biblioteki w różnych wersjach. Zwróciliście uwagę, że paczki deb czy rpm często mają określenia sugerujące dla jakiej konkretnej wersji dystrybucji są one przygotowane? To m.in. właśnie dlatego. Pamiętajcie również, że w Archu od dawna jest systemd, a wiele paczek dla Debiana, czy Ubuntu dostosowanych jest jeszcze do upstartu.
Dobrze, co zatem robić, gdy koniecznie musicie mieć program oferowany w deb lub rpm?
Po pierwsze należy wnikliwie i spokojnie przeszukać dostępne repozytoria Archa oraz AUR. Jeśli są to należy zainstalować lub zbudować, te, które są dostępne w ten sposób. Jeśli ich nie ma, należy poszukać źródeł. Jeśli te są - stworzyć odpowiedni PKGBUILD (lub poprosić o jego stworzenie, gdy wiedzy zbyt mało osoby bardziej doświadczone), skompilować program i zainstalować go za pomocą pacmana. Kiedy źródeł nie ma w istocie to można spróbować poszukać jakiegoś appimage, czy flatpaka (snappy nie polecam ze względów, które już opisałem). Innym źródłem takiej paczki może być jakiś system pochodny od Archa. W przypadku Antergosa, czy innej dystrybucji korzystającej bezpośrednio z repozytorium Archa, instalacja takiej paczki nie powinna robić problemów w systemie. Należy jedynie pamiętać, że jakaś paczka została zainstalowana z obcego repozytorium, które poniekąd można traktować również jako tzw. nieoficjalne. W przypadku paczek Manjaro i Archa. Tu pewien problem może istnieć, albowiem repozytoria stable obu systemów nie odpowiadają w 100% sobie i wersje paczek mogą być różne. Jeśli w Archu decydowalibyśmy się na taki krok, to należałoby się pokusić o instalację paczki z testowego bądź niestabilnego repozytorium Manjaro, a i wówczas zalecałbym ostrożność i traktowanie tego jako ostateczność, ale i tak lepszą niż instalację paczki deb, czy rpm. Najlepiej jednak byłoby taką paczkę po prostu przebudować. Inne systemy, które wykorzystują pacmana jako menedżer paczek, jak np. Charka czy KaOS mogą być traktowane wyłącznie na takich samych zasadach jak paczki deb, czy rpm. Bezpośrednie zainstalowanie paczki z KaOS graniczy zresztą z cudem, ze względu na odmienną ich nomenklaturę.
Dopiero ostatecznością winno być pokuszenie się o instalację paczki deb lub rpm, jednakże nie stosując w tym celu ich menedżerów plików. Przede wszystkim, jeśli dostępne są oba rodzaje paczek, to lepszym wyborem będzie rpm. Struktura katalogów Fedory jest zbliżona do Archa. Możemy też liczyć na to, że szczególnie w stosunku do paczek dla Debiana Stable czy Ubuntu LTS (zwłaszcza pod koniec jego wsparcia), użyte do budowy programy są w tej samej wersji, co w Archu. Kiedy już znajdziemy odpowiednią paczkę, należy dla niej zrobić PKGBUILD, który dokonałby rozpakowania rpma czy ewentualnie deba, a następnie umieściłby otrzymane w ten sposób pliki w zgodzie ze strukturą katalogów Archa. Niekiedy trzba będzie jeszcze dokonać zmian w plikach *.desktop i innych. Otrzymaną paczkę dopiero będzie można zainstalować w systemie za pomocą pacmana. Jak zwykle - jeśli nie potrafisz tego dokonać sam, to możesz się zwrócić do społeczności o pomoc w takiej sprawie.
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ściolatka; dlaczego? Skoro działa, skoro zainstalowało, to dlaczego mi tego robić nie wolno? Wolno. Kto komu zabroni. Niemniej jednak nie licz w takim przypadku, że ktokolwiek potem pomoże, a biorąc pod uwagę co zrobiłeś sam sobie nie pomożesz i zamiast zaktualizować oprogramowanie, za którymś razem okaże się, że będziesz instalować system od początku, oczywiście złożecząc na pacmana, Archa i kogo tylko będziesz chciał obarczać odpowiedzialnością swoich błędów.
Dlaczego zatem rozwiązanie powyższe jest wadliwe?
Niemal każda dystrybucja linuksowa stosuje menedżery paczek. Oczywiście z punktu widzenia użytkownika, szczególnie bardzo "zielonego", jest on traktowany jako uniwersalny instalator oprogramowania. Fakt, każdy menedżer paczek posiada taką funkcjonalność. Jego rola w systemie jest jednak znacznie szersza i m.in. służy zachowaniu w nim porządku. Mówiąc kolokwialnie: po prostu dba, by system działał. Wprowadzając do systemu paczki za pomocą menedżera możemy liczyć na to, że system działał będzie długie lata.
Co się zatem dzieje, gdy do instalacji wykorzystamy obce narzędzie? Otóż nasz menedżer paczek (pacman) nie zostanie o tym powiadomiony. W systemie pojawią się pliki, o których on nic nie wie. Przy jakiejś aktualizacji programów dojść może zatem do sytuacji, w której istniejące, obce pliki, będą kolidować z tymi, które mają zostać zainstalowane. Instalacja nie powiedzie się. Długo sobie będziesz przypominał co zrobiłeś, by utrudnić pacmanowi życie i najczęściej winą obarczysz bogu ducha winny menedżer czy deweloperów oprogramowania.
Jest też druga przyczyna, aktualna szczególnie w przypadku paczek deb. Otóż struktura katalogów Archa i Debiana różni się. Oba te systemy gdzie indziej oczekują istnienia poszczególnych plików, składających się na paczkę. Instalacja przez dpkg oczywiście się uda, wszak z tego punktu widzenia, dokona on rozpakowania paczki deb i umieszczenie wypakowanych plików w strukturze, która została w niej zadeklarowana. Sam program jakiś czas może nawet i działać, ale instalacja w ten sposób to proszenie się o kłopoty.
Jeszcze inna przyczyna, to zwróćmy uwagę, że instalujemy w ten sposób paczki binarne, już skompilowane na jakimś systemie i dla określonego systemu tworzone. W tym, docelowym dla takiej paczki systemie znajdować się mogą biblioteki w różnych wersjach. Zwróciliście uwagę, że paczki deb czy rpm często mają określenia sugerujące dla jakiej konkretnej wersji dystrybucji są one przygotowane? To m.in. właśnie dlatego. Pamiętajcie również, że w Archu od dawna jest systemd, a wiele paczek dla Debiana, czy Ubuntu dostosowanych jest jeszcze do upstartu.
Dobrze, co zatem robić, gdy koniecznie musicie mieć program oferowany w deb lub rpm?
Po pierwsze należy wnikliwie i spokojnie przeszukać dostępne repozytoria Archa oraz AUR. Jeśli są to należy zainstalować lub zbudować, te, które są dostępne w ten sposób. Jeśli ich nie ma, należy poszukać źródeł. Jeśli te są - stworzyć odpowiedni PKGBUILD (lub poprosić o jego stworzenie, gdy wiedzy zbyt mało osoby bardziej doświadczone), skompilować program i zainstalować go za pomocą pacmana. Kiedy źródeł nie ma w istocie to można spróbować poszukać jakiegoś appimage, czy flatpaka (snappy nie polecam ze względów, które już opisałem). Innym źródłem takiej paczki może być jakiś system pochodny od Archa. W przypadku Antergosa, czy innej dystrybucji korzystającej bezpośrednio z repozytorium Archa, instalacja takiej paczki nie powinna robić problemów w systemie. Należy jedynie pamiętać, że jakaś paczka została zainstalowana z obcego repozytorium, które poniekąd można traktować również jako tzw. nieoficjalne. W przypadku paczek Manjaro i Archa. Tu pewien problem może istnieć, albowiem repozytoria stable obu systemów nie odpowiadają w 100% sobie i wersje paczek mogą być różne. Jeśli w Archu decydowalibyśmy się na taki krok, to należałoby się pokusić o instalację paczki z testowego bądź niestabilnego repozytorium Manjaro, a i wówczas zalecałbym ostrożność i traktowanie tego jako ostateczność, ale i tak lepszą niż instalację paczki deb, czy rpm. Najlepiej jednak byłoby taką paczkę po prostu przebudować. Inne systemy, które wykorzystują pacmana jako menedżer paczek, jak np. Charka czy KaOS mogą być traktowane wyłącznie na takich samych zasadach jak paczki deb, czy rpm. Bezpośrednie zainstalowanie paczki z KaOS graniczy zresztą z cudem, ze względu na odmienną ich nomenklaturę.
Dopiero ostatecznością winno być pokuszenie się o instalację paczki deb lub rpm, jednakże nie stosując w tym celu ich menedżerów plików. Przede wszystkim, jeśli dostępne są oba rodzaje paczek, to lepszym wyborem będzie rpm. Struktura katalogów Fedory jest zbliżona do Archa. Możemy też liczyć na to, że szczególnie w stosunku do paczek dla Debiana Stable czy Ubuntu LTS (zwłaszcza pod koniec jego wsparcia), użyte do budowy programy są w tej samej wersji, co w Archu. Kiedy już znajdziemy odpowiednią paczkę, należy dla niej zrobić PKGBUILD, który dokonałby rozpakowania rpma czy ewentualnie deba, a następnie umieściłby otrzymane w ten sposób pliki w zgodzie ze strukturą katalogów Archa. Niekiedy trzba będzie jeszcze dokonać zmian w plikach *.desktop i innych. Otrzymaną paczkę dopiero będzie można zainstalować w systemie za pomocą pacmana. Jak zwykle - jeśli nie potrafisz tego dokonać sam, to możesz się zwrócić do społeczności o pomoc w takiej sprawie.
Komentarze
Prześlij komentarz