Instalacja pakietów w dystrybucji gentoo na przykładzie serwera subversion. Część I

Dystrybucja Gentoo zaadaptowała jedną z lepszych rzeczy jakie udało się wymyślić projektom z rodziny BSD, coś co nazywamy portami (ports). Oczywiście porty w wykonaniu BSD to wykorzystanie w bardzo ubogi sposób plików Makefile do kompilacji i instalacji pakietów ze źródeł. Co to tak dokładnie oznacza?
Proponuję zajrzeć tu ponieważ nie zamierzam wiernie przeklajać treści, które bardzo dobrze opisują system portage:
- portage - wikipedia
- oficjalna dokumentacja Gentoo

Ponieważ przy pisaniu bloga mam zamiar prowadzić swoją listę zalet i wad Gentoo - dopisuję pierwszą zaletę:
- Rewelacyjny system zarządzania instalacją oprogramowania - Portage.
Co tak naprawdę przemawia do mnie w portage?
- na pewno to, że za jego pomocą (korzystając z repoozytorium systemowego - głównego) zainstaluję pakiety typu mplayer, skype, kadu, adobe acrobat, itd. A moje działanie ograniczy się w najprostszym wypadku do wydania polecenia (przy instalacji skype):

emerge skype

System sam za mnie ściągnie pakiet z sieci i go zainstaluje. Spróbujcie zrobić to samo w innej dystrybucji. Nie znam takiej. W każdej z przez mnie testowanych (a było ich wiele) wymagane jest dodanie nowych repozytoriów, które nie zawsze dają powody żeby im kompletnie ufać (są to często repozytoria prowadzone przez osoby prywatne lub organizacje nieściśle związane z fundacją/firmą/etc. prowadzącą daną dystrybucję) - a to przecież musimy zrobić żeby zainstalować pakiet, którego nie ma w repozytorium dystrybucji.

- to, że gdy instaluję nowy pakiet widzę na podstawie USE-flag jakie możliwości mi daje lub jaką ma mniej więcej funkcjonalność (ale o tym za chwilę - omówię to na przykładzie).
- dodatkowo przy aktualizacji danego pakietu USE-flagi dają mi szybko wgląd w to jak w pakiecie zmieniła się funkcjonalność. Zapewnione to jest przez kolorowanie obsługiwanych przez pakiet flag i odpowiednie oznaczenie nowych flag w danej wersji softu.
- pakiety podzielone na kategorie
- możesz skonfigurować system dokładnie pod swoją architekturę sprzętową. Większość dystrybucji dostarcza pakiety skompilowanie pod i386, co poniektóre dodają i686. Tu możemy skorzystać z pełnych możliwości jakich nam dostarcza nasz hardware (choć musimy oczywiście wiedzieć co robimy)

Wadą Gentoo, która niejednej osobie dała się we znaki jest:
- konieczność kompilacji wszystkiego - spowalnia to zdecydowanie czas instalacji (choć widziałem pakety binarne, które wykonywały czynności okołoinstalacyjne nieraz dłużej niż zajmowała kompletna instalacja pod Gentoo). Na kompilację są sposoby (ccache, distcc) lub tworzenie pakietów (pkg, rpm) - kompilacja na jednej maszynie i rozprowadzenie skompilowanego pakietu na pozostałe maszyny. Gentoo posiada do tego ciekawy mechanizm, z którego muszę się przyznać nie korzystałem - catalyst
Z pozostałych warto powiedzieć o:
- rozmiarze, który drzewo portage zajmuje na dysku.

... dobra wracam do głównego nurtu
Część praktyczna

Zacznijmy więc instalację subversion.
Zakładam, że mamy skonfigurowany system portage (o tym opowiem następnym razem dość szczegółowo). Główny plik konfiguracyjny instalatora Gentoo - polecenia emerge - to plik /etc/make.conf.
A więc do dzieła:

# emerge --ask --verbose subversion
lub zamienie z krótkimi opcjami (gdy już nabierzemy wprawy):
# emerge --av subversion
These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild N ] dev-db/sqlite-3.6.13 USE="threadsafe -debug -doc -soundex -tcl" 2,716 kB
[ebuild N ] net-misc/neon-0.28.4 USE="nls ssl zlib -doc -expat -gnutls -kerberos -pkcs11 -socks5" LINGUAS="-cs -de -fr -ja -nn -pl -ru -tr -zh_CN" 758 kB
[ebuild N ] virtual/perl-MIME-Base64-3.07 0 kB
[ebuild N ] dev-perl/URI-1.35 94 kB
[ebuild N ] dev-util/subversion-1.6.2 USE="apache2 berkdb dso nls perl python webdav-neon -bash-completion -ctypes-python -debug -doc -emacs -extras -gnome-keyring -java -ruby -sasl -test -vim-syntax -webdav-serf" 5,343 kB

Total: 5 packages (5 new), Size of downloads: 8,910 kB

Would you like to merge these packages? [Yes/No]

Ojoj, troszkę tego jest. Pięć pakietów do instalacji. Dlaczego? Ponieważ instalacja subversion wymusza na portage'u konieczność instalacji dodatkowych pakietów, od których zależy poprawne funkcjonowanie subversion. Skupmy się wyłącznie na linijce z interesującym nas programem:

[ebuild N ] dev-util/subversion-1.6.2 USE="apache2 berkdb dso nls perl python webdav-neon -bash-completion -ctypes-python -debug -doc -emacs -extras"

Pierwsza część - w nawiasach kwadratowych mowi nam o statusie pakietu. W naszym wypadku jest to nowy pakiet (literka N). Pozostałe możliwe oznaczenia to:
U - update (zostanie zainstalowany pakiet w nowszej wersji)
F - fetch (pakiet źródłowy musi być ściągniety przez użytkownika, np. w wypadku sun-java-1.4, ponieważ musimy zaakceptować licencję na stronie SUNa. Podobnie jest z wieloma innymi pakietami np. Oracle'a. Jednak lepsze to niż nie mieć pakietu w repozytorium i samemu się borykać z jego ręczną instalacją)
f - fetch (jak poprzednio z tą różnicą, że pakiet jest już ściągnięty)
D - downgrade (zostanie zainstalowana starsza wersja pakietu - dzieje się to najczęściej gdy zainstalowany był pakiet zamaskowany)
S - pakiet slotowany (instalujemy inną wersję danego pakietu bez odinstalowywania istniejących w systemie- np. sun-jre-1.4, sun-jre-1.5 mogą być zainstalowane obok siebie w systemie i zamiennie używane w zależności od potrzeb)
R - reinstalacja (pakiet będzie przeinstalowany - numer wersji pozostaje ten sam)
I - interactive (wymagana interakcja z użytkownikiem - hmm chyba się z takim nie spotkałem - domyślam się, że może chodzić o akceptację umowy licencyjnej, etc.)
B - blocked (instalacja pakietu blokowana przez inny zainstalowany pakiet)
b - blocked (instalacja blokowana przez inny pakiet, jednak system portage rozwiąże automatycznie ten problem)

W nawiasie pojawia się też tajemniczy wyraz ebuild - jest to program, bezpośredni interfejs do systemu portage. Emerge instalując pakiety tak naprawdę wywołuje w odpowiedniej sekwencji program ebuild z właściwym parametrem (man ebuild).
W dalszej części linijki mamy nazwę pakietu wraz z wersją (subversion-1.6.2) poprzedzoną nazwą kategorii do której został on zaliczony (dev-util - narzędzia developerskie). Informacje te odzwierciedlają strukturę, która znajduje się w katalogu /usr/portage, gdzie znajduje się całe drzewo portage (ciekawskich zachęcam do sprawdzenia).
Kolejna część to:
USE="apache2 berkdb dso nls perl python webdav-neon -bash-completion -ctypes-python -debug -doc -emacs -extras"

Jest to informacja na temat flag USE (funkcjonalności), które pakiet obsługuje. Znak '-' minus mówi nam, że dana funkcjonalność nie zostanie włączona w bieżącej instalacji. Flagi w większości wypadków są opisowe. Jednak jeżeli dana flaga nic nam nie mówi możemy użyć polecenia euse:

# euse -i nls
global use flags (searching: nls)
************************************************************
[+ D ] nls - Adds Native Language Support (using gettext - GNU locale utilities)

local use flags (searching: nls)
************************************************************
[+ D ] nls (app-portage/eix):
Support foreign language messages (experimental; currently only de)

[+ D ] nls (net-analyzer/rrdtool):
Enable native language support (using intltool)

[+ D ] nls (net-irc/rbot):
Build and install translation for the messages coming from the bot and its plugins (through dev-ruby/ruby-gettext).

Opis euse - zostawiam do następnego razu. Jest już późno.