[ << ] [ < ] [ Powrót ] [ > ] [ >> ]

1. Ebuild HOWTO

• Drzewo Portage
• Skrypty ebuild
• Położenia w systemie plików
• Skrypty i narzędzia Portage
• Zależności pakietu
• Testowanie i wdrożenie

1.a. Drzewo Portage

Wprowadzenie

Drzewo Portage zwykle znajduje się w katalogu /usr/portage i jest ułożone w hierarchicznej strukturze, składającej się z katalogów kategorii, w których znajdują się katalogi pakietów. Oto przykład: plik util-linux-2.11y.ebuild można znaleźć w katalogu /usr/portage/sys-apps/util-linux. W tym samym katalogu może znajdować się kilka innych wersji util-linux razem z wersją util-linux-2.11y.ebuild. Jest tak, ponieważ wszystkie pliki ebuild danego pakietu (niezależnie od wersji) mają wspólny katalog kategoria/pakiet w głównym katalogu /usr/portage, jednak tylko w przypadku, gdy nie zainstalowano dodatkowych repozytoriów.

Pobieranie drzewa Portage z CVS

W razie jakichkolwiek wątpliwości co do systemu CVS należy przeczytać dokument Praca z CVS w Gentoo, gdzie znajduje się znacznie więcej informacji na ten temat.

Drzewo Portage można znaleźć w module gentoo-x86 drzewa systemu Gentoo Linux. Aby pobrać moduł (około 350 megabajtów), najpierw należy skonfigurować CVS za pomocą powyższego przewodnika, a następnie pobrać moduł gentoo-x86 poleceniem checkout.

Co umieszczać (a czego nie) w drzewie Portage

Przed napisaniem jakiegokolwiek ebuilda powinniśmy przejrzeć bugs.gentoo.org w poszukiwaniu niezamieszczonego jeszcze w drzewie Portage pliku ebuild do pakietu, do którego sami chcieliśmy go pisać. W tym celu należy wejść na stronę bugs.gentoo.org, wybrać "query", jako produkt (product) wybrać Gentoo Linux, jako składnik (component) ebuilds. W polu tekstowym powinniśmy wpisać nazwę ebuilda, a jako status wybrać "NEW", "ASSIGNED", "REOPENED" i "RESOLVED" (to ostatnie jest ważne), a następnie zatwierdzić zapytanie. Leniwi niech po prostu klikną tutaj.

Drzewo Portage powinno przede wszystkim być używane do przechowywania plików .ebuild, a także wszelkich względnie małych plików pomocniczych, takich jak łatki lub przykładowe pliki konfiguracyjne. Pliki pomocnicze powinny być umieszczane w katalogu /usr/portage/kategoria/pakiet/files, aby nie zaśmiecać głównego katalogu kategoria/pakiet. Wyjątkiem od tej reguły są większe pliki łatek (zalecamy przyjąć górną granicę rozmiaru pliku na 20KB), które powinny zostać umieszczone na serwerach lustrzanych Gentoo, aby użytkownicy nie marnowali przepustowości ani przestrzeni dyskowej. Odradzamy też deweloperom umieszczanie w CVS plików binarnych (nie-ASCII). Jeśli jednak jest to konieczne (gdybyśmy na przykład chcieli zamieścić niewielki plik graficzny PNG), należy dodać go do CVS przy użyciu opcji -kb, tak jak poniżej:

# cvs add -kb mojobrazek.png

Opcja -kb instruuje CVS, że plik mojobrazek.png to plik binarny i powinien być specjalnie traktowany. Nie powinno się na przykład z oczywistych względów pozwolić na łączenie różnic między dwiema wersjami tego pliku. Skoro już mowa o łączeniu zmian, pliki poprawek zamieszczane w Portage nie powinny być kompresowane. Dzięki temu system CVS będzie mógł łączyć zmiany i poprawnie informować deweloperów o konfliktach.

Należy pamiętać, że pakiety, które wysyłamy jako stabilne muszą być gotowe do natychmiastowego użycia przez końcowych użytkowników. Musimy upewnić się, że posiadamy dobry zestaw domyślnych ustawień, który zadowoli większość z nich. Jeśli zaś nasz pakiet nie działa i nie mamy pomysłu jak sprawić, by działał, warto spojrzeć jak poradzili sobie z nią deweloperzy innych dystrybucji. Przykładów możemy szukać choćby w repozytoriach Mandrivy, Debiana lub Fedory.

Wysyłając pliki ebuild do CVS wszyscy deweloperzy powinni używać polecenia repoman commit zamiast cvs commit. Przed samym zamieszczeniem należy wykonać polecenie repoman full, aby upewnić się, że o niczym nie zapominamy.

