Archiwa tagu: pacman

Przygotowanie plików do budowy pakietu

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’)

Budowa pakietu i tworzenie repozytorium

Budowanie pakietu. Krótki opis jak to zrobić oraz jak zbudować własne lokalne lub zdalne repozytorium.

1. Jeśli prawidłowo został zbudowany PKGBUILD, wszystko jest gotowe do budowy pakietu. W katalogu z plikiem PKGBUILD wykonujemy polecenie:

make_nnd_pkg

2. Po wydaniu polecenia make_nnd_pkg źródła zostaną pobrane z lokalnego cache (z intenetu zostały pobrane podczas generowania sum kontrolnych), sprawdzone zostaną sumy kontrolne plików, źródła zostaną rozpakowane. Następnie zostanie wywołana funkcja build() kompilująca i instalująca program w katalogu tymczasowym. Jeśli ustawiliśmy zmienną pre_packing=yes to po funkcji build(), kilku funkcji wewnętrznych zostaje wykonana funkcja pre_packing(). Jeśli wszystko poszło prawidłowo to po skompilowaniu zostaniemy zapytani o to czy chcemy wprowadzić poprawki do automatycznego podziału pakietów. Odpowiadamy ‚T’, sprawdzamy czy wszystko jest na swoim miejscu, wciskamy F10 aby wyjść z Midnight Commandera, skrypt kończy budować pakiet. Znów jesteśmy w katalogu z plikiem PKGBUILD, ale plików mamy już nieco więcej – mamy, przede wszystkim, pakiet (oraz pakiet-devel i pakiet-man, jeśli takowe zostały stworzone), mamy pliki filelist-* zawierające listy plików w każdym ze zbudowanych pakietów, mamy katalogi ‚src’, ‚pkg’, ‚dev_pkg’, ‚man_pkg’. Usuwamy wszystko poza tym co mieliśmy przed rozpoczęciem budowy pakietu. Można (a nawet powinno się) ostateczną budowę pakietu wykonać poleceniem:

make_nnd_pkg -cw /jakiś_katalog

spowoduje to, że wszystkie tymczasowe pliki zostaną usunięte automatycznie, a pakiety zostaną zapisane w katalogu /jakiś_katalog. Warto sobie taki katalog dla pakietów stworzyć…

3. Jeśli pakiet budowaliśmy jednym z podkatalogów drzewka cvs (NIE ZALECANE!!) to wykonujemy update i commit wprowadzonych zmian, następnie wychodzimy z naszego dotychczasowego katalogu do katalogu nadrzędnego, wchodzimy kolejno do katalogów *-devel i *-man (o ile istnieją) i w każdym z nich wykonujemy cvs update i commit. Jeśli budowaliśmy pakiet w katalogu tymczasowym to najpierw uaktualniamy pliki w odpowiednim katalogu dzewa cvs, a następnie robimy cvs update i commit.

4. Dla tych, którzy nie chcą/potrafią bawić się cvs (badź nie mają dostępu do cvs):
Tworzymy katalog tymczasowy nazywający się tak jak pakiet, kopiujemy do niego katalogi: pakiet, pakiet-devel, pakiet-man, oraz odpowiednie pliki pakietów. Tymczasowy katalog kompresujemy i wysyłamy do kogoś, kto wrzuci nam wszystko do cvs, wygeneruje bazy pakietów i zrobi update repozytorium.

5. Budowanie repozytorium lokalnego:
Mamy katalog (nazwijmy go np. lokalne) zawierający podkatalogi z plikami PKGBUILD i innymi niezbędnymi do budowy pakietów i drugi, zawierający zbudowany przez nas pakiety. Generujemy bazę danych pakietów poleceniem:

gensync /sciezka/lokalne /katalog/z/pakietami/lokalne.db.tar.gz

po chwili mamy w katalogu z pakietami bazę danych naszych lokalnych pakietów. Możemy teraz do pacman.conf dodać linie:

[lokalne]
Server = file:///scieżka/do/katalogu/z/pakietami

Od tej chwili pacman będzie synchronizował pakiety również z tym katalogiem.

6. Budowa repozytorium zdalnego przebiega tak samo. Jeśli chcemy robić samodzielnie update oficjalnych repozytoriów to niezbędne jest posiadanie na dysku WSZYSTKICH pakietów z repozytorium. Genereujemy bazę pakietów, a następnie podmieniamy/dodajemy/usuwamy odpowiednie pliki na serwerze.

Michał Lechański (Mis’)

NND – co i dlaczego

