Jak nie instalować programów ze źródeł
To krótka przypowieść, jaka naszła mnie po lekturze dwu poradników o instalacji w Manjaro GIMPa oraz LibreOffice ze źródeł. Teksty są bliźniacze, a ich główną tezę można sprowadzić do stwierdzenia: zbudować program i zainstalować poprzez sudo make install. Skoro jest głupia porada, to wymaga jakiejś riposty.
Pominę sens budowania programów, które są w repozytoriach, zwłaszcza, że autor nie zaciekawił się opcjami kompilacji, które najczęściej w ogóle przemawiają za podjęciem tego trudu. Pominę też rozważania, czy istotnie dla systemu dobrym jest dostosowanie pod określony procesor zaledwie jednego, czy dwu programów, a nie całego systemu. Można mieć na ten temat bardzo różne zdania, a chętnych odsyłam do wiedzy tych, którzy na kompilacji zęby zjedli, czyli kolegów od Gentoo.
Interesuje mnie zgoła co innego.
Zastanówmy się wpierw nad owym magicznym sudo make install (oczywiście, o ile autor kodu dostarczył ich reguły, co regułą nie jest). Przed jego wydaniem, program zasadniczo został już skompilowany. W katalogu, w którym dokonywaliśmy budowy programu istnieją już stosowne binarki (i ewentualnie inne jego, niebinarne nawet, elementy). Wydając powyższe polecenie instruujemy make by dokonało ich instalacji w systemie. Binarki te lądują w miejscach określonych skryptem budującym program. Niemal zawsze (i stąd wymagane jest owe sudo) przekopiowanie ich odbywa się do katalogów zastrzeżonych dla administratora systemu. W tych samych katalogach instalowane są również paczki wprowadzane do systemu za pośrednictwem menedżera pakietów. Jaki zatem problem skoro wszystko odbywa się zgodnie z regułami sztuki?
Problemów wcale nie mało. Wymienię w punktach, by oszczędzić Waszego czasu.
Po pierwsze - w systemach, w których istnieje menedżer pakietów, za ich instalację, przechowywanie informacji o zainstalowanych pakietach, lokalizacji poszczególnych elementów składających się na taką paczkę oraz wielu jeszcze innych aspektach - służy i wyłącznie ten menedżer pakietów. I aż się prosi o stwierdzenie: koniec kropka.
Po drugie - budowa i instalacja w sposób klasyczny (czyli opisany przez autora) - w żaden sposób nie przekazuje menedżerowi pakietów informacji o zainstalowaniu takiej aplikacji. Instalując w klasyczny sposób aplikacje, umieszczamy w katalogach na nie przeznaczonych różne pliki, które mogą kolidować z jakimiś paczkami instalowanym przez menedżera pakietów. Próba instalacji takiej paczki (a także innych instalowanych wraz z nią) nie powiedzie się, albowiem pacman wykryje, że w systemie plików znajduje się już plik o takiej samej nazwie. Na nic się w tym momencie zda próba jego wykorzystania do identyfikacji do jakiego pakietu należy dany plik (pacman -O plik). Ta skończy się podaniem prawidłowej z punktu widzenia pacmana informacji, że plik ten nie należy do żadnego pakietu, ale nie oznacza to, że ów plik nie należy do żadnej aplikacji. W tym momencie dokonanie niemal dowolnej operacji dla uzdrowienia tej sytuacji może skończyć się spektakularnym błędem. Wystarczy? Dla mnie tak.
Po trzecie - o ile pacman dokonując instalacji paczek sprawdza właśnie powyższą sytuację i w przypadku wykrycia istniejącego już w systemie pliku uniemożliwia dalszą instalację i daje czas na ochłonięcie administratorowi i zidentyfikowanie błędu oraz rozwiązanie problemu, to instalacja poprzez sudo make install nie zauważy takiego problemu. Wszak administrator systemu nakazał mu zainstalowanie w konkretnej lokalizacji konkretnego pliku. Jeśli w systemie będzie już istniał taki sam plik, jednakże dostarczany przez inną paczkę, to ów plik zostanie nadpisany nowym. Mam dalej pisać co może to spowodować? Wystarczy?
Po czwarte - kompilując i instalując paczki w sposób podany przez autora, zdajemy się na to, co autor danego rozwiązania przewidział w plikach konfigurujących kompilację. Tak stworzona aplikacja może się różnić lokalizacją poszczególnych plików składających się na daną aplikację od systemu przyjętego w Archu (a w ślad za nim w Manjaro). Taka aplikacja może, ale nie musi działać prawidłowo. Nieprawidłowo natomiast będzie wyglądała ona z punktu widzenia struktury i hierarchii katalogów w Archu.
I tyle, bo nie chce mi się więcej rozpisywać na temat dlaczego oba poradniki są typowym przykładem dezinformacji, z których skorzystanie może zrobić więcej szkody niż pożytku. Na koniec tylko jedna kwestia. Bowiem skoro nie tak, jak autor wskazał, to jak?
Otóż jedynym poprawnym sposobem instalacji programów ze źródeł w Archu (ale tak na prawdę, to w dowolnej dystrybucji) jest stworzenie odpowiedniej paczki rozpoznawanej przez menedżer pakietów i zainstalowanie jej w systemie za jego pomocą. W przypadku Archa (i pochodnych) wykorzystujemy w tym celu PKGBUILD. Możemy go stworzyć we własnym zakresie, możemy skorzystać z istniejącego rozwiązania (wszak oba programy wskazane przez autora dostępne są w repozytoriach i mają swoje PKGBUILDy), jeśli nie wiemy jak tego dokonać samemu, mamy też co najmniej kilka możliwości z jakich możemy skorzystać (AUR, BBS Archa, nasze forum).
I nie byłbym sobą, gdybym nie napisał: kochani autorzy skończmy z dezinformacją. Skończmy z podawaniem błędnych rozwiązań. Nawet jeśli jakieś rozwiązanie działa, to nie oznacza, że jest ono prawidłowe. Umieszczajmy rozwiązania wyłącznie takie, co do których jesteśmy w 100% przekonani, że są one prawidłowe i - przede wszystkim, że - nikomu proponowane przez nas rozwiązanie nie zaszkodzi.
Pominę sens budowania programów, które są w repozytoriach, zwłaszcza, że autor nie zaciekawił się opcjami kompilacji, które najczęściej w ogóle przemawiają za podjęciem tego trudu. Pominę też rozważania, czy istotnie dla systemu dobrym jest dostosowanie pod określony procesor zaledwie jednego, czy dwu programów, a nie całego systemu. Można mieć na ten temat bardzo różne zdania, a chętnych odsyłam do wiedzy tych, którzy na kompilacji zęby zjedli, czyli kolegów od Gentoo.
Interesuje mnie zgoła co innego.
Zastanówmy się wpierw nad owym magicznym sudo make install (oczywiście, o ile autor kodu dostarczył ich reguły, co regułą nie jest). Przed jego wydaniem, program zasadniczo został już skompilowany. W katalogu, w którym dokonywaliśmy budowy programu istnieją już stosowne binarki (i ewentualnie inne jego, niebinarne nawet, elementy). Wydając powyższe polecenie instruujemy make by dokonało ich instalacji w systemie. Binarki te lądują w miejscach określonych skryptem budującym program. Niemal zawsze (i stąd wymagane jest owe sudo) przekopiowanie ich odbywa się do katalogów zastrzeżonych dla administratora systemu. W tych samych katalogach instalowane są również paczki wprowadzane do systemu za pośrednictwem menedżera pakietów. Jaki zatem problem skoro wszystko odbywa się zgodnie z regułami sztuki?
Problemów wcale nie mało. Wymienię w punktach, by oszczędzić Waszego czasu.
Po pierwsze - w systemach, w których istnieje menedżer pakietów, za ich instalację, przechowywanie informacji o zainstalowanych pakietach, lokalizacji poszczególnych elementów składających się na taką paczkę oraz wielu jeszcze innych aspektach - służy i wyłącznie ten menedżer pakietów. I aż się prosi o stwierdzenie: koniec kropka.
Po drugie - budowa i instalacja w sposób klasyczny (czyli opisany przez autora) - w żaden sposób nie przekazuje menedżerowi pakietów informacji o zainstalowaniu takiej aplikacji. Instalując w klasyczny sposób aplikacje, umieszczamy w katalogach na nie przeznaczonych różne pliki, które mogą kolidować z jakimiś paczkami instalowanym przez menedżera pakietów. Próba instalacji takiej paczki (a także innych instalowanych wraz z nią) nie powiedzie się, albowiem pacman wykryje, że w systemie plików znajduje się już plik o takiej samej nazwie. Na nic się w tym momencie zda próba jego wykorzystania do identyfikacji do jakiego pakietu należy dany plik (pacman -O plik). Ta skończy się podaniem prawidłowej z punktu widzenia pacmana informacji, że plik ten nie należy do żadnego pakietu, ale nie oznacza to, że ów plik nie należy do żadnej aplikacji. W tym momencie dokonanie niemal dowolnej operacji dla uzdrowienia tej sytuacji może skończyć się spektakularnym błędem. Wystarczy? Dla mnie tak.
Po trzecie - o ile pacman dokonując instalacji paczek sprawdza właśnie powyższą sytuację i w przypadku wykrycia istniejącego już w systemie pliku uniemożliwia dalszą instalację i daje czas na ochłonięcie administratorowi i zidentyfikowanie błędu oraz rozwiązanie problemu, to instalacja poprzez sudo make install nie zauważy takiego problemu. Wszak administrator systemu nakazał mu zainstalowanie w konkretnej lokalizacji konkretnego pliku. Jeśli w systemie będzie już istniał taki sam plik, jednakże dostarczany przez inną paczkę, to ów plik zostanie nadpisany nowym. Mam dalej pisać co może to spowodować? Wystarczy?
Po czwarte - kompilując i instalując paczki w sposób podany przez autora, zdajemy się na to, co autor danego rozwiązania przewidział w plikach konfigurujących kompilację. Tak stworzona aplikacja może się różnić lokalizacją poszczególnych plików składających się na daną aplikację od systemu przyjętego w Archu (a w ślad za nim w Manjaro). Taka aplikacja może, ale nie musi działać prawidłowo. Nieprawidłowo natomiast będzie wyglądała ona z punktu widzenia struktury i hierarchii katalogów w Archu.
I tyle, bo nie chce mi się więcej rozpisywać na temat dlaczego oba poradniki są typowym przykładem dezinformacji, z których skorzystanie może zrobić więcej szkody niż pożytku. Na koniec tylko jedna kwestia. Bowiem skoro nie tak, jak autor wskazał, to jak?
Otóż jedynym poprawnym sposobem instalacji programów ze źródeł w Archu (ale tak na prawdę, to w dowolnej dystrybucji) jest stworzenie odpowiedniej paczki rozpoznawanej przez menedżer pakietów i zainstalowanie jej w systemie za jego pomocą. W przypadku Archa (i pochodnych) wykorzystujemy w tym celu PKGBUILD. Możemy go stworzyć we własnym zakresie, możemy skorzystać z istniejącego rozwiązania (wszak oba programy wskazane przez autora dostępne są w repozytoriach i mają swoje PKGBUILDy), jeśli nie wiemy jak tego dokonać samemu, mamy też co najmniej kilka możliwości z jakich możemy skorzystać (AUR, BBS Archa, nasze forum).
I nie byłbym sobą, gdybym nie napisał: kochani autorzy skończmy z dezinformacją. Skończmy z podawaniem błędnych rozwiązań. Nawet jeśli jakieś rozwiązanie działa, to nie oznacza, że jest ono prawidłowe. Umieszczajmy rozwiązania wyłącznie takie, co do których jesteśmy w 100% przekonani, że są one prawidłowe i - przede wszystkim, że - nikomu proponowane przez nas rozwiązanie nie zaszkodzi.
Komentarze
Prześlij komentarz