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

Zakładam, że kompilacja przebiegła bezproblemowo. Jednymi z ostatnich komunikatów po instalacji w dystrybucji Gentoo są często informacje o tym co trzeba zrobić, żeby uzyskać w pełni funkcjonalny, działający produkt. To według mnie kolejna zaleta, która jest przydatna szczególnie wtedy gdy poruszamy się po nowym gruncie, tj. testujemy jakis nieznany nam w szczegółach pakiet a chcemy go szybko uruchomić. Instrukcja jest dobrze sformatowana, a ze względu na to, że korzystamy z kolorowej konsoli - trudno ją przeoczyć. Dodatkowo w przypadku instalacji kilku pakietów emerge na zakończenie instlacji wyświetli w podsumowaniu informacje z każdego z nich. Są jeszcze inne sposoby na to, żeby nie przeoczyć komunikatów (o tym innym razem).
W wypadku subversion wygląda to tak:

* Subversion Server Notes
* -----------------------
*
* If you intend to run a server, a repository needs to be created using
* svnadmin (see man svnadmin) or the following command to create it in
* /var/svn:
*
* emerge --config =dev-util/subversion-1.6.2
*
* Subversion has multiple server types, take your pick:
*
* - svnserve daemon:
* 1. Edit /etc/conf.d/svnserve
* 2. Fix the repository permissions (see "Fixing the repository permissions"
)
* 3. Start daemon: /etc/init.d/svnserve start
* 4. Make persistent: rc-update add svnserve default
*
* - svnserve via xinetd:
* 1. Edit /etc/xinetd.d/svnserve (remove disable line)
* 2. Fix the repository permissions (see "Fixing the repository permissions"
)
* 3. Restart xinetd.d: /etc/init.d/xinetd restart
*
* - svn over ssh:
* 1. Fix the repository permissions (see "Fixing the repository permissions"
)
* Additionally run:
* groupadd svnusers
* chown -R root:svnusers /var/svn/repos
* 2. Create an svnserve wrapper in /usr/local/bin to set the umask you
* want, for example:
* #!/bin/bash
* . /etc/conf.d/svnserve
* umask 007
* exec /usr/bin/svnserve ${SVNSERVE_OPTS} "$@"
*
* - http-based server:
* 1. Edit /etc/conf.d/apache2 to include both "-D DAV" and "-D SVN"
* 2. Create an htpasswd file:
* htpasswd2 -m -c /var/svn/conf/svnusers USERNAME
* 3. Fix the repository permissions (see "Fixing the repository permissions"
)
* 4. Restart Apache: /etc/init.d/apache2 restart
*
* Fixing the repository permissions:
* chmod -Rf go-rwx /var/svn/conf
* chmod -Rf g-w,o-rwx /var/svn/repos
* chmod -Rf g+rw /var/svn/repos/db
* chmod -Rf g+rw /var/svn/repos/locks
*
* If you intend to use svn-hot-backup, you can specify the number of
* backups to keep per repository by specifying an environment variable.
* If you want to keep e.g. 2 backups, do the following:
* echo '# hot-backup: Keep that many repository backups around' > /etc/env.d/80
subversion
* echo 'SVN_HOTBACKUP_BACKUPS_NUMBER=2' >> /etc/env.d/80subversion
*
* Subversion contains support for the use of Memcached
* to cache data of FSFS repositories.
* You should install "net-misc/memcached", start memcached
* and configure your FSFS repositories, if you want to use this feature.
* See the documentation for details.
*
>>> Regenerating /etc/ld.so.cache...

>>> Recording dev-util/subversion in "world" favorites file...

Emerge oprócz wymienionych już cech (instalacja, dobór flag, changelog, itd.) jest w stanie skonfigurować zainstalowany pakiet - oczywiście o ile ten pakiet posiada taką funkcjonalność (o tym innym razem). Jak widać, po instalacji menadżer pakietów zaleca mi skonfigurowanie pakietu. Mam to zrobić za pomocą komendy:

