Programy spoza repozytorium

Wstęp

Wchodzisz na stronę programu, który chcesz zainstalować. W hurtowni dystrybucji go nie ma. Producent daje Ci sześć przycisków. Sześć różnych sposobów na to samo. Który kliknąć?

Dziś przejdziemy przez wszystkie. Pokażę, czym się różnią, kiedy który ma sens, gdzie lądują pliki i co zrobić, kiedy program po instalacji mówi, że nie może znaleźć jakiejś biblioteki.

Najpierw: kolejność zaufania

Zanim cokolwiek klikniesz, zasada dla admina. Im dalej od hurtowni dystrybucji, tym więcej roboty i ryzyka spada na Ciebie.

1. Repozytorium dystrybucji. Ktoś za Ciebie sprawdza, podpisuje i łata.
2. Oficjalne repozytorium producenta, dodane do apt albo dnf, jak repozytorium Dockera z lekcji 65. Dalej masz aktualizacje razem z resztą systemu.
3. Flatpak albo Snap. Aktualizacje są, ale osobnym kanałem.
4. Pobrany plik .deb albo .rpm. Instalujesz raz i sam pamiętasz o aktualizacjach.
5. AppImage. Jeden plik, zero integracji z systemem.
6. Kompilacja ze źródeł. Pełna kontrola i pełna odpowiedzialność.

To jak z jedzeniem w pracy. Stołówka zakładowa ma sanepid. Catering ma certyfikat. A kanapka od kolegi „z domu” może być najlepsza na świecie, ale jak się zatrujesz, reklamacji nie złożysz.

Pobrany .deb i .rpm

Najprostszy przypadek. Producent daje karton, ale nie ma hurtowni. Zanim go wniesiesz, obejrzyj etykietę. Na przykładzie mojego testowego pakietu:

dpkg-deb -I powitanie_1.0_all.deb

 Package: powitanie
 Version: 1.0
 Architecture: all
 Maintainer: Kurs <kurs@example.com>
 Depends: sl
 Description: Testowy pakiet do kursu

dpkg-deb -c pokaże listę plików w środku. Instalacja: w lekcji 65 wnosiliśmy karton dpkg -i i magazynier stawał bez kołków. Wygodniej poprosić kierownika, żeby wniósł karton z dysku i sam dowiózł zależności:

sudo apt install ./powitanie_1.0_all.deb

Kropka i ukośnik są kluczowe. Bez nich apt myśli, że to nazwa pakietu z hurtowni:

sudo apt install powitanie_1.0_all.deb

E: Unable to locate package powitanie_1.0_all.deb

./ mówi: „to jest plik, tutaj, w tym folderze”. Ten sam trik co przy uruchamianiu skryptów.

[RHEL] Na Red Hacie dnf od razu rozumie ścieżkę do pliku, a nawet adres URL:

rpm -qpi plik.rpm
rpm -qpl plik.rpm
rpm -qp --scripts plik.rpm
sudo dnf install ./plik.rpm

-p znaczy „pytam o plik pakietu, nie o zainstalowany pakiet”. A --scripts pokazuje skrypty instalacyjne. Pamiętasz z lekcji 64? Działają jako root. Jeśli w skrypcie instalacyjnym „przeglądarki PDF” widzisz curl z jakiegoś adresu i | bash, to nie jest przeglądarka PDF.

Haczyk całej metody: taki pakiet nie aktualizuje się sam. Hurtownia nic o nim nie wie. Zanim pobierzesz plik, sprawdź na stronie producenta, czy nie ma repozytorium. Jeśli ma, wybierz repozytorium.

Flatpak: aplikacja w kontenerze z własną kuchnią

Program z Flatpaka przychodzi z własną kuchnią. Nie korzysta z bibliotek systemu, tylko z tak zwanego runtime'u, czyli wspólnego zestawu bibliotek, który Flatpak dociąga raz i dzieli między aplikacje. Do tego aplikacja działa w piaskownicy, czyli widzi tylko to, na co jej pozwolono. Jak kucharz w wynajętym food trucku: ma swój sprzęt, a do Twojej kuchni nie ma wstępu.