Polityka wysyłania do CVS

• Zawsze należy wykonać polecenie repoman scan przed wysłaniem
• Zawsze należy wykonać polecenie repoman full przed wysłaniem
• Zawsze powinniśmy sprawdzić poprawność pliku package.mask przed jego wysłaniem przez wykonanie emerge --pretend mypkg i sprawdzenie czy nie zawiera konfliktów.
• Zawsze należy uaktualnić plik ChangeLog przed wysłaniem
• Zawsze powinniśmy wysłać uaktualniony plik package.mask przed uaktualnionym pakietem, w razie gdyby wystąpiły konflikty podczas wysyłania pliku package.mask.
• Zawsze powinniśmy wysyłać wszystkie pliki danego pakietu za jednym razem, nie pojedynczo. Jeśli wysyłamy pakiet z nową licencją albo taki, który jest zamaskowana, najpierw należy wysłać uaktualniony plik package.mask i/lub licencję, następnie plik ebuild, ChangeLog, łatki i plik metadata.xml wszystkie za jednym razem, aby uniknąć uszkodzenia systemów użytkowników.

Katalog files

Jak wspominaliśmy wcześniej, w każdym katalogu pakietu znajduje się podkatalog files/. W nim należy umieszczać wszelkie łatki, pliki konfiguracyjne lub inne pliki pomocnicze. Pliki większe niż około 20KB powinny być zamieszczane na serwerach lustrzanych, aby zmniejszyć ilość (niepotrzebnych) plików, które nasi użytkownicy będą musieli ściągnąć. Warto rozważyć taki schemat nazywania tworzonych poprawek, dzięki którym pakiet w ogóle się zbuduje, aby uwzględniały wersję w nazwie, na przykład pakiet-1.0-gentoo.diff lub prościej, 1.0-gentoo.diff. Przy okazji człon gentoo informuje, że poprawka ta została stworzona przez nas, deweloperów Gentoo, a nie pobrana z listy dyskusyjnej albo innego miejsca. Raz jeszcze: nie należy kompresować tych plików, ponieważ CVS nie radzi sobie dobrze z plikami binarnymi.

Warto rozważyć dodawanie przedrostka lub przyrostka (na przykład mypkg-1.0) do wszystkich plików, które umieszczamy w katalogu files/, aby pliki wykorzystywane z konkretną wersją ebuilda można było łatwo odróżnić od siebie. Ułatwia to porównywanie zmian pomiędzy poprawkami. Ogólnie jest to dobry pomysł. :) Możemy użyć innego przyrostka, jeśli chcemy, aby nazwa pliku łatki przekazywała więcej informacji.

Jeśli w katalogu files/ chcemy umieścić więcej plików, warto stworzyć podkatalogi, na przykład files/1.0/ i umieszczać odpowiednie pliki w ich własnych podkatalogach. Gdy używamy tej metody, nie jest już konieczne dodawanie informacji o wersji do nazw plików. Często jest to więc bardziej wygodne.

1.b. Skrypty ebuild

Wprowadzenie

Skrypty ebuild są podstawą całego systemu Portage. Zawierają wszelkie informacje potrzebne do pobrania, rozpakowania, skompilowania i instalacji zestawu źródeł, a także wykonania ewentualnych czynności poprzedzających i/lub następujących po instalacji i/lub deinstalacji. Pomimo iż większość Portage napisana jest w języku Python, same skrypty ebuild napisane są w bashu, ponieważ wykorzystanie języka skryptowego powłoki pozwala nam na wykonywanie komend tak samo jak z wiersza poleceń. Jednym z najważniejszych założeń projektowych skryptów ebuild jest nazwanie zawartych w nim poleceń analogicznie do tych, które wypisywalibyśmy, instalując pakiet ręcznie poprzez wiersz poleceń. Również z tego względu użycie składni basha jest bardzo wskazane.

Skrypty ebuild są interpretowane przez komendy ebuild i emerge. Wyobraźmy sobie polecenie ebuild jako niskopoziomowe narzędzie, służące do budowania. Potrafi zbudować i zainstalować pojedynczy ebuild, ale nic poza tym. Sprawdzi czy zależności są spełnione, ale nie będzie próbowało ich automatycznie spełnić. Z drugiej strony polecenie emerge jest wysokopoziomowym "silnikiem" dla polecenia ebuild i potrafi w razie potrzeby automatycznie zainstalować zależności, wykonać instalacje symulowane pretend, aby użytkownik mógł dowiedzieć się jakie pakiety zostaną zainstalowane - i dużo więcej. Ogólnie polecenie emerge jest lepsze od ebuild pod każdym względem, oprócz jednego. Za pomocą ebuild możemy stopniowo i pojedynczo wykonywać poszczególne fazy instalacji pakietu (pobieranie źródeł, rozpakowanie, kompilacja, instalacja i integracja pakietu z systemem). Jest to nieocenione narzędzie do debugowania dla deweloperów, ponieważ umożliwia zawężenie problemu z ebuildem do konkretnego fragmentu skryptu ebuild.