# emerge --config =dev-util/subversion-1.6.2


Configuring pkg...

* >>> Initializing the database in //var/svn ...
* >>> Populating repository directory ...
* >>> Setting repository permissions ...

Ponieważ w wypadku subversion istnieje kilka trybów uruchomienia serwera repozytorium, które podaje nam instrukcja - konieczne jest wykonanie instrukcji odpowiednich dla wybranego rodzaju pracy serwera. Dla mnie to dodatkowy plus jeśli chodzi o Gentoo - instalowane pakiety dostarczane są z dokładną instrukcją. Dzięki temu mam wgląd w podstawowe możliwości - co dodatkowo ułatwia zaznajomienie się z funkcjonalnością instalowanego pakietu.
Jak widać subversion może działać jako:
- osobny daemon (o tym innym razem)
- daemon uruchamiany w miarę potrzeby poprzez daemon'a xinetd (o tym innym razem).
- svn po ssh - czyli tunelowanie połączenia z repozytorium za pomocą ssh (o tym innym razem)
- usługa na protokole HTTP - poprzez serwer apache

Ja wybiorę repozytorium działające po protokole http.
Muszę więc wykonać czynności konfiguracyjne specyficzne dla serwera apache.
1. edycja pliku /etc/conf.d/apache2 i dodanie do zmiennej APACHE2_OPTS dwóch makr "-D DAV" i "-D SVN"
Zatrzymajmy się tu na chwilę - pojawiło się trochę nowości - wyjaśnię po kolei większość z nich.
Po pierwsze katalog /etc/conf.d - to specjalny katalog, w którym znajdują się ustawienia startowe poszczególnych usług uruchamianych w systemie. W innych dystrybucjach analogiczne informacje są często przechowywane w katalogu /etc/defaults. Tak więc plik /etc/conf.d/apache2 jest plikiem konfiguracyjnym skryptu startowego serwera apache. Skrypty startowe znajdują się w katalogu /etc/init.d i mają taką samą nazwę jak pliki konfiguracyjne z /etc/conf.d. Makro definiowane przez nas służy najczęściej (w wielkim skrócie) do tworzenia warunków w konfiguracji serwera przy których dany moduł lub dana konfiguracja ma być wczytana, np. możemy za pomocą niego definiować w konfiguracji kiedy moduł ma być wczytany. Pozwolę sobie wsadzić tu ni z gruszki ni z pietruszki fragment konfiguracji jaka mogła by być użyta w przypadku makra DAV:

< IfDefine DAV>
LoadModule mod_dav.so
</IfDefine>

2. Stworzenie pliku htpasswd:

# htpasswd2 -m -c /var/svn/conf/svnusers krzysiek