Flatpak żyje głównie na desktopach. Największa hurtownia nazywa się Flathub.

sudo apt install flatpak
flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
flatpak install flathub org.gimp.GIMP
flatpak run org.gimp.GIMP
flatpak list --app
flatpak update
flatpak uninstall org.gimp.GIMP
flatpak uninstall --unused

[RHEL] Instalacja samego Flatpaka: sudo dnf install flatpak. Reszta identyczna.

remote-add dodaje hurtownię. --if-not-exists sprawia, że druga próba nie wywali błędu. Aplikacje nazywają się odwróconą domeną, jak org.gimp.GIMP. uninstall --unused sprząta runtime'y, których już żadna aplikacja nie używa. To flatpakowe autoremove.

Domyślnie Flatpak instaluje dla całego systemu. Z flagą --user instalujesz tylko dla siebie, bez sudo.

Snap: paczka od Canonicala

Snap to podobny pomysł od Canonicala, firmy od Ubuntu. Też paczka z zależnościami w środku, też piaskownica, też osobna hurtownia: Snap Store. Na Ubuntu demon snapd zwykle jest już zainstalowany.

snap find nazwa
sudo snap install nazwa
snap list
sudo snap refresh
sudo snap remove nazwa

Wielka różnica: snapy aktualizują się same. Domyślnie snapd sprawdza aktualizacje cztery razy dziennie. Dla laptopa to wygoda. Dla serwera produkcyjnego to program, który może zmienić wersję we wtorek o 14:00 bez pytania. Da się to wstrzymać:

sudo snap refresh --hold=24h nazwa

Bez podanego czasu blokada jest bezterminowa.

Niektóre programy wymagają flagi --classic. To snap bez piaskownicy, z pełnym dostępem do systemu, jak zwykły program. Bez tej flagi snap takiego programu nie zainstaluje i podpowie, żeby jej użyć.

[RHEL] Na Red Hacie snap jest możliwy przez EPEL (snapd plus włączenie snapd.socket), ale oficjalna instrukcja Snapcrafta wymienia RHEL 7, 8 i 9. W świecie Red Hata to raczej egzotyka.

AppImage: program w jednym pliku

AppImage to najprostszy pomysł z całej trójki: cały program z bibliotekami w jednym pliku. Bez instalacji. Pobierasz, nadajesz prawo wykonywania i uruchamiasz. Jak gotowe danie w słoiku: otwierasz i jesz.

Na przykładzie narzędzia appimagetool, które samo jest AppImage'em:

./appimagetool-x86_64.AppImage --version

bash: line 1: ./appimagetool-x86_64.AppImage: Permission denied

Pamiętasz klucze do pokojów? Pobrany plik nie ma prawa wykonywania. Nadajemy:

chmod +x appimagetool-x86_64.AppImage
./appimagetool-x86_64.AppImage --version

appimagetool, continuous build (git version 4919cc4), build 368 built on 2026-11-01 20:39:21 UTC

Działa. Usunięcie programu to usunięcie pliku.

Starsze AppImage'e do działania potrzebują biblioteki FUSE w wersji 2, której nowe systemy nie mają domyślnie. Na Ubuntu 24.04 ten pakiet zmienił nazwę i instalujesz go tak:

sudo apt install libfuse2t64

[RHEL] Na Fedorze i systemach z rodziny Red Hata szukasz pakietów fuse i fuse-libs.

Nowsze AppImage'e mają tę bibliotekę wbudowaną i nic nie trzeba doinstalowywać. Jeśli FUSE w ogóle nie działa, na przykład w kontenerze, jest wyjście awaryjne: --appimage-extract-and-run rozpakowuje program do folderu tymczasowego i uruchamia go stamtąd.

