Informacje o podstawach budowania własnych pakietów.
1. Budowa pakietu polega na przygotowaniu pliku PKGBUILD i innych np.: pakiet.install, pliki startowe itp…
2. W katalogu tymczasowym stwórz podkatalog o nazwie pakietu, który chcesz zbudować. Do niego skopiuj plik PKGBUILD.proto (powinien być w /var/abs) i zmień nazwę na PKGBUILD. Jeśli twój pakiet będzie wymagał jakichś specjalnych działań przed/po instalacji, upgradzie, usunięciu, skopiuj również install.proto i zmień nazwę na nazwa_pakietu.install.
3. W pliku PKGBUILD wpisz wartości do zmiennych:
pkgname – nazwa pakietu (taka sama jak nazwa katalogu z plikiem PKGBUILD). Ta zmienna NIE MOŻE być pusta!
przykład: pkgname=glibc
pkgver – wersja programu. Ta zmienna NIE MOŻE być pusta!
przykład: pkgver=2.3.3
pkgrel – „wydanie” pakietu. Ta zmienna powinna mieć format: Xnnd, gdzie X to numer kolejnego wydania. Numer wydania zmieniać się będzie przy każdej budowie pakietu. Ta zmienna NIE MOŻE być pusta!
przykład: pkgrel=23nnd
pkgdesc – Krótki opis pakietu. Ta zmienna NIE POWINNA być pusta!
przykład: pkgdesc=”GLIBC – Podstawowa biblioteka systemowa”
url – Adres strony domowej pakietowanego programu. Ta zmienna NIE POWINNA być pusta!
przykład: url=”http://www.glibc.org”
license – licencja na której wydano program (np. GPL, BSD).
przykład: license=GPL
depends – zmienna tablicowa, gdzie podawane są wszystkie nazwy pakietów niezbędnych do działania naszego programu. O tym jakie pakiety są niezbędne powie nam dokumentacja, znajomość pakietowanego programu i polecenie ldd.
przykład: depends=(’bash’ 'inny_pakiet’ 'jeszcze_inny_pakiet>=2.6.7′)
Zwróć uwagę, że można podawać tu dodatkowe wymogi co do wersji potrzebnego pakietu.
makedepends – jak wyżej, z tym że tu podajesz nazwy pakietów niezbędnych na etapie budowy pakietu i kompilacji, a niepotrzebne do prawidłowego działania.
przykład: makedepends=(’gcc’ 'binutils’)
conflicts – tu podajemy nazwy pakietów z którymi nasz pakiet NIE MOŻE być jednocześnie zainstalowany.
przykład: conflicts=(’uClibc’ 'cos_jeszcze’)
replaces – nazwa pakietu, który zostanie podmieniony przez nasz pakiet.
provides – pacman (i make_nnd_pkg) podczas instalacji, upgrade, usuwania i budowy pakietu sprawdzają zależności w zmiennych $pkgname i właśnie w $provides.
przykład: mamy dwie wersje kernela: kernel24-ide i kernel24-scsi. Ponieważ obie dostarczają tych samych narzędzi więc w zmiennej $provides oba pakiety maja ustawione „kernel24” natomiast pakiety, które do działania (lub budowy) wymagają obecności kernela mają w zmiennej $depends ustawione kernel24. Powoduje to, że bez znaczenia jaki kernel mamy zainstalowany w systemie – zależności zostaną spełnione.
install – nazwa pliku (zazwyczaj nazwa_pakietu.install), który będzie zawierał dyrektywy co należy zrobić przed/po instalacji, przed/po upgradzie, przed/po usunięciu pakietu. Często ta zmienna pozostaje pusta.
source – zmienna tablicowa w której są podane wszystkie pliki niezbędne do budowy pakietu: źródła programu dodatkowe scripty, patche, itp… Zazwyczaj źródła programu i patche ściągane są bezpośrednio ze strony domowej i podawany jest tylko url do plików. Dodatkowe scripty/pliki powinny być umieszczone w katalogu roboczym. Podczas budowy pakietu zostaną skopiowane do katalogu src, który będzie stworzony jako podkatalog katalogu roboczego.
przykład: source=(http://jakis_url/katalog/$pkgname-$pkgver jakis-plik inny_plik)
md5sums – zmienna tablicowa w której są podane sumy kontrolne wszytkich plików umieszczonych w zmiennej source.
przykład: md5sums=(’jhgjkhrjahgkrahgreu976′ '73642j34h5kj43h876gbv’ 'sjhgzrd876gragregfdfg’)
nosplit – zmienna przyjmująca jedną z dwóch wartości – 'yes’ lub 'no’. Jeśli w pliku PKGBUILD pojawi się nosplit=yes, to taki pakiet NIE BĘDZIE podzielony na pakiet, pakiet-devel, pakiet-man. Zazwyczaj nie jest potrzebne ustawianie tej zmiennej.
pre_packing – zmienna przyjmująca jedną z dwóch wartości 'yes’ lub 'no’. Ustawienie jej na wartość 'yes’ spowoduje wykonanie dodatkowej funkcji tuż przed skompresowaniem pakietu. Funkcję tę trzeba oczywiście przygotować i umieścić w pliku PKGBUILD.
Zmienne $nosplit i $pre_packing, oraz związane z nimi funkcje zostały przygotowane specjalnie dla NND.
Plik PKGBUILD rozumie również inne zmienne – są one opisane w man makepkg.
4. W pliku PKGBUILD popraw funkcję build(). W niej należy umieścić wszystko to co musimy wykonać aby skompilować program. Ta funkcja to nic innego jak kawałek scriptu shella, w którym krok po kroku przygotowujemy program do kompilacji – patchujemy, modyfikujemu pliki, dodajemy/usuwamy pliki itp… Tu również wywoływane jest polecenie ./configure (o ile jest) przygotowujące źródła do kompilacji. Uwaga, ponieważ większość programów jest domyślnie instalowana w /usr/local należy pamietać o dodaniu do ./configure parametru –prefix (np. ./configure –prefix=/usr). Nie wolno zapomnieć o „cd” do odpowiednich katalogów.
Dla typowego programu kompilowanego i instalowanego serią poleceń ’./configure && make && make install’ odpowiednia funkcja build() jest już zawarta w pliku PKGBUILD.proto. Na uwagę zasługuje linia:
make DESTDIR=$startdir/pkg install
Powoduje ona, że skompilowany program zostanie zainstalowany w katalogu wskazanym przez zmienną DESTDIR, a nie w strukturze katalogów naszego systemu. Zmienna $startdir to po prostu katalog, w którym znajduje się plik PKGBUILD.
UWAGA. Czasem zmienna DESTDIR nie jest wykorzystywana przez autorów programu. Wtedy należy zamiast niej użyć zmiennej prefix. Czyli powyższa linia wyglądałaby następująco:
make prefix=$startdir/pkg/usr install # przy założeniu, że użyte było ./configure –prefix=/usr
Niestety nie wszystkie programy instaluje się łatwo. Czasem wymagana jest edycja plików Makefile (lub innych), czasem należy zmienić domyślne położenie jakichś plików,
coś usunąć, zmienić nazwę jakiegoś pliku – możliwości są setki. Dokładne informacje o sposobie budowy i instalacji danego programu zazwyczaj są zawarte w pliku INSTALL w katalogu głównym źródeł programu. Zapoznanie się z tym, a także z innymi (README, readme.first) plikami dokumentacji zdecydowanie skróci czas budowy pakietu. Jeśli podczas prób dojdziesz do wniosku, że automatyczny podział kompilowanego programu nie jest poprawny, możesz dodać funkcję pre_packing() w której umieść instrukcje przenoszący pliki do odpowiednich katalogów.
O ile w obrębie katalogu $startdir możesz korzystać z funkcji build(), o tyle przenosznie plików pomiędzy katalogami pakiet <–> pakiet-devel <–> pakiet-man jest możliwe dopiero tuż przed kompresją pakietu. Wcześniej nie istnieją odpowiednie katalogi. Tu właśnie przydaje się użycie funkcji pre_packing(). Dodatkowo w obrębie tej funkcji jest możliwość wprowadzenia poprawek do plików PKGBUILD dla pakietów *-devel i *-man. Katalogi zawierające te pliki znajdują sie w katalogu nadrzędnym do $startdir.
5. Po przygotowaniu funkcji build() (i ewentualnie pre_packing()), należy w katalogu zawierającym plik PKGBUILD wykonać polecenie:
make_nnd_pkg -g >> PKGBUILD
spowoduje ono że zostaną pobrane źródła programu (na podstawie adresów ze zmiennej source) i dla każdego z plików źródłowych zostanie wygenerowana suma kontrolna i zapisana na końcu pliku PKGBUILD. Jeśli źródeł programu nie ma na dysku i są one pobierane z internetu to poza sumami kontrolnymi znajdzie się tam trochę śmieci. Należy usunąć wszytko co jest położone poniżej OSTATNIEGO znaku ’}’ i nie jest sumą kontrolną (patrz przykład md5sums). Jeśli korzystaliśmy z pliku PKGBUILD.proto to mamy teraz dwie zmienne md5sums – jedną pustą i jedną z właśnie wygenerowanymi sumami kontrolnymi. Należy usunąć pustą i przenieść wygenerowane sumy kontrolne powyżej funkcji build(). Nie jest to, co prawda, niezbędne, ale jest logiczne i pomaga utrzymać porządek w pliku.
6. Plik PKGBUILD został przygotowany do budowy pakietu. Teraz należy przygotować plik nazwa_pakietu.install, w którym będą dokładne dyrektywy, co należy zrobić przed/po instalacji, przed/po upgrade i przed/po usunięciu pakietu. Wzór takiego pliku jest w katalogu /var/abs (install.proto). Nie należy w nim zmieniac nic poza dodaniem odpowiednich poleceń do odpowiednich funkcji… np. po instalacji/usunięciu bibliotek należy wykonać polecenie 'ldconfig’, po instalacji/deinstalacji modułów jądra należy uruchomić 'depmod -a’. Tutaj również można umieścić komunikaty dla użytkownika (np. po zmianie kernela: „Uruchom Lilo…”) Niestety, na razie nie można używać tych funkcji interaktywnie – tzn. user nie może odpowiadać na pytania systemu.
Dalsze postępowanie opisane zostało w artykule Budowa pakietu i tworzenie repozytorium.
Michał Lechański (Mis’)