Plik ten wykorzystamy do przechowywania bazy użytkowników, którzy później bedą mieli dostęp do repozytorium, po wcześniejszym uwierzytelnieniu. Istnieje wiele mechanizmów uwierzytelniania użytkowników poprzez serwer apache (m.in. dlatego korzystamy z apache'a) - my w tej chwili skorzystamy z domyślnego jaki proponuje nam subversion.
3. Poprawki w ustawieniu uprawnień do plików:

# chmod -Rf go-rwx /var/svn/conf
# chmod -Rf g-w,o-rwx /var/svn/repos
# chmod -Rf g+rw /var/svn/repos/db
# chmod -Rf g+rw /var/svn/repos/locks

Muszę jeszcze skonfigurować serwer apache. Ponieważ na razie chcę uruchomić repozytorium skorzystam z gotowca. Ponieważ ustawiłem przy instalacji subversion USE flagę apache2 - zostały zainstalowane dodatkowe moduły do apache'a. Ich konfiguracja znajduje się w pliku /etc/apache2/modules.d/47_mod_dav_svn.conf. Wyedytuję ten plik i odkomentuje wszystkie linie z przykładową konfiguracją, które się tam znajdują.

4. Uruchom/zrestartuj serwer apache

# /etc/init.d/apache2 restart

Sprawdźmy czy działa?

# svn info http://localhost/svn/repos/
Authentication realm: Subversion repository
Password for 'root':
svn: Server sent unexpected return value (500 Internal Server Error) in response to OPTIONS request for 'http://localhost/svn/repos'

Nie działa - ale rozczarowanie. Pomyślmy - co może być nie tak?
Komunikat wskazuje na błąd po stronie serwera www. Zajrzę w logi błędów apache'a (error logs).

# tail /var/log/apache2/error_log

[Thu Jul 09 09:25:28 2009] [notice] caught SIGTERM, shutting down
[Thu Jul 09 09:25:57 2009] [notice] Apache/2.2.11 (Unix) DAV/2 mod_ssl/2.2.11 OpenSSL/0.9.8k SVN/1.6.2 PHP/5.2.9-pl2-gentoo configured -- resuming normal operations
[Thu Jul 09 09:29:54 2009] [error] [client 127.0.0.1] (13)Permission denied: Could not open password file: /var/svn/conf/svnusers

aha - uprawnienia do pliku - chłopaki w Gentoo coś przegapili w instrukcji - zgłoszę na bugs.gentoo.org
Ustawię poprawnie uprawnienia dla całego repozytorium

# chown -R apache:apache /var/svn

Sprawdzę teraz:

# svn co http://localhost/svn/repos/
Authentication realm: Subversion repository
Password for 'root':
Authentication realm: Subversion repository
Username: krzysiek
Password for 'krzysiek':
-----------------------------------------------------------------------
ATTENTION! Your password for authentication realm:

Subversion repository

can only be stored to disk unencrypted! You are advised to configure
your system so that Subversion can store passwords encrypted, if
possible. See the documentation for details.

You can avoid future appearances of this warning by setting the value
of the 'store-plaintext-passwords' option to either 'yes' or 'no' in
'/root/.subversion/servers'.
-----------------------------------------------------------------------
Store password unencrypted (yes/no)? n
Please type 'yes' or 'no': no
Checked out revision 0.

Jest OK.
UWAGA! Zwróćcie uwagę na komunikat (zawsze zwracajcie uwagę na komunikaty) - warto wyłączyć przechowywanie haseł w pliku na dysku.
Robimy to ustawiając opcję store-plaintext-passwords na no w pliku /root/.subversion/config

I to na tyle na dziś. Następnym razem zajmę się omówieniem podstaw obsługi repozytorium subversion.

W najbliższym czasie wspomnę też o skryptach startowych Gentoo i omówię pominięte dziś punkty z instrukcji tj. snv_hot_backup i pakiet memcached.

Daniel Robbins o Gentoo, zarządzaniu pakietami

W wolnym czasie polecam wywiad z Danielem Robbinsem - twórcą dystrybucji Gentoo. Ciekawie o Portage'u jak o przepisie na instalację - bardzo trafne spostrzeżenie.

Sudo - nadawanie specjalnych uprawnień

Ponieważ nie zamierzam przepisywać, podam link do dobrego przewodnika po komendzie sudo. O dziwo jest taki przewodnik zrobiony przez Gentoo. To kolejna zaleta tego projektu - świetna, dogłębna i spójna dokumentacja.

Po zaznajomieniu się z komendą czas na praktykę.
Ja w swoim zastosowaniu, w stawianym systemie chcę nadać możliwość instalowania pakietów za pomocą polecenia emerge jednemu użytkownikowi. Jak to zrobić?
Proponuję tak:

# visudo
-bash: visudo: command not found

O cholewcia - nie jest zainstalowane. Więc poszukajmy w portage'u:

emerge --search sudo

W czasie kiedy to polecenie się wykonuje dopiszę kolejną według mnie (niewielką) zaletę Gentoo -w porównianiu do dystrybucji debianowych jedną komendą zainstalujemy, wyszukamy pakiet - w Debianie są osobne i nieintuicyjne apt-get (instalacja) apt-cache search(bodajże - wyszukiwanie).
Dobra - mam już wyniki - a wśród nich:

Searching...
[ Results for search key : sudo ]
[ Applications found : 6 ]

* app-admin/sudo
Latest version available: 1.7.1-r1
Latest version installed: [ Not Installed ]
Size of files: 738 kB
Homepage: http://www.sudo.ws/
Description: Allows users or groups to run commands as other users
License: as-is BSD

Ponieważ emerge --search wyszukuje pakiet przeglądając na bieżąco wszystkie ebuildy w portage'u (/usr/portage - chyba wszystkie - tak mi się wydaje - a jeśli nie to metadata) nieraz możemy się poirytować czasem trwania wyszukiwania - jak to miało miejsce w moim wypadku. Proponuję używać komendy eix. hmm.. pryska zaleta jednej komendy do wyszukiwania i instalacji - no cóż - ale za to mamy szybko działającego eix'a - apt-chache strasznie muli mimo, że podobnie jak eix wyszukuje dane we własnej, zindeksowanej wcześniej bazie pakietów.
eix instaluję tak (warto zainstalować z bazą sqlite - odpowiednia flaga jest przy pakiecie):

# emerge -av eix

Zalecam używanie opcji --verbose --ask przy każdej instalacji - zawsze warto mieć wgląd w to co się będzie działo niż na ślepo instalować.

Zainstaluję w końcu sudo:

# emerge -av sudo
These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild N ] app-admin/sudo-1.7.1-r1 USE="pam -ldap -offensive (-selinux) -skey" 739 kB