Nazewnictwo plików ebuild

Nazwa pliku ebuild składa się z czterech logicznych podsekcji:

pkg-ver{_suf{#}}{-r#}.ebuild

Pierwsza podsekcja, pkg, to nazwa pakietu. Powinna ona zawierać jedynie małe litery, cyfry od 0 do 9 oraz dowolną liczbę pojedynczych znaków minus (-), podkreślenia (_) lub plus (+). Przykłady: util-linux, sysklogd i gtk+. W Portage można znaleźć kilka pakietów, które nie spełniają tych wymogów, ale nasze pakiety muszą je spełniać.

Druga podsekcja, ver to wersja pakietu, która zwykle powinna odpowiadać wersji głównego archiwum ze źródłami. Najczęściej wersja składa się z dwóch lub trzech (czasem więcej) liczb oddzielonych kropkami, na przykład w ten sposób: 1.2 lub 4.5.2. Czasem bezpośrednio za ostatnią liczbą może pojawić się pojedyncza litera, na przykład 1.4b lub 2.6h. Wersja pakietu połączona jest myślnikiem z jego nazwą. Przykładowo: coś-1.0, bla-2.4.6.

Trzecia podsekcja, {_suf{#}} jest opcjonalna i może zawierać jeden z następujących przyrostków, wymienionych w kolejności od oznaczających najstarsze wydanie po najnowsze:

Po każdym z tych przyrostków może zostać dodana dodatnia liczba całkowita różna od zera, na przykład linux-2.4.0_pre10. Zakładając identyczne wersje, przyrostki są ułożone następująco (mniejszy oznacza starszy): _alpha < _beta < _pre < _rc < (brak przyrostka) < _p.

Podczas porównywania liczb poprzedzonych identycznymi przyrostkami za nowszą zostanie uznana większa liczba całkowita. Przykład: bla-1.0_alpha4 jest nowsza niż bla-1.0_alpha3.

Czwarta podsekcja nazwy pakietu oznacza wewnętrzny numer rewizji specyficznej dla systemu Gentoo Linux. Jest on opcjonalny, podobnie jak przyrostek. Znak # jest dodatnią liczbą całkowitą różną od zera, na przykład pakiet-4.5.3-r3.

Numer rewizji jest niezależny od wersji archiwum źródłowego i informuje, iż dostępna jest nowa i poprawiona wersja danego pakietu, specyficzna dla systemu Gentoo Linux. Pierwsze wydania pakietów nie mają numeru rewizji, co oznacza, że pakiet package-4.5.3 Portage potraktuje jak mającą zerowy numer rewizji. Oznacza to, że pakiety zliczane będą w następującej kolejności: 1.0 (wersja początkowa), 1.0-r1, 1.0-r2, itd.

Dokonując znacznych zmian w istniejącym pliku ebuild powinniśmy skopiować go do nowego pliku z numerem rewizji zwiększonym o 1. Należy pamiętać, aby zawsze odnotowywać zmiany zarówno w pliku ChangeLog, jak i w komunikacie wysyłania. Pominięcie choć jednego jest wbrew regułom.

...w zasadzie to mamy też piątą sekcję nazwy pliku ebuild -- samo rozszerzenie .ebuild.

Zawartość pliku ebuild

W tej części zajmiemy się wprowadzeniem do plików ebuild. Aby zobaczyć listę wszystkiego, co można w nich zrobić, warto przeczytać stronę podręcznika systemowego man, gdzie są informacje na temat formatu skryptów ebuild, ich zmiennych i funkcji: man 5 ebuild.

Nagłówki

Nagłówek wysyłanego pliku ebuild powinien być dokładnie taki sam jak ten w pliku /usr/portage/header.txt. Nie należy modyfikować go w żaden sposób, a przede wszystkim należy upewnić się, że linia zawierająca napis $Header: $ jest nienaruszona.

Pierwsze trzy linie powinny wyglądać mniej-więcej tak:

# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

Zmienne

Pierwsza część każdego pliku ebuild składa się z kilku zmiennych. Dzielą się one na trzy kategorie wymienione poniżej:

• READ: zmiennych tych możemy użyć, ale nie wolno ich ustawiać
• MUST: zmienne, które koniecznie należy ustawić
• OPT: zmienne, które powinniśmy ustawić

Funkcje

W plikach ebuild można zdefiniować wiele różnych funkcji, które kontrolują proces budowania i instalacji pakietu.

Funkcje pomocnicze

W naszych skryptach ebuild możemy użyć także następujących funkcji pomocniczych.

Funkcje pomocnicze dostarczone przez eutils.eclass

Możemy użyć następujących funkcji pomocniczych, które są dostępne w naszych ebuildach poprzez eclass "eutils". Należy upewnić się, że użyliśmy instrukcji inherit eutils, inaczej funkcje te nie będą działać.

Funkcje pomocnicze dostarczone przez flag-o-matic.eclass

Możemy użyć następujących funkcji pomocniczych, które są dostępne w naszych ebuildach poprzez eclass "flag-o-matic". Należy upewnić się, że użyliśmy instrukcji inherit flag-o-matic, inaczej funkcje te nie będą działać. Nigdy nie należy ręcznie modyfikować ustawień kompilatora, zamiast tego powinniśmy użyć funkcji z eclass flag-o-matic do czynności typu odfiltrowanie sprawiających kłopoty flag.

Funkcje pomocnicze dostępne w toolchain-funcs.eclass

Możemy użyć następujących funkcji pomocniczych, które są dostępne w naszych ebuildach poprzez eclass "toolchain-funcs". Należy upewnić się, że użyliśmy instrukcji inherit toolchain-funcs, inaczej funkcje te nie będą działać. Nigdy nie należy ręcznie modyfikować ustawień kompilatora lub binutils, zamiast tego powinniśmy użyć funkcji z eclass flag-o-matic do określenia kompilatorów i binutils.

Poniższe funkcje stosuje się, aby wspierać kompilację skrośną i kompilator icc. Powinny być one używane gdy pakiet wprost używa gcc, g++, ld, ranlib lub jakichkolwiek poniższych narzędzi. Na ogół pakiety, które używają narzędzi do autokonfiguracji wykrywają kompilację skrośną automatycznie i nie potrzebują poniższych funkcji.

Zasady pisania plików ebuild

Pliki ebuild są tak naprawdę skryptami powłoki, powinniśmy więc przy ich edycji używać trybu edycji skryptów powłoki naszego edytora. Należy stosować odpowiednie wcięcia, wyłącznie przy pomocy znaków tabulacji -- żadnych spacji. Należy się upewnić, że rozmiar tabulacji w naszym edytorze wynosi 4 spacje. Zawsze powinniśmy stosować nawiasy klamrowe wokół zmiennych środowiskowych, czyli ${P} zamiast $P.

Długie linie zawijamy za pomocą znaku ' \':

./configure \
--prefix=/usr || die "configure failed"

Więcej szczegółów znajdziemy w pliku skel.ebuild (zwykle znajduje się on w katalogu /usr/portage).

Warto zwrócić uwagę na domyślny plik vimrc w Gentoo jeśli używamy programu Vim do edycji plików ebuild/eclass. Znajduje się on w katalogu /etc/vim/vimrc i zawiera poprawne ustawienia wcięć i typów plików dla plików ebuild i eclass. Jeszcze więcej możliwości, w tym specjalne podświetlanie składni w plikach ebuild uzyskamy instalując app-vim/gentoo-syntax.

Na systemach innych niż Gentoo podobne ustawienia zyskamy, dopisując poniższe linijki do naszego pliku vimrc, albo jeszcze lepiej, instalując skrypty gentoo-syntax, które są dostępne na serwerach lustrzanych Gentoo..

au BufRead,BufNewFile *.e{build,class} let is_bash=1|setfiletype sh
au BufRead,BufNewFile *.e{build,class} set ts=4 sw=4 noexpandtab

Użytkownicy edytora Emacs powinni zainstalować pakiet app-emacs/gentoo-syntax (dla GNU Emacs) lub app-xemacs/gentoo-syntax (dla XEmacs). Pakiety te zawierają pliki konfiguracyjne pomagające Emacsowi prawidłowo zawijać wiersze i podświetlać składnię w plikach ebuild.

Jeśli zaś używamy edytora nano, szczęśliwie oszczędzono nam pracy. Wystarczy tylko odkomentować sekcję dotyczącą ebuildów w pliku /etc/nanorc.

Zmienne USE

Dzięki zmiennym USE możliwe jest skonfigurowanie Portage, aby globalnie i automatycznie włączało lub wyłączało pewne opcjonalne, ustawiane przy budowaniu funkcje programów. Oto przykład. Załóżmy, że jesteśmy fanami środowiska GNOME i chcielibyśmy, aby każdy ebuild, który daje możliwość wkompilowania opcjonalnej obsługi tego środowiska zrobił to. W tym przypadku należy dodać gnome do zmiennej USE w pliku /etc/make.conf, a Portage automatycznie będzie dodawał opcjonalną funkcjonalność GNOME do pakietów, jeśli jest ona dostępna. Podobnie, jeśli nie chcemy funkcji GNOME w naszych ebuildach, wystarczy upewnić się, że gnome nie jest dodane do zmiennej USE w pliku /etc/make.conf. System Gentoo Linux ma niemal przytłaczającą ilość opcji USE, dzięki czemu możemy skonfigurować go dokładnie tak jak chcemy.

W naszych skryptach ebuild możemy sprawdzać czy dana zmienna USE jest ustawiona za pomocą polecenia use <zmienna>. Najczęściej użyjemy tego polecenia analogicznie jak poniżej:

if use X; then
  # Komendy specyficzne dla X...
fi

Zmiennych USE można również używać w celu ustawiania zależności. Na przykład chcielibyśmy, aby pewien pakiet był wymagany tylko jeśli ustawiona jest pewna zmienna USE. Możemy tego dokonać za pomocą składni flaga? ( kategoria/pakiet ) w zmiennej DEPEND naszego pliku ebuild. W tym przypadku kategoria/pakiet będzie wymagana jedynie wtedy, gdy flaga będzie obecna w zmiennej USE. Możliwe jest także określenie jaka zależność ma zostać użyta jeśli pewna flaga USE jest ustawiona, a jaka ma zostać użyta, jeśli nie jest ustawiona: flaga? ( kategoria/pakiet ) i !flaga? ( innakategoria/innypakiet ). W tym przypadku jeśli flaga nie jest ustawiona, użyta zostanie innakategoria/innypakiet zamiast kategoria/pakiet. Należy upewnić się, że nasze ebuildy używają powyższej składni, a nie instrukcji warunkowych IF powłoki bash. Instrukcje warunkowe basha nie współpracują z cache'owaniem zależności przez Portage, więc używanie ich popsuje nasz ebuild.

Oto ważna wskazówka jak używać zmiennej USE. Najczęściej pakiety posiadają skrypt ./configure, za pomocą którego dokonuje się ich konfiguracji. Zwykle jeśli nasz ebuild używa ./configure, wszelka opcjonalna funkcjonalność zostanie włączona lub wyłączona przy budowaniu przez przekazanie odpowiednich parametrów do polecenia ./configure. Oto najlepszy sposób na obsłużenie tego:

DEPEND="X? ( >=x11-base/xfree-4.3 )
mysql? ( >=dev-db/mysql-3.23.49 )
apache2? ( >=net-www/apache-2 )
!apache2? ( =net-www/apache-1* )"

src_compile() {
  econf \
    $(use_enable X x11) \
    $(use_enable mysql) \
    || die "Error: econf failed!"
  emake || die "Error: emake failed!"
}

Takie podejście daje dobre wyniki. Nie musimy martwić się jakie są domyślne ustawienia mysql albo X (włączone/wyłączone), przekazujemy wprost funkcji econf co ma zrobić w oparciu o zmienną USE. Nie wspominając już o przejrzystości takiego kodu. :)

Czasami ebuildy będą posiadały konfliktujące opcjonalne funkcjonalności. Sprawdzanie tych konfliktów oraz drukowanie błędu jeśli odpowiedź jest twierdząca nie jest dobrym rozwiązaniem. Zamiast tego należy faworyzować jedną funkcjonalność przed drugą. W takich wypadkach należy zastanowić się, która opcja dostarcza bardziej powrzechną funkcjonalność, lub po prostu rzucić monetą. Przykładem mogą być ebuildy msmtp. Pakiet ten może współpracować z SSL dostarczanym przez GnuTLS, z SSL dostarczanym przez OpenSSL lub w ogóle nie posiadać wsparcia dla SSL. W związku z tym, że GnuTLS posiada szersze możliwości niż OpenSSL jest faworyzowane, a dokonuje się tego w następujący sposób:

src_compile() {
     local myconf

     if use gnutls ; then
         myconf="${myconf} --enable-ssl --with-ssl=gnutls"
     elif use ssl ; then
         myconf="${myconf} --enable-ssl --with-ssl=openssl"
     else
         myconf="${myconf} --disable-ssl"
     fi

     econf \
         # Other stuff
         ${myconf} \
         || die "configure failed"

     emake || die "make failed"
 }

Pod tym adresem możemy obejrzeć stale uaktualnianą tabelę zmiennych USE.

1.c. Położenia w systemie plików

Wprowadzenie do FHS

Standard rozmieszczenia katalogów w systemie plików ściśle odpowiada FHS, czyli File system Hierarchy Standard (standard hierarchii systemu plików). Uproszczony opis standardu podajemy poniżej; kompletną specyfikację można znaleźć pod adresem http://www.pathname.com/fhs/.

Jak umieszczać pakiety w systemie plików

Jeśli pakiet używa autoconf i automake, domyślne katalogi docelowe przy instalacji zwykle będą poprawne, z kilkoma wyjątkami:

• Jeśli instalujemy program w katalogu /bin, /sbin, /usr/bin lub /usr/sbin, dokumentacja man programu powinna zostać zainstalowana w katalogu /usr/share/man. Zwykle można to osiągnąć pisząc w skrypcie ebuild ./configure --mandir=/usr/share/man.
• Pliki dokumentacji GNU info zawsze powinny być instalowane w katalogu /usr/share/info, nawet jeśli dokumentacja należy do programów specyficznych dla X11, GNOME lub KDE. Zwróćmy uwagę: katalog /usr/share/info jest jedynym oficjalnym miejscem na pliki GNU info. Często skrypty ./configure domyślnie instalują pliki GNU info w katalogu /usr/info. W tej sytuacji należy przekazać ./configure parametr --infodir=/usr/share/info.
• Pliki dokumentacji są instalowane w katalogu /usr/share/doc, do podkatalogu, na którego nazwę składa się nazwa, wersja i rewizja danego programu. Dotyczy to wszystkich programów: GNOME, KDE, X11 i konsolowych. Niektóre programy jednak mogą dla swoich potrzeb instalować dodatkową dokumentację i pliki pomocnicze w hierarchii /usr/share.
• Programy i biblioteki specyficzne dla X11 zawsze powinny być instalowane w katalogu /usr, a nie bezpośrednio w /usr/X11R6. Tę hierarchię katalogów rezerwujemy dla samego Systemu X Window w Wersji 11, Wydaniu 6. Jest to być może bardziej dosłowna interpretacja standardu FHS niż w przypadku wielu innych dystrybucji.
• Podobnie programy GNOME i KDE powinny być zawsze instalowane w katalogu /usr.

Ogólnie nasze ebuildy powinny instalować pliki w katalogu /usr. Niektóre programy mogą być kompilowane i linkowane z bibliotekami GNOME, KDE oraz X11 lub bez nich, co może powodować zamieszanie. Rozwiązanie, jakie proponujemy to instalowanie wszystkiego w katalogu /usr, dzięki czemu autorzy skryptów ebuild unikną niejednoznacznych sytuacji i niepotrzebnych komplikacji. Miejsce, w którym będziemy instalować pliki programu nie mogą zależeć od obecności lub nieobecności jakichś zmiennych USE. Dlatego ebuildy w drzewie Portage praktycznie zawsze instalują swoje pliki wyłącznie w hierarchii katalogów /usr.

1.d. Skrypty i narzędzia Portage

Skrypty publiczne

Są to skrypty używane przez administratora systemu do instalacji i deinstalacji pakietów, a także przy opiekowaniu się bazą danych pakietów.

Skrypt ebuild jest głównym "silnikiem" systemu Portage; za jego pomocą wykonujemy wszystkie główne zadania, na przykład rozpakowanie, kompilacja, instalacja, integracja z systemem i deinstalacja pakietów. Używa się go w następujący sposób: ebuild ścieżka/do/pakiet.ebuild komenda. Oto dostępne polecenia:

Narzędzie emerge rekursywnie instaluje pakiet i wszystkie jej zależności w systemie plików. Komenda ta ma wiele opcji, których listę możemy zobaczyć, wydając polecenie emerge --help.

Narzędzie env-update uaktualnia pliki konfiguracyjne (w tym /etc/ld.so.conf i /etc/profile.env), aby uwzględniały zmiany wprowadzone przez zainstalowane pakiety.

Prywatne skrypty i komendy

Skryptów tych możemy użyć w naszych skryptach ebuild do wykonywania typowych zadań.

Jeśli ktoś lubi grzebać w kodzie, może przyjrzeć się poniższym skryptom, zaglądając do katalogu /usr/lib/portage/bin.

1.e. Zależności pakietu

Dlaczego zależności są ważne

Portage to coś więcej niż wygodny skrypt pozwalający w ujednolicony sposób budować oprogramowanie (program, bibliotekę) ze źródeł. Potrafi on także pobrać i zainstalować wszelkie potrzebne zależności, jeśli tylko podamy je w naszym skrypcie ebuild.

W oficjalnych ebuildach wszystkie zależności zostały już określone, więc gdy wydamy komendę emerge net-www/mozilla, Portage dopilnuje by wszystkie zależności niezbędne do zbudowania i uruchomienia Mozilli zostały zainstalowane zanim zacznie kompilować samą Mozillę.

Portage rozróżnia nawet między zależnościami potrzebnymi do zbudowania i do uruchomienia (Niestety, w tej chwili Portage jedynie instaluje wszystkie zależności potrzebne do budowania i uruchomienia. W przyszłości jednak będzie możliwe automatyczne odchudzenie systemu, aby pozostały w nim tylko zależności potrzebne do uruchamiania programów.

Jak definiować zależności w naszych skryptach ebuild (czyli atomy DEPEND)

Zmienna DEPEND w naszym pliku bla-x.y.z.ebuild mówi Portage jakie pakiety są potrzebne, aby zbudować program bla. Zmienna RDEPEND określa zaś jakie pakiety są potrzebne, aby uruchomić bla. Zmienna RDEPEND powinna być ustawiona jawnie, nawet jeśli jej wartość jest taka sama jak w przypadku DEPEND, ponieważ w przyszłości zmiennej RDEPEND nie będzie domyślnie przypisywana wartość DEPEND, w przypadku braku zdefiniowania tej pierwszej.

DEPEND="virtual/opengl
     dev-libs/libxml2"
RDEPEND="${DEPEND}"

Ten przykład informuje Portage o fakcie, że aby zbudować pakiet bla-x.y.z potrzebne będą pakiety virtual/opengl (więcej o kategoriach wirtualnych wkrótce) i dev-libs/libxml2. Nie jest podane jakie wersje opengl i libxml2 są potrzebne, co oznacza, że dobre będą wszystkie.

Rzecz jasna, "dobre będą wszystkie" w większości wypadków nie wystarczy. Jedynie w przypadku głównych bibliotek jest to wystarczające, ponieważ jego autorzy bardzo się starają, aby był on zawsze w stu procentach binarnie kompatybilny. W przypadku innych bibliotek możemy oczywiście podać wersje zależności.

>=sys-apps/bar-1.2
=sys-apps/baz-1.0

Znaki >= i = oznaczają to, czego możemy się po nich spodziewać; wersja 1.2 lub nowsza programu sys-apps/bar będzie się nadawać (oznacza to, że również wersja 2.0 sys-apps/bar też będzie odpowiednia), zaś wersja 1.0 programu sys-apps/baz będzie jedyną odpowiednią. Więcej informacji na temat wzorca wersji pakietów można znaleźć wyżej w rozdziale Nazewnictwo plików ebuild.

Oto inne sposoby na podawanie wersji zależności:

~sys-apps/qux-1.0
=sys-apps/bla-1.2*
!sys-libs/gdbm

~sys-apps/qux-1.0 wybierze najnowszą rewizję programu qux-1.0 w Portage.

=sys-apps/bla-1.2* wybierze najnowsze wersje spośród gałęzi 1.2, ale zignoruje 1.3 i wcześniejsze/późniejsze gałęzie. Tak więc bla-1.2.3 i bla-1.2.0 będą odpowiednie, zaś bla-1.3.3, bla-1.3.0 i bla-1.1.0 już nie. Warto zauważyć, że bla-1.22.3 też pasuje do wzorca, co czasami może spowodować problemy.

!sys-libs/gdbm uniemożliwi instalację tego pakietu jeśli gdbm jest zainstalowane.

Ważne uwagi

Przy konfiguracji zmiennych DEPEND i RDEPEND można popełnić wiele błędów. Oto kilka porad, dzięki którym możemy ich uniknąć.

• Zawsze należy podać kategorię.
  Na przykład powinniśmy napisać >=x11-libs/gtk+-2 zamiast tylko >=gtk+-2.
• Nie powinniśmy stawiać znaku gwiazdki (*) przy zależnościach typu >=.
  Prawidłowo powinniśmy napisać >=x11-libs/gtk+-2 zamiast >=x11-libs/gtk+-2*.
• Nie wolno definiować meta-pakietu jako zależności.
  Nie powinniśmy więc określić zależności od gnome-base/gnome, zamiast tego używamy konkretnej biblioteki, na przykład libgnome.
• Podajemy jedną zależność na linię.
  Definiowanie więcej niż jednej zależności w jednej linii sprawia, że kod jest brzydki i trudny do zrozumienia.
• GTK: Zawsze należy użyć zależności =x11-libs/gtk+-1.2* przy aplikacjach GTK+1.

Ponadto powinniśmy się upewnić, że podaliśmy wszystkie zależności naszego pakietu:

• Zajrzyjmy do plików configure.in lub configure.ac
  Poszukajmy w nich sprawdzania obecności pakietów. Warto zwrócić uwagę na sprawdzenia pkg-config lub funkcje AM_*, które szukają konkretnej wersji.
• Możemy przyjrzeć się dołączonym plikom .spec
  Zwykle dołączone pliki .spec mogą być źródłem informacji o zależnościach. Nie należy jednak traktować ich jako jedynego źródła.
• Poszukajmy strony internetowej aplikacji/biblioteki
  Autor często sugeruje na oficjalnej stronie jakich zależności wymaga jego program.
• Warto przeczytać pliki README i INSTALL dołączone do pakietu
  Zwykle zawierają one informacje przydatne przy budowaniu i instalowaniu pakietów.
• Należy pamiętać o zależnościach innych niż binarne, takie jak pkg-config, programy do generowania dokumentacji, itd.
  Proces budowania zwykle wymaga zależności takich jak intltool, libtool, pkg-config, doxygen, scrollkeeper, gtk-doc itp. Upewnijmy się, że zostały one podane.

Aby zapoznać się z najnowszymi informacjami o atomach DEPEND, należy przeczytać 5 sekcję dokumentacji systemowej man: man 5 ebuild.

1.f. Testowanie i wdrożenie

Plik ChangeLog

Za każdym razem gdy uaktualniamy (lub piszemy nowy) skrypt ebuild, musimy także uaktualnić (lub utworzyć) jego Changelog. Plik skel.ChangeLog zawiera przykładową treść i może zostać potraktowany jako wzór.

Funkcją pliku Changelog jest udokumentowanie co zostało zrobione, czemu zostało to zrobione i kto tego dokonał. Dzięki temu zarówno deweloperzy jak i użytkownicy mogą w łatwy sposób prześledzić zmiany.

Changelog jest głównie przeznaczony dla użytkowników, należy więc pisać krótko, na temat i unikać zbędnych technicznych szczegółów.

Przechowywanie plików ebuild lokalnie

Aby możliwe było testowanie skryptów ebuild oraz poinformowanie Portage o ich istnieniu, musimy umieścić je w określonym katalogu. Portage używa w tym celu zmiennej PORTDIR_OVERLAY, definiowanej przez użytkownika w pliku /etc/make.conf. Powinniśmy użyć tej zmiennej aby podać katalog, w którym będziemy trzymać nasze ebuildy (może to być na przykład /usr/local/portage).

W katalogu tym należy używać tej samej struktury (i tych samych kategorii) co w katalogu /usr/portage.

Gdy używamy PORTDIR_OVERLAY nasze ebuildy pozostaną w systemie i będą wciąż rozpoznawane przez Portage nawet gdy wykonamy polecenie emerge sync.

Testowanie pakietów

Zastanówmy się w jaki sposób przetestować czy nasz pakiet działa. Czasem deweloperzy od razu dołączyli polecenia make test lub make check, które sprawdzą podstawowe funkcje pakietu. Jeśli tak, to uruchomienie env FEATURES=test ebuild bla-x.y.z.ebuild test wykona je. Jeśli polecenia te nie działają poprawnie, spróbujmy je naprawić (i wysłać łatki autorom programu).

Jeśli takich poleceń nie ma, należy rozważyć dodanie funkcji src_test do naszego skryptu ebuild. Jest ona wykonywana przed funkcją src_install i może być bardzo pomocna przy testowaniu działania programu na różnych architekturach. Deweloperzy innych architektur będą nam wdzięczni jeśli dodamy tę funkcję, dzięki czemu nie będą musieli zagłębiać się w funkcjonowanie pakietu.

Należy jednak pamiętać o ogólnej zasadzie działania plików ebuild. Funkcja src_test nie może być interaktywna. Jeśli wymaga ona innych pakietów, należy użyć flagi USE test w celu podania dodatkowych zależności kompilacji w zmiennej DEPEND. Weźmy też pod uwagę, że funkcje src_test nie są zalecane przy graficznych aplikacjach korzystających z X, ponieważ użytkownik korzystający z Portage niekoniecznie będzie miał możliwość uruchomienia ich.

Przydatne narzędzia testujące

Istnieje kilka przydatnych narzędzi, które pomogą nam w pisaniu i opiekowaniu się naszymi ebuildami.

[ << ] [ < ] [ Powrót ] [ > ] [ >> ]

Materiał udostępniany na podstawie licencji Creative Commons - Attribution / Share Alike.