Pokazywanie postów oznaczonych etykietą euse. Pokaż wszystkie posty
Pokazywanie postów oznaczonych etykietą euse. Pokaż wszystkie posty

poniedziałek, 13 lipca 2009

Co nieco o euse i innych

Ponieważ pewnie wiele osób zauważyło, że euse nie jest demonem szybkości, warto zastanowić się nad alternatywami. Wcześniej jednak spróbujmy znaleźć powód wolnego działania euse.
Zaczynamy!
Gdzie znajduje się program euse:

# which euse

/usr/bin/euse

OK, mamy. Teraz nauczmy się wykorzystywać przydatne skróty shella. Strzałki w górę i dół na klawiaturze umożliwiają nam nawigację w historii wykonanych poleceń. Więc strzałka w górę i mamy poprzednio wykonane polecenie. Teraz naciśnijmy HOME i jesteśmy na początku linii, END - na jej końcu. O tym jak konfigurować własne skróty opowiem innym razem.
Wykorzystując tą wiedzę co by się za dużo nie napisać zmodyfikujmy tę linię, tak żeby zobaczyć czym jaki jest typ pliku euse:

# file `which euse`
/usr/bin/euse: Bourne-Again shell script text executable


aha - czyli skrypt Bash. Polecenie file wyświetla nam na podstawie swojej bazy informacje na temat typu pliku (polecam do szczegółowej lektury man).
Czym jest zaś tajemniczy ` - backquote (backtick)?
W tym miejscu następuje podmiana wywołania polecenia na wartość zwróconą po jego wykonaniu (command substitution lub bardziej po polsku - cytowanie polecenia). Czyli wszystko co znajdzie się pomiędzy znakami ` jest wykonywane a następnie wynik zwrócony jest podstawiany w to miejsce. Wywołania z użyciem backtick'ów (odwrotny apostrof) można zagnieżdżać, należy jednak pamiętać wtedy o użyciu znaku maskującego \ (tzw. backslasha). Backtick jest szczególnie użyteczny w skryptach, gdy chcemy podstawić gdzie możemy wykorzystać go do podstawienia wyniku wykonania polecenia pod zmienną (np.: ZMIENNA=`ls -l`). Zamiennie z backtickiem można stosować konstrukcję $(polecenie).

Skoro zaczynamy powoli wchodzić w shella nasuwają mi się dwa pytanka, a mianowicie:
- po czym poznać czy dana komenda to polecenie zewnętrzne, czy wbudowana komenda basha?
- dlaczego cd jest wbudowany w bash?

Zostawiam je na razie jako zadanie domowe - spróbujcie pogłówkować.

Teraz gdy dowiedzieliśmy się paru nowych rzeczy warto popatrzyc w źródła euse (nie zapomnijcie o wykorzystywaniu opisanych skrótów):

vim `which euse`

Ponieważ - jak stwierdziliśmy wcześniej - wyświetlanie informacji o flagach jest wolne skupmy się na tej operacji i trochę pogmerajmy w kodzie. Informacje wyświetlamy za pomocą opcji -i - poszukajmy:

while [ -n "${1}" ]; do
case "${1}" in
-h | --help) MODE="showhelp";;
-v | --version) MODE="showversion";;
-i | --info) MODE="showdesc";;
-I | --info-installed) MODE="showinstdesc";;
-l | --local) SCOPE="local";;
-g | --global) SCOPE="global";;
-a | --active) MODE="showflags";;
-E | --enable) MODE="modify"; ACTION="add";;
-D | --disable) MODE="modify"; ACTION="remove";;
-P | --prune) MODE="modify"; ACTION="prune";;
-*)


Jest w pętli odpowiedzialnej za odczyt argumentów wywołania (opcji) programu/skryptu (o tym innym razem). Jak widać (mniej lub bardziej) użycie tej opcji powoduje ustawienie w skrypcie zmiennej MODE na wartość showdesc.
Co się dzieje dalej?
Na samym końcu skryptu znajdziemy:

##### main program comes now #####

# disable globbing as it fucks up with args=*
set -f
parse_arguments "$@"
check_sanity

eval ${MODE} ${ARGUMENTS}
set +f


Jak widać mamy tu cały przepływ programu - kolejno wywołanie funkcji (zdefiniowanych powyżej) parse_arguments (parsowanie opcji), check_sanity (pomijam - pewnie sprawdzanie poprawności wywołania, opcji, etc.) i wykonanie funkcji o nazwie zdefiniowanej w zmiennej MODE (i wszystko się wyjaśniło - o eval powiem innym razem). Zaglądnijmy do tej funkcji (showdesc):

# This function takes a list of use flags and shows the status and
# the description for each one, honoring $SCOPE
showdesc() {
local descdir
local current_desc
local found_one
local args

args="${*:-*}"

if [ -z "${SCOPE}" ]; then
SCOPE="global" showdesc ${args}
echo
SCOPE="local" showdesc ${args}
return
fi

descdir="$(get_portdir)/profiles"

[...]

while [ -n "${1}" ]; do
if [ "${SCOPE}" == "global" ]; then
if grep "^${1} *-" "${descdir}/use.desc" > /dev/null; then
get_flagstatus "${1}"
foundone=1
fi
grep "^${1} *-" "${descdir}/use.desc"
fi
# local flags are a bit more complicated as there can be multiple
# entries per flag and we can't pipe into printf
if [ "${SCOPE}" == "local" ]; then
if grep ":${1} *-" "${descdir}/use.local.desc" > /dev/null; then
foundone=1
fi
grep ":${1} *-" "${descdir}/use.local.desc" \
| sed -e "s/^\([^:]\+\):\(${1}\) *- *\(.\+\)/\1|\2|\3/g" \
| while read line; do
pkg="$(echo $line | cut -d\| -f 1)"
flag="$(echo $line | cut -d\| -f 2)"
desc="$(echo $line | cut -d\| -f 3)"
get_flagstatus "${flag}"
printf "%s (%s):\n%s\n\n" "${flag}" "${pkg}" "${desc}"
done
fi
shift
done


Przy okazji takiego grzebania można sie trochę nauczyć i dowiedzieć o Gentoo i portage'u. Jak widać opisy flag globalnych - znajdują się w pliku profiles/use.desc w katalogu głównym systemu portage, natomiast flagi zdefiniowane w poszczególnych paczkach (lokalne) - w profiles/use.local.desc.
Patrząc na pętle łatwo zauważyć, że wyszukiwanie odbywa się za pomocą polecenia grep (o tym innym razem). W wypadku flag globalnych operacja jest dość szybka, jednak komplikuje się i wydłuża przy flagach lokalnych ze względu na ich format (warto zaglądnąć do tych plików). No i już wiemy dlaczego to tyle trwa.

Przeglądając źródła warto zwrócić jeszcze uwagę na komendę set +f/set -f, która odpowiada za obsługę globbingu w shellu - w skrócie ubogiego krewnego wyrażeń regularnych (o tym innym razem). Tu została zastosowana, żeby ominąć jej rozwinięcie/ewaluację w shellu - widać chłopaki mieli pewien problem z tym przy wywołaniu.

PS. Następnym razem opowiem o innych narzędziach do zarządzania flagami.
Zmieniam też nieco tryb pisania z pn-sobota na pn/sr/pt

piątek, 3 lipca 2009

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

sobota, 27 czerwca 2009

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.