Total: 1 package (1 new), Size of downloads: 739 kB

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

I już. Teraz nadaję uprawnienia użytkownikowi:

# visudo

Dodaję linię:
user localhost = /usr/bin/emerge

i już - użytkownik user może używać komendy emerge.

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

Ostatnio zakończyłem na sprawdzeniu znaczenia USE-flag za pomocą komendy euse. Pora powiedzieć trochę więcej o tych flagach.
Większość pakietów (programów) dostępnych w dystrybucjach Linuksa rozprowadzanych jest na licencji GPL lub BSD (są też rzadziej używane LGPL, MIT, etc.), co oznacza, że źródła tych programów dostępne są w sieci bezpłatnie. Autor udostępnia swoją pracę - umożliwiając nam jednocześnie wprowadzanie w niej zmian na określonych licencją warunkach. Co to oznacza w praktyce?
Na przykład to, że możemy taki pakiet ściągnąć i zainstalować na swoim komputerze za darmo. Ponieważ są to jednak wyłącznie źródła, a nie gotowy do uruchomienia program, konieczna jest ich kompilacja do wersji binarnej. Każdy dobrze przygotowany pakiet źródłowy zawiera pliki INSTALL i README, w których autor opisuje sposób instalacji. Najczęściej są to trzy kroki:
- konfiguracja pakietu (./configure) z odpowiednimi opcjami
- kompilacja - make
- instalacja - make install

W wypadku wielu pakietów oprogramowania - szczególnie tych bardziej zaawansowanych - np. subversion'a pierwszy krok (konfiguracja) może przysporzyć sporego bólu głowy. Musimy określić wiele ustawień dotyczących instalowanego pakietu, m.in.:
- gdzie ma być zainstalowany (domyślnie jest to zazwyczaj /usr/local)
- czy stworzyć biblioteki umożliwiające obsługę subversion z poziomu języka ruby, python, perl, java?
- czy skompilować z dodatkowymi modułami?
- czy skompilować moduły umożliwiające współpracę z repozytorium za pośrednictwem apache'a?
- czy dodać bibliotekę odpowiedzialną za obsługę repozytoriów za pomocą protokołu http?