Minusy? Nikt Ci go nie zaktualizuje i nikt nie sprawdzi podpisu. Pobierasz tylko z oficjalnej strony producenta.

Kompilacja ze źródeł

Ostatni przycisk: „Source code”. Kod źródłowy, czyli przepis zamiast gotowego dania. Gotujesz sam.

Po co? Bo w hurtowni jest stara wersja. Na moim Ubuntu 24.04 jest htop 3.3.0, a autorzy wydali już 3.4.1. Zbudujmy go.

Najpierw narzędzia kuchenne: kompilator i biblioteki w wersji dla programistów, czyli z plikami nagłówkowymi. Pakiety z dopiskiem -dev na Ubuntu albo -devel na Red Hacie.

sudo apt install build-essential libncurses-dev

[RHEL] sudo dnf group install "Development Tools" i sudo dnf install ncurses-devel.

Pobieramy źródła i sprawdzamy, czy nikt ich nie podmienił. Autorzy publikują obok plik z sumą kontrolną:

curl -LO https://github.com/htop-dev/htop/releases/download/3.4.1/htop-3.4.1.tar.xz
curl -LO https://github.com/htop-dev/htop/releases/download/3.4.1/htop-3.4.1.tar.xz.sha256
sha256sum -c htop-3.4.1.tar.xz.sha256

htop-3.4.1.tar.xz: OK

I trzy słowa, które w świecie Linuksa brzmią jak zaklęcie:

tar xf htop-3.4.1.tar.xz
cd htop-3.4.1
./configure --prefix=/usr/local
make -j"$(nproc)"
sudo make install

./configure to inwentaryzacja kuchni. Sprawdza, czy masz kompilator i wszystkie biblioteki, i przygotowuje przepis pod Twój system. --prefix=/usr/local mówi, gdzie ma potem wylądować program. make to samo gotowanie, czyli kompilacja. -j"$(nproc)" znaczy „gotuj na tylu palnikach, ile masz rdzeni”. A make install rozkłada gotowe danie po półkach:

  /usr/bin/install -c htop '/usr/local/bin'
 /usr/bin/install -c -m 644 htop.desktop '/usr/local/share/applications'
 /usr/bin/install -c -m 644 htop.1 '/usr/local/share/man/man1'

Teraz w systemie są dwa htopy:

which -a htop
htop --version
/usr/bin/htop --version

/usr/local/bin/htop
/usr/bin/htop
/bin/htop
htop 3.4.1-3.4.1
htop 3.3.0

Wygrywa ten z /usr/local/bin, bo ten folder jest w PATH wcześniej niż /usr/bin. Trzeci wynik, /bin/htop, to ten sam plik co /usr/bin/htop, widziany przez drogowskaz /bin.

Uwaga, pułapka: menedżer pakietów nic nie wie o tym, co wrzuciłeś przez make install. Nie zaktualizuje tego, nie usunie i nie ostrzeże przed konfliktem. Wiele projektów, w tym htop, ma do sudo make install komendę w drugą stronę: sudo make uninstall. Ale nie licz, że każdy. Dlatego nie wyrzucaj folderu ze źródłami, dopóki program jest zainstalowany.

/usr/local i /opt: gdzie kłaść rzeczy spoza hurtowni

Pamiętasz plan biurowca z lekcji 8? Dwa piętra są zarezerwowane dla rzeczy, które nie przyszły z hurtowni dystrybucji. Menedżer pakietów ich nie rusza.

/usr/local to rzeczy zbudowane i zainstalowane lokalnie, ułożone tak jak w /usr: programy w /usr/local/bin, biblioteki w /usr/local/lib, dokumentacja w /usr/local/share. Tu domyślnie trafia prawie wszystko, co budujesz przez ./configure && make install.

/opt to duże programy, które przychodzą w całości, z własnym folderem: /opt/firma/program/. W środku mają często własne bin i lib. Typowo programy komercyjne i rzeczy od zewnętrznych firm.