NND – jak kiedyś w PC World Computer napisano to dystrybucja o enigmatycznej nazwie. Jako jeden z autorów nie mogę się z tym zgodzić…
przecież ten skrót rozwija się bardzo prosto: Niestety Nie Działa
Mam nadzieję, że teraz już nie będzie to rozwinięcie obrazujące rzeczywistość NND. Ale jakby ktoś miał do nas pretensje, to stanowi ono znakomite wyjaśnienie wszystkich problemów – wszak oferujemy towar 100% zgodny z nazwą.
Niniejszy dokument jest wynikiem lenistwa i próbą wymigania się od konieczności odpowiadania na dziesiątki pytań dotyczących struktury, działania i funkcji poszczególnych elementów NND. Oczywiście nie ma tu miejsca, ani ja nie mam ochoty (i wystarczającej wiedzy), aby opisać wszystko ze szczegółami. Teorię Linuksa zostawmy więc i zajmijmy się tylko tym co w NND jest inne. Więc po kolei…

pacman – manager pakietów. Potrafi zainstalować, usunąć, zaktualizować pakiety NND. Pilnuje zależności pomiędzy pakietami. Pakiety można instalować z lokalnych lub zdalnych repozytoriów jak i z posiadanych na dysku pojedynczych plików. Wraz z Pacmanem dostajemy narzędzie make_nnd_pkg, (lub makepkg, ponieważ jest make_nnd_pkg jest symbolicznym linkiem do tego właśnie pliku) służące do budowy pakietów (prosimy o nieużywanie nazwy makepkg, ponieważ script zbuduje pakiet niezgodny z zalożeniami NND), gensync używany do generowania bazy pakietów, oraz kilka innych narzędzi które jeszcze nie zostały dodstosowane do specyfiki NND.

Pacmana używa się tak:

instalowanie pakietów:
pacman -S nazwa_pakietu

usuwanie pakietów:
pacman -R nazwa_pakietu

informacja o wersji zainstalowanego pakietu:
pacman -Q nazwa_pakietu

informacja o przynależności danego pliku do pakietu:
pacman -Qo /sciezka/plik

wyszukiwanie słowa w nazwach pakietów i ich opisach:
pacman -Ss szukane_słowo

instalacja pakietu z dysku
pacman -U /sciezka/plik

aktualizacja wszystkich zainstalowanych pakietów:
pacman -Suy

listowanie zainstalowanych pakietów:
pacman -Q

lista plików w pakiecie:
pacman -Ql nazwa_pakietu

oczywiście to tylko niektóre z możliwości pacmana. Wszystkie są opisane w manualu. Namawiam do przeczytania (niestety na razie po angielsku).
UWAGA! Pacman podczas instalacji/usuwania/upgrade pakietu prosi o potwierdzenie wykonania operacji. Można to „zautomatyzować” wydając polecenia w takiej formie:

yes | pacman -Suy

dodanie na początku polecenia ‚yes’ i potoku spowoduje, że pacman będzie działał bez dodatkowych pytań. Proponowałbym jednak używać tego ułatwienia „z głową”… wszak każdy kij ma przecież dwa końce 🙂

pakiety – zwykłe archiwa *.tar.gz zawierające dodatkowe pliki służace do budowy bazy pakietów i stanowiące źródło informacji o pakiecie.

net_conf – script konfigurujący nasze połączenia sieciowe, zarówno lokalne jak i internetowe.

nndpkg – quasi graficzny interfejs do podstawowych funkcji pacmana. Pozwala listować/instalować/usuwać pakiety, upgradeować system itp.

rc.conf – plik konfiguracyjny, możemy tam ustawić kilka parametrów dystrybucji – w komentarzach znajdują sie wyjaśnienia poszczególnych ustawień.

/etc/network/internal i /etc/network/external – katalogi zawierające skrypty startujące połączenia sieciowe, odpowiednio lokalne i zewnętrzne (internetowe). Każdy z tych scriptów powinien być zbudowany według ponizszego schematu:


#!/bin/sh

ZMIENNE=wykorzystywane_przez_skrypt

case $1 in
start)
polecenia_startujące_połączenie
if [ $? = 0 ]; then
exit 0
else
exit 1
fi
;;
stop)
polecenia_przerywające_połączenie
if [ $? = 0 ]; then
exit 0
else
exit 1
fi
;;
esac

