Przejdź do głównej zawartości

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.

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…

Plasma i Strażnik Krypt

W czasach, gdy nasza prywatność jest wystawiana na ciężką próbę, jeden z deweloperów KDE postanowił dodać do Plasmy możliwość dość łatwej obsługi szyfrowanych, wirtualnych "katalogów" - krypt, jak je nazywa. Sam projekt nazywa się plasma-vault i po około 3 miesiącach rozwijania pojawiła się w repozytorium unstable KDE najpierw jego wersja 5.9.95, a obecnie 5.9.96. Jak wskazuje numer wersji (choć ten został nadany nie przez opiekuna, ale przez wszędobylskiego Jonathana Riddella), aplikacja była planowana jako część Plasma 5.10. Tak się jednak z jakichś przyczyn nie stało. Obecnie jest ona planowana, jako część nadchodzącego wydania 5.11. Sam program w Archu dostępny jest w AUR. Buduje się całkiem żwawo i działa na tyle, by można zaryzykować jeśli nie używanie, to przynajmniej sprawdzenie działania i zgłoszenie ewentualnych błędów deweloperom. Pamiętajcie by czytać to co po pacman pisze przy instalacji. Program do prawidłowej funkcjonalności potrzebuje bądź encfs bądź cryfs. …

Co naprawdę oznacza, że pacman (Arch) nie wspiera częściowej aktualizacji

Pośród osób pracujących na Arch Linux jak mantra powtarzane jest twierdzenie: pacman (Arch) nie wspiera częściowej aktualizacji. Co w istocie to oznacza? Jakie są najczęściej popełniane błędy?

1. Synchronizacja repozytoriów dla zabawy
Zdarzyło się Wam wydać polecenie pacman -Sy bądź pacman -Syy, a za jakiś czas instalować program poprzez pacman -S? Jeśli nie, to jak dowodzą świadectwa innych użytkowników tu i ówdzie rozsiane po internecie praktyka ta wcale nie jest tak rzadka. Zobaczmy zatem co się dzieje w takich przypadkach i do czego to prowadzi.
Pierwsze polecenie dokona synchronizacji informacji o dostępnych paczkach (w tym ich wersjach) w repozytoriach z informacjami lokalnie przechowywanymi w bazie pacmana. Nie jest dokonywana żadna aktualizacja systemu. Następne polecenie oczywiście zainstaluje paczkę. Paczkę w takiej wersji, jaka jest w danym momencie w repozytorium.
Zwróćmy teraz uwagę na to w jaki sposób budowane są paczki w repozytoriach Archa oraz jakie informacje przekaz…