Tutaj mam zamiar zamieścić opisy pewnych zadań administracyjnych, najczęściej tych, które różnią się w różnych dystrybucjach, a bez których nie sposób pracować w un*xie. Ja sam nie pracowałem jeszcze pod wszystkimi dystrybucjami, więc pewnie spora część tych porad będzie pochodzić od znajomych. Zaznaczam, że nigdy nie będę mechanicznie przepisywać manuali! Wszystkie tu zamieszczone sposoby będą pochodzić bezpośrednio od użytkowników, którzy coś tymi metodami zrobili.
Jest jedna pewna metoda na instalację ze źródeł: przeczytać pliki README
i INSTALL z tarballa. Tam zawsze jest opisany proces instalacji i ewentualne
buraki (na przykład opis instalacji pod SuSE jest często specjalnie
wymieniony, jako sprawiający problemy nie występujące w innych dystrybucjach).
Tam również są zamieszczone informacje, jakie biblioteki/programy są wymagane
do kompilacji tego programu.
Na szczęście większość programów instaluje się prawie identycznie: wchodzisz
do katalogu ze źródłami, odpalasz skrypt ./configure, po poprawnym
zakończeniu make, na koniec make install. Pierwszy etap
służy do ustalenia, jaki masz komputer i system operacyjny (bo przecież to nie
musi być PC ani Linuks) i gdzie masz niektóre wymagane biblioteki. Czasem
zdarza się, że musisz podać specjalne opcje, ale wszystkie są opisane
w ./configure --help (ciekawostka: możesz podać dokładnie, gdzie
powinien się program zainstalować: ./configure
--prefix=/opt/nazwa-programu spowoduje zainstalowanie programu
w /opt/nazwa-programu, czyli pliki wykonywalne będą
w /opt/nazwa-programu/bin; czasem jest to wygodniejsze, ale
będziesz sam musiał zadbać o to, żeby pliki wykonywalne znalazły się w ścieżce
$PATH). Potem make uruchamia proces
kompilacji programu. To trwa najdłużej. Czasem wystarczy kilka minut, czasem
trzeba nawet pięciu godzin (Qt 3.2 na Celeronie 400 z 192 MB RAMu).
Przeważnie długość procesu kompilacji jest proporcjonalna do wielkości źródeł.
Na zakończenie make install kopiuje skompilowane pliki do
odpowiedniego miejsca, czyli tam, gdzie miały się znaleźć (najczęściej
będziesz potrzebował uprawnień roota, więc na ten czas warto zrobić
su). Dobrym pomysłem jest zachowanie skonfigurowanych źródeł, bo
nie wiadomo, czy nie będziesz chciał zainstalować nowej wersji prgramu. Wtedy
odinstalujesz sobie wersję starą, a zainstalujesz nową. Proces deinstalacji
uruchamia się najczęściej poleceniem make uninstall, chociaż czasem
nie ma deinstalatora (vide gcc 2.95.3). Na szczęście przeważnie
wystarczy pousuwać pliki skopiowane przy instalacji, więc jeśli instalowałeś
program na przykład w /opt/nazwa-programu, to usuwasz jeden
katalog.
Przechowywanie źródeł jest, owszem, dobrym pomysłem, ale po co trzymać
w źródełkach skompilowane programy? Już po jednej kopii plików wykonywalnych
trzymasz, w katalogu instalacyjnym. Do tego tymczasowe pliki kompilacyjne,
w sumie zajmuje to około trzykrotnie więcej, niż same źródła. Do wyczyszczenia
source'ów służy polecenie make clean (konfiguracja zostanie
zachowana). Potem tar zcf /usr/local/src/zrodelka.tar.gz
katalog-instalacyjny i już nawet możesz usunąć źródła, bo masz je
zarchiwizowane w /usr/local/src.
Instalacja ze źródeł nie musi odbywać się dokładnie w ten sposób,
wszystko zależy od autora programu. Taki pine ma zupełnie własny
skrypt konfiguracyjny, a cdrtools nie mają go w ogóle, od razu
trzeba odpalić make. Dlatego bardzo ważne jest
przeczytanie, co autor programu napisał o instalacji. Ale pocieszę cię:
programy po bardzo dużej części mają standardowe "instalatory", a nawet
dostępne są już skompilowane w pakietach.
Na początku mojej kariery w świecie linuksowym kolega mi wcisnął RedHata 7.2.
W sumie nie żałuję, bo dużo się nauczyłem. Obsługa pakietów w RedHacie w sumie
nie jest najgorsza (choć wielu administratorów potrafi przyprawić o palpitację
serca). Podobno znacznie się poprawiła w RedHacie 9.0, niestety nie używałem
tej wersji, więc nie mam pewnych informacji. Do instalacji i usuwania
programów służy zgrabne polecenie rpm. Z grubsza rzecz biorąc ma
cztery wywołania: rpm -i nazwapakietu-versja.architektura.rpm ...,
rpm -q nazwapakietu, rpm -qa | grep szukane-wyrazenie,
rpm -e nazwapakietu. Pierwsze służy do instalacji pakietów, trzy
kropki oznaczają, że można (a czasem nie da się inaczej) instalować kilka
pakietów jednocześnie. Nazwa pliku pakietu wzięła się z konwencji nazywania
paczek rpm, na ten przykład kalkulator bc z płyty RedHata 7.2
(wersja 1.06-5, kompilowana pod procesory intelopochodne) będzie w paczce
bc-1.06-5.i386.rpm. W drugim wywołaniu rpm sprawdza,
czy pakiet o zadanej nazwie istnieje. Możesz spytać się tylko o nazwę, możesz
dodać numer wersji i architekturę. Trzecie wywołanie to w zasadzie listowanie
wszystkich pakietów i filtrowanie wyjścia w poszukiwaniu pakietów o nazwie
zawierającej wyrażenie. Ostatnie wywołanie to usunięcie pakietu.
Są jeszcze pewne opcje, przydatne przy instalacji: --test - nie
istaluje programu, ale sprawdza, czy by się zainstalował; --nodeps
- ignoruje zależności (nie polecam, zależności od czegoś w końcu są);
-v, -h - razem (-ivh) dają ładny pasek
postępu przy instalacji.
Pojawiło się słówko zależności. W Linuksie pewne programy wymagają
odpowiednich bibliotek do działania, na przykład mc wymaga
curses. System pakietów rpm sam wykrywa takie wymagania. To są właśnie
zależności. Ogólnie nie jest dobrym pomysłem pomijać zależności, bo taki
mc się nie uruchomi.
Jeszcze nie wspomniałem o jednej opcji. rpm -U
nazwapakietu-versja.architektura.rpm zaktualizuje pakiet, czyli zamiast
starych plików i bibliotek (oprócz, rzecz jasna, konfiguracji) powstawia
nowe.
W Slackware system pakietów został sprowadzony do niezbędnego minimum.
Wszystkie programy są dystrybuowane w archiwach tar skompresowanych
gzipem, jako *.tgz. Do instalacji pakietów służy
installpkg, do aktualizacji upgradepkg, do usuwania
- removepkg. Lista zainstalowanych pakietów znajduje się w katalogu
/var/log/packages, a dokładnie, to tu znajdują się pliki tekstowe
z opisem pakietu i listą plików, jakie pakiet dodał do systemu plików.
System pakietów tgz ma parę zalet, ale ma też jedną wadę: nie obsługuje
zależności. Podobno to też jest zaletą, ale jak zainstalujesz pakiet, może się
okazać, że program się nie uruchamia, bo brakuje biblioteki (żeby ułatwić
sobie sprawę stworzyłem prosty skrypcik, o czym dalej). Jednak same pakiety są
tak konstruowane, żeby tych "zależności" było jak najmniej. Oczywiście nie da
się w rozsądny sposób ominąć faktu, że mc wymaga curses,
ale już nie ma takich bzdurnych wymagań, że mc nie uruchomi się, bo
nie ma gpm (przykład wzięty z sufitu). No a dzięki temu, że
zależności prawie nie ma, a pakiet to zwykły zgzipowany tar, pakiety
Slackware'a nadają się jak żadne inne do instalacji na każdej innej
dystrybucji. Sam używałem (a raczej zainstalowałem i ze dwa razy uruchomiłem)
wspomnianego mc ze Slackware na RedHacie 7.2 - działał lepiej, niż
z płyty instalacyjnej RedHata :))
Od siebie dodam, że do Slackware 8.1 dopisałem kilka niedużych skrypcików
wspomagających administrację: pkgtools (dział
Radosna Twórczość). To jest zwykła paczka
tgz, można ją zainstalować poleceniem installpkg. Lista plików do
Slackware 8.1.0.1, 9.0 i 9.1 do ściągnięcia w tym samym miejscu.