Podczas startu systemu skrypty te są wywoływane przez skrypt /etc/rc.d/lan i /etc/rc.d/internet z parametrem start lub stop. Katalog /etc/network wraz z podkatalogami i skryptami generowany jest podczas pierwszego uruchomienia net_conf. Jeśli masz łącze, którego nie przewidzieli jeszcze autorzy NND to możesz stworzyć swoje własne skrypty startowe i tu je umieścić. Musisz jednak przestrzegać pewnych reguł:
– skrypty startujące połączenie z internetem MUSZĄ mieć nazwy według klucza – rc.$nazwa_łącza, z tym, że $nazwa_łącza jest zapisana w pliku rc.conf w zmiennej CONNECTION (np. jeśli zmienna ma wartość CONNECTION=dsl plik startowy nazywa się rc.dsl)
– skrypty startujące połączenia lokalne MUSZĄ mieć nazwy takie jak interfejsy sieciowe, które uruchamiają (np eth2, ppp1, ra0). Nazwy te są przypisane do kolejnych zmiennych INTIFx w pliku /etc/rc.conf. Jednocześnie nazwy te MOGĄ się pojawić w zmiennej DHCPIF w pliku /etc/rc.conf jeśli chcesz aby po uruchomieniu serwera dhcpd oczekiwał on na tych interfejsach na zapytania klientów.
Jeśli stworzysz własne skrypty startowe dla łącz lokalnych (np. kart radiowych) lub internetowych bardzo prosimy o podesłanie nam szczegółowego opisu łącza, wymaganych modułów bądź innego potrzebnego oprogramowania i samych scriptów. Pozwoli to nam rozszerzyć funkcjonalność NND.

pacman.conf – plik konfiguracyjny managera pakietów. Tu konfigurujemy adresy repozytoriów pakietów, postępowanie pacmana z różnymi plikami konfiguracyjnymi (backup, nadpisanie, pozostawienie bez zmiany), plik logu, sposób pobierania pakietów z internetu. Jeśli nie chcemy aby pacman uaktualniał nam jakiś pakiet należy w tym pliku, w sekcji [options] dodać linijkę:
IgnorePkg = nazwa_pakietu
Jeśli nie chcemy aby jakikolwiek plik został nadpisany przy upgradzie to w sekcji [options] dodajemy linię:
NoUpgrade = scieżka/nazwa_pliku
Przykładowe wpisy są już w pacman.conf. Zwracam uwagę, na konieczność aktualizowania pacman.conf po konfiguracji każdej usługi.

makepkg.conf – plik konfiguracyjny narzędzia do budowy pakietów. Poszczególne opcje są opisane w komentarzach. Ci, którzy przewidują budowanie własnych pakietów powinni tym pliku usunąć znak komentarza przed linią zaczynającą się od „export PACKAGER”, oraz wstawić w tej linii swoje dane.

/etc/rc.d – katalog zawierający scripty startowe systemu i scripty startowe usług systemowych (daemonów). Wszystkie one korzystają z pliku /etc/rc.d/functions – w którym są zawarte definicje kolorów i sposobu wyświetlania różnych informacji.

/etc/abs katalog z plikami konfiguracyjnymi dla programu abs. Program ten przeznaczony jest dla osób chcących budować pakiety. Łączy się on z serwerem i pobiera z serwera cvs wszystkie pliki niezbędne do budowy pakietów. Program działa tylko „do użytkownika” oraz nie daje bezpośredniego dostępu do serwera cvs.
Niestety w obecnej wersji jeszcze nie jest przystosowany do pracy w środowisku NND.

/etc/pacman.d – katalog w którym przechowywane są pliki z adresami repozytoriów pakietów.

/var/abs – katalog wykorzystywany przez program abs do przechowywania plików potrzebnych do budowy pakietów.

/var/cache/pacman/pkg – katalog w którym przechowywane są kopie zainstalowanych pakietów. Jeśli potrzebujesz miejsca na dysku możesz usunąć stare pakiety z cache poleceniem

pacman -Sc

Jeśli chcesz ten katalog opróżnić całkowicie użyj:

pacman -Scc

UWAGA, czasami stare pakiety się przydają… jeśli możesz sobie na to pozwolić proponuję nie używać dwóch powyższych poleceń. Przynajmniej niezbyt często, ostatniego zaś nigdy.

/var/cache/pacman/src – katalog w którym przechowywane są ściągnięte z internetu źródła programów które „pakietowaliśmy”. Ten katalog można opróżnić poleceniem:

make_nnd_pkg -C

/var/lib/pacman – katalog zawierający bazy pakietów. /var/lib/pacman/local to katalog z informacjami o zainstalowanych pakietach, pozostałe zawierają informacje o repozytoriach.

Oczywiście powyższe informacje nie wyczerpują tematu, jednak mam nadzieję, że choć trochę przybliżą specyfikę NND.

Michał Lechański (Mis’) 13-08-2006 o godz. 19:22:55