Złota zasada: nigdy nie wrzucaj ręcznie plików do /usr/bin ani /usr/lib. To półki menedżera pakietów. Przy najbliższej aktualizacji nadpisze Twój plik i nawet nie zauważy.

Biblioteki: ldd, ldconfig, /etc/ld.so.conf.d

Biblioteka współdzielona to wspólna część, z której korzysta wiele programów. Jak wspólna kuchnia na piętrze w akademiku: nie każdy pokój ma własną lodówkę. Pliki bibliotek kończą się na .so, od „shared object”.

Z czego korzysta program? Pytasz ldd:

ldd /usr/local/bin/htop

	linux-vdso.so.1 (0x00007f55d44ef000)
	libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 (0x00007f55d4444000)
	libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007f55d4410000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f55d4327000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f55d4000000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f55d44f1000)

Po lewej nazwa biblioteki, której program potrzebuje, po prawej, gdzie system ją znalazł. libncursesw to biblioteka do rysowania okienek w terminalu, libc to podstawowa biblioteka języka C, z której korzysta prawie wszystko.

[RHEL] Na Red Hacie biblioteki 64-bitowe leżą w /usr/lib64.

Ważne ostrzeżenie z dokumentacji: nigdy nie uruchamiaj ldd na programie, któremu nie ufasz. W niektórych przypadkach ldd może przy tym wykonać kod tego programu. Dla obcych plików jest bezpieczniejsza wersja, która tylko czyta nagłówek:

objdump -p /usr/bin/htop | grep NEEDED

  NEEDED               libncursesw.so.6
  NEEDED               libtinfo.so.6
  NEEDED               libm.so.6
  NEEDED               libnl-3.so.200
  NEEDED               libnl-genl-3.so.200
  NEEDED               libc.so.6

Pokazuje tylko bezpośrednie zależności, ale niczego nie uruchamia.

Gdzie system szuka bibliotek? W standardowych folderach i w tych wymienionych w /etc/ld.so.conf:

cat /etc/ld.so.conf
ls /etc/ld.so.conf.d/

include /etc/ld.so.conf.d/*.conf
libc.conf
x86_64-linux-gnu.conf

Główny plik mówi tylko „wczytaj wszystko z folderu .d”. Ten sam wzorzec co przy hurtowniach apt: jeden plik na jedną sprawę. Ale system nie czyta tych plików przy każdym uruchomieniu programu, bo byłoby to za wolne. Komenda ldconfig przegląda wszystkie te foldery i buduje z nich spis w /etc/ld.so.cache. Programy korzystają ze spisu. O tym, co się dzieje, kiedy o tym zapomnisz, w typowym błędzie.

Jak to działa pod spodem

Kiedy uruchamiasz program, jądro widzi w nagłówku pliku, że potrzebuje on pomocnika: programu ładującego biblioteki. To ten ostatni wpis z ldd: /lib64/ld-linux-x86-64.so.2. Ładowacz czyta listę NEEDED, a potem dla każdej biblioteki szuka po kolei: w folderach ze zmiennej LD_LIBRARY_PATH, w spisie /etc/ld.so.cache i w folderach domyślnych. Znajduje, podpina do pamięci programu i dopiero wtedy program rusza.

A Flatpak, Snap i AppImage omijają cały ten problem, bo niosą biblioteki ze sobą. Snap to skompresowany obraz systemu plików, który snapd montuje w /snap/nazwa/wersja. AppImage to mały program startowy z doklejonym takim obrazem, montowanym przez FUSE przy każdym uruchomieniu. Flatpak trzyma aplikacje i runtime'y w /var/lib/flatpak i uruchamia je w piaskownicy zbudowanej z mechanizmów jądra, tych samych, z których korzystają kontenery. Cena? Więcej miejsca na dysku, bo ta sama biblioteka leży w kilku kopiach, i łatki bezpieczeństwa bibliotek przychodzą dopiero z nową wersją paczki.

Ściąga flag