Szczegółowe możliwości konfiguracji pojedynczego pakietu można sprawdzić po rozpakowaniu paczki źródłowej i uruchomieniu programu ./configure --help

Można oczywiście skorzystać z gotowych pakietów dostarczanych przez główne dystrybucje Linuksa. Co jednak zrobić gdy chcemy mieć dodatkową funkcjonalność, która przez dystrybucję nie została dodana do standardowego modułu, hmmm... Weźmy przykład przeglądarki tekstowej links. Standardowo dostarczana jest ona bez obsługi protokołu ssl (dziwne, nieprawdaż?). Co sie wtedy robi, ano przecież jest to oczywiste - odinstalowuje pakiet links i instaluje pakiet links-ssl. Ciemność widzę... No tak i tu zaczyna się opisywane już wcześniej pojęcie 'packaging hell'. Tysiące zależności, miliony pakietów, które tak naprawdę są tym samym pakietem, tylko z inną funkcjonalnością.
I tu z pomocą przychodzi nam rozwiązanie oferowane przez portage. Jeden pakiet, w którym to my definujemy jaką ma on mieć funkcjonalność. Robimy to właśnie za pomocą USE-flag. Weźmy nieszczęsny pakiet links - wiemy już jak dodać funkcjonalność ssl do pakietu w dystrybucji pakietowej dajmy na to Ubuntu - zainstalować links-ssl, odinstalować links, tyle że w odwrotnej kolejności. Nie zapomnij za żadne skarby o tym mój drogi czytelniku.
Co należy zrobić w Gentoo - ustawić dla pakietu flagę USE ssl i już. O resztę zadba za Ciebie portage.
Jak ustawić flagę?
- można ustawić ją globalnie - np. w pliku /etc/make.conf poprzez dodanie jej do parametrów zmiennej USE=""
- lokalnie - per pakiet - robimy to w pliku /etc/portage/package.use, wpis wyglada np. tak:
www-clients/links ssl
- w trakcie instalacji pakietu (niezalecane) - ustawiając zmienną USE przy wywołaniu emerge: USE=ssl emerge -av links (Ze względu na to, że flaga ta jest ustawiana przy pojedynczym wywołaniu emerge, jeśli nie dopiszemy ją na stałe pakiet przy następnej aktualizacji zostanie przekompilowany bez ssl)

Kiedy już nauczymy się ręcznie dodawać flagi możemy zacząć używać narzędzia do automatycznego ustawiania flag. Z tego co mi wiadomo działa ono tylko globalnie, tzn. dodaje wpisy w /etc/make.conf, które to tyczą się wszystkich pakietów. Wtedy flagę ssl możemy dodać tak:

# euse -E ssl
Zablokować globalnie kompilację z flagą:
# euse -D ssl
a usunąć wszelkie wpisy z daną flagą z /etc/make.conf tak:
# euse -P ssl

Proponuję przeczytać ze zrozumieniem man euse i wszystko powinno się wyjaśnić. W razie problemów można praktycznie przećwiczyć wszyskie przypadki.
Należy jednak pamiętać o tym, że zmieniamy globalne ustawienia, które są nadpisywane przez ustawienia per pakiet (/etc/portage/portage.use).
Możemy też wyłączać wybrane funkcjonalności - robimy to poprzedzając wybraną flagę znakiem '-' (minus). Działanie jest analogiczne jak w przypadku dodawania flag opisanego powyżej.

Proponuję potestować to u siebie, np. z użyciem opcji 'pretend' (nie instaluj tylko sprawdź) emerge'a:

# emerge -pv links

Dobrze, USE flagi już mamy z grubsza omówione. Wracajmy po tej krótkiej dygresji ;) do głównego wątku - czyli subversion. Skończyliśmy na:

# 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

Flagi, które nam się wyświetliły wynikają z ogólnych ustawień systemu, a w szczególności profilu tego systemu (ale o tym następnym razem). Jak widać w wypadku subversion aktywne flagi to:

apache2 berkdb dso nls perl python webdav-neon

Pozostałe flagi są nieaktywne (znak minus) - co oznacza, że dana funkcjonalność, za którą odpowiada flaga będzie niedostępna.
Zestaw flag mniej więcej nam odpowiada - chcemy mieć możliwość udostępniania repozytorium przez apache'a (flaga apache2), flaga webdav umożliwi klientowi svn (subversion) dostęp do repozytoriów poprzez http. Nie chcemy mieć natomiast flagi berkdb, która to określa sposób przechowywania danych w repozytorium. Nie będziemy korzystać z domyślnej bazy Berkley - zamiast niej skorzystamy z nowego systemu przechowywania danych w subversion - a mianowicie z subversion FSFS. O zaletach i wadach konkretnych sposobów przechowywania danych w repozytorium dużo inforamcji znajduje się w svn book, a konkretnie tu.

Skoro wiemy co i jak ma być ustawione - zmieniamy flagi dla pakietu. Ponieważ nie chcę zmieniać ich globalnie - wyłącze je na poziomie pojedynczego pakietu, tzn. w /etc/portage/package.use. Wpis wygląda następująco:

dev-util/subversion -berkdb

Teraz przystąpmy do instalacji

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 dso nls perl python webdav-neon -bash-completion -berkdb -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]

Jak widać flaga berkdb jest nieaktywna - czyli tak jak chcieliśmy. Zatem rozpocznijmy instalację - enter. Następuje konfiguracja i instalacja kolejnych pakietów z powyższej listy, zgodnie z kolejnością ich wyświetlania. Kolejne kroki instalacji odpowiadają krokom, które należy przejść przy ręcznej instalacji pakietu (configure, make, make install). Tyle tylko, że są one zautomatyzowane, ustystematyzowane i zgodne z konwencją (tak bardzo ważne słowo, które znacznie ułatwia życie jeśli się żyje w zgodzie z nim), powtórzmy KONWENCJĄ przyjętą w Gentoo. Zdejmuje to z nas ciężar pamiętania o tym co, gdzie z jakimi flagami i jak zostało zainstalowane. Od tej pory odpowiedzialność za pakiet, a w szczególności jego aktualizacje zrzucamy na barki Gentoo.

i to by było na tyle na dziś...


Przydatne linki:
Gentoo Portage part 1
Gentoo Portage part 2
Subversion Book

Jeszcze o zalecie portage

Jak wspominałem we wcześniejszym wpisie - portage umożliwia instalowanie i zarządzanie z poziomu repozytorium pakietami mplayer, skype, acrobat reader, sun java 1.4, picassa, etc. (jeśli ktoś pamięta inne to proszę dopisać). Są to pakiety, których nie umieszcza się w repozytoriach dystrybucji z różnych powodów - czasami producent nie zezwala na dystrybucję paczek instalacyjnych poza swoimi serwerami, innym razem wchodzą w grę względy patentowe (vide mplayer).
Powoduje to, że w dystrybucjach typu debian, ubuntu, suse, etc. instalacja i zarządzanie tymi pakietami to droga przez mękę (patrz np. tu). W gentoo instalacja takiego pakietu to wydanie polecenia emerge skype. System doda skype do listy zainstalowanych pakietów i w momencie gdy pojawi się nowsza wersja pakietu nastąpi jego automatyczna aktualizacja.
Może to i niewiele - powiedzą co poniektórzy - jednak gdy takich pakietów przybywa w systemie i trzeba pamiętać o ich ręcznej aktualizacji -ponieważ żaden rpm, apt nie poinformuje nas o tym)- administrator musi o tym pamiętać - a z tym to bywa różnie. Można oczywiście tworzyć dodatkowe procedury żeby o tym niezapomnieć, tylko że po co?
KISS - Keep It Simple Stupid - to według mnie jedna z podstawowych zasad jakimi powinien kierować się w swojej pracy administrator.

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.