[ powrót ] [ Spis treści ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ A ] [ dalej ]
W katalogu ze źródłami Twojego programu powstał nowy podkatalog, który nazywa się `debian'. Zawiera on kilka plików, które powinniśmy wyedytować, aby umożliwić działanie pakietu. Najważniejszymi z nich są pliki `control', `changelog', `copyright' i 'rules', które są wymagane w każdym pakiecie.
Ten plik zawiera różne informacje, których używaja programy dpkg
,
dselect
oraz inne narzędzia służące do zarządzania pakietem.
Poniżej przedstawiono plik control utworzony przez program dh_make:
1 Source: gentoo 2 Section: unknown 3 Priority: optional 4 Maintainer: Josip Rodin <joy-mg@debian.org> 5 Build-Depends: debhelper (>> 3.0.0) 6 Standards-Version: 3.6.2 7 8 Package: gentoo 9 Architecture: any 10 Depends: ${shlibs:Depends} 11 Description: <insert up to 60 chars description> 12 <insert long description, indented with spaces>
(dodałem numery linii)
Linie 1-6 zawierają informacje kontrolne dla pakietu źródłowego.
Linia 1. zawiera nazwę pakietu źródłowego.
Linia 2. oznacza sekcję dystrybucji, do której należy pakiet źródłowy.
Być może zauważyłeś, że Debian jest podzielony na następujące sekcje: `main' (zawiera wolne oprogramowanie), `non-free' (zawiera oprogramowanie, które nie jest wolne) i `contrib' (zawiera wolne oprogramowanie, które zależy od oprogramowania, które nie jest wolne). Dodatkowo każda z sekcji dzieli się na logiczne podsekcje, które skrótowo opisują, do czego służy dany pakiet. Mamy zatem sekcję `admin', która zawiera programy przeznaczone tylko dla administratora systemu, `base' z podstawowymi narzędziami, `devel' z narzędziami programistów, `doc' z dokumentacją, `libs' z bibliotekami, `mail' z programami do obsługi poczty elektronicznej, `net' z aplikacjami sieciowymi i demonami usług sieciowych, `x11' z programami dla systemów X11, które nie pasują nigdzie indziej i wiele innych.
Zmieńmy ją zatem na x11. Prefiks "main/" jest przyjmowany domyślnie, więc możemy go pominąć.
Linia 3. opisuje, jak ważne jest to, aby użytkownik zainstalował dany pakiet. Więcej informacji na temat wartości, jakie może przyjmować to pole znajdziesz w podręczniku Polityki Debiana. Dla nowych pakietów zazwyczaj może ono przyjmować wartość "optional".
Sekcja (Section) i priorytet (Priority) są używane przez nakładki, jak program
dselect
, które używają ich do sortowania pakietów i wyboru
domyślnego zestawu pakietów do zainstalowania. Gdy będziesz umieszczał swój
pakiet w archiwum Debiana, wartość tych dwóch pól może być zmieniona przez
opiekunów archiwum. W takich przypadkach zostaniesz o tym powiadomiony
e-mailem.
Ponieważ jest to pakiet o normalnym priorytecie i nie jest w konflikcie z innym pakietem, to pozostawiamy tam wartość "optional".
Linia 4. zawiera imię i nazwisko oraz adres e-mail opiekuna pakietu. Upewnij się, że pole to zawiera wartość odpowiednią dla nagłówka "To: " wiadomości pocztowej, gdyż po umieszczeniu pakietu w archiwum system śledzenia błędów użyje tego pola do wysyłania Ci e-maili ze zgłoszeniami błędów. Nie stosuj przecinków, ampersandów (`&') i nawiasów.
Linia 5. zawiera listę pakietów wymaganych do zbudowania Twojego pakietu.
Niektóre pakiety, na przykład gcc czy make, są założone z góry, więcej
szczegółów na temat znajdziesz w pakiecie build-essential
. Jeśli
do zbudowania Twojego pakietu jest potrzebny jakiś niestandardowy kompilator
lub inne narzędzie, to powinieneś dodać tutaj linię `Build-Depends'. Wpisy są
oddzielane od siebie za pomocą przecinków; przeczytaj objaśnienia na temat
zależności binariów, aby dowiedzieć się więcej na temat składni tego pola.
Możesz także użyć w tym miejscu takich pól jak Build-Depends-Indep, Build-Conflicts i innych. Dane te są używane przez oprogramowanie do automatycznego budowania pakietów Debiana w celu stworzenia pakietów binarnych przeznaczonych dla innych platform komputerowych. Więcej informacji na temat zależności budowania pakietów znajdziesz w podręczniku Polityki. Dokument Developers' Reference zawiera szczegóły na temat innych platform (architektur) oraz adaptowania (ang. porting) do nich oprogramowania.
Poniżej pokazano sztuczkę, dzięki której odszukasz pakiety, których potrzebuje do zbudowania Twój pakiet:
strace -f -o /tmp/log ./configure # or make instead of ./configure, if the package doesn't use autoconf for x in `dpkg -S $(grep open /tmp/log|\ perl -pe 's!.* open\(\"([^\"]*).*!$1!' |\ grep "^/"| sort | uniq|\ grep -v "^\(/tmp\|/dev\|/proc\)" ) 2>/dev/null|\ cut -f1 -d":"| sort | uniq`; \ do \ echo -n "$x (>=" `dpkg -s $x|grep ^Version|cut -f2 -d":"` "), "; \ done
Aby ręcznie znaleźć kompletny zestaw zależności dla programu
/usr/bin/foo
, wykonaj
objdump -p /usr/bin/foo | grep NEEDED
a dla każdej znalezionej biblioteki, np. libfoo.so.6
, wykonaj
dpkg -S libfoo.so.6
Potem tylko weź wersję -dev każdej z nich jako pozycję w `Build-deps'. Jeśli
używasz do tego celu ldd
, pokazuje on również zależności
niebezpośrednie, co skutkuje zbyt dużą liczbą wykazywanych zależności.
Tak więc program gentoo wymaga do zbudowania pakietów xlibs-dev
,
libgtk1.2-dev
i libglib1.2-dev
, więc dodajmy je za
pakietem debhelper
.
Linia 6. jest wersją standardów polityki Debiana, którą dany pakiet spełnia, wersję podręcznika Polityki, który czytasz w trakcie tworzenia Twojego pakietu.
Linia 8. to nazwa pakietu binarnego. Zwykle jest ona taka sama jak nazwa pakietu źródłowego, ale nie musi to być regułą.
Linia 9. opisuje architekturę procesora, dla którego może być skompilowany
pakiet. Pozostawimy w niej "any", gdyż pakiet
dpkg-gencontrol(1)
sam wstawi w tym miejscu odpowiednią wartość
dla każdego typu maszyny, na której kompilowany jest pakiet.
Jeśli Twój pakiet jest niezależny od architektury procesora (dla przykładu skrypt powłoki lub Perla, albo jakiś dokument), wpisz tutaj "all" i poczytaj później w sekcji Plik `rules', Rozdział 4.4 na temat używania reguły `binary-indep' zamiast `binary-arch' do budowania pakietu.
Linia 10. pokazuje jedną z najpotężniejszych cech systemu pakietów Debiana. Pakiety mogą znajdować się w różnych relacjach z innymi pakietami. Oprócz pola Depends: mogą też występować pola opisujące inne związki: Recommends:, Suggests:, Pre-Depends:, Conflicts:, Provides: i Replaces:.
Narzędzia do zarządzania pakietami zwykle zachowują się w ten sam sposób w
czasie ustalania relacji między pakietami. Jeśli tak nie jest, zostanie to
wkrótce wyjaśnione (zobacz dpkg(8)
, dselect(8)
,
apt(8)
, aptitude(1)
, itd.).
Pola te oznaczają:
Depends: (Wymaga)
Pakiet nie zostanie zainstalowany o ile pakiety, których on wymaga nie są już zainstalowane w systemie. Użyj tego pola, gdy Twój program absolutnie nie może być uruchomiony (lub z dużymi trudnościami), jeśli któryś z tych pakietów nie jest obecny w systemie.
Recommends: (Zaleca)
Nakładki takie jak dselect czy aptitude zachęcą Cię do zainstalowania zalecanych pakietów wraz z Twoim pakietem; dselect będzie nawet na to nalegać. Programy dpkg i apt-get jednak zignorują te pole. Użyj go dla pakietów, które nie są niezbędne, ale są zwykle używane razem z Twoim programem.
Suggests: (Poleca)
Gdy użytkownik instaluje Twój program, wszystkie nakładki zachęcą go także do zainstalowania pakietów, które on poleca. Programy dpkg i apt-get nie będą się o to troszczyć. Użyj tego pola dla pakietów, które lepiej działają z Twoim programem, ale nie są dla niego niezbędne.
Pre-Depends: (Przed-Wymaga)
Jest to silniejsza relacja niż Depends:. Pakiet nie zostanie zainstalowany o ile pakiety, od których jest on przed-zależny nie są zainstalowane w systemie i poprawnie skonfigurowane. Używaj tego pola bardzo oszczędnie i jedynie po przedyskutowaniu tego na liście debian-devel. Czytaj: nie używaj go nigdy. :-)
Conflicts: (PowodujeKonflikt)
Pakiet nie zostanie zainstalowany, dopóki wszystkie pakiety, które powodują konflikt nie zostaną wcześniej usunięte z systemu. Użyj tego pola, gdy Twój program absolutnie nie może być uruchomiony lub spowoduje jakieś problemy, jeśli jakiś inny pakiet jest obecny w systemie.
Provides: (Dostarcza)
Dla niektórych rodzajów pakietów zostało zdefiniowanych wiele alternatywnych nazw wirtualnych. Pełną listę tych pakietów znajdziesz w pliku /usr/share/doc/debian-policy/virtual-package-names-list.txt.gz. Użyj tego pola, jeśli Twój program dostarcza funkcjonalności istniejącego już pakietu wirtualnego.
Replaces: (Zastępuje)
Użyj tego pola, gdy Twój program zastępuje pliki jakiegoś innego pakietu lub zupełnie zastępuje jakiś pakiet (używane łącznie z polem Conflicts:). Pliki z wymienionych pakietów zostaną nadpisane przez pliki z Twojego pakietu.
Wszystkie te pola mają jednolitą składnię. Jest to lista nazw pakietów oddzielonych za pomocą przecinka. Nazwy pakietów mogą również być listami alternatywnych nazw pakietów oddzielonych przy pomocy symbolu | (symbol potoku).
Pola mogą ograniczać swoje zastosowanie tylko do szczególnych wersji każdego wymienionego pakietu. Wersje te są umieszczone w nawiasach po każdej nazwie pakietu i powinny zawierać relacje między numerami wersji pakietów. Dozwolonymi relacjami są: <<, <=, =, >= i >>, odpowiednio: wcześniejszy, wcześniejszy lub równy, dokładnie równy, późniejszy lub równy i późniejszy. Dla przykładu:
Depends: foo (>= 1.2), libbar1 (= 1.3.4) Conflicts: baz Recommends: libbaz4 (>> 4.0.7) Suggests: quux Replaces: quux (<< 5), quux-foo (<= 7.6)
Ostatnią cechą, o której powinieneś wiedzieć, jest ${shlibs:Depends}. Gdy Twój
pakiet zostanie zbudowany i zainstalowany w tymczasowym katalogu, program
dh_shlibdeps(1)
"prześwietli" go w poszukiwaniu binariów
i bibliotek, określi jakich bibliotek współdzielonych wymaga i wykryje, w
których pakietach się one znajdują, na przykład libc6 lub xlib6g. Następnie
program dh_gencontrol(1)
umieści ich nazwy we właściwym miejscu,
więc nie musisz się o to martwić.
Skoro już wszystko to zostało powiedziane, możemy pozostawić linię 10. w takiej postaci jak teraz i wstawić po niej Suggests: file, ponieważ gentoo może użyć niektórych funkcjonalności dostarczanych przez ten program/pakiet.
Linia 11. jest krótkim opisem pakietu. Większość ekranów tekstowych ma szerokość 80 kolumn, więc nie powinna ona zawierać więcej niż 60 znaków. Ja wpisałem w niej "fully GUI configurable X file manager using GTK+" (w pełni konfigurowalny okienkowy manager plików używający GTK+).
Od linii 12. zaczyna się dłuższy opis pakietu. Powinien to być akapit z większą liczbą szczegółów na temat pakietu. Pierwsza kolumna każdej linii długiego opisu powinna być pusta. Ponieważ opis ten nie może zawierać pustych linii, wszędzie tam gdzie chciałbyś je wstawić, musisz umieścić znak . (kropka) w kolumnie nr 2. Także na końcu długiego opisu nie może się pojawić więcej niż jedna pusta linia.
A oto końcowa postać uaktualnionego pliku `control':
1 Source: gentoo 2 Section: x11 3 Priority: optional 4 Maintainer: Josip Rodin <joy-mg@debian.org> 5 Build-Depends: debhelper (>> 3.0.0), xlibs-dev, libgtk1.2-dev, libglib1.2-dev 6 Standards-Version: 3.5.2 7 8 Package: gentoo 9 Architecture: any 10 Depends: ${shlibs:Depends} 11 Suggests: file 12 Description: fully GUI configurable X file manager using GTK+ 13 gentoo is a file manager for Linux written from scratch in pure C. It 14 uses the GTK+ toolkit for all of its interface needs. gentoo provides 15 100% GUI configurability; no need to edit config files by hand and re- 16 start the program. gentoo supports identifying the type of various 17 files (using extension, regular expressions, or the 'file' command), 18 and can display files of different types with different colors and icons. 19 . 20 gentoo borrows some of its look and feel from the classic Amiga file 21 manager "Directory OPUS" (written by Jonathan Potter).
(numery linii zostały dodane przeze mnie)
Plik ten zawiera informacje o zewnętrznych (ang. upstream) zasobach pakietu, prawach autorskich i licencji. Jego format nie jest narzucony przez Politykę Debiana, ale jego zawartość już tak (zobacz sekcję 12.6 "Informacje o prawach autorskich").
Program dh_make stworzył już domyślny plik, którego zawartość jest podobna do tej poniżej:
1 This package was debianized by Josip Rodin <joy-mg@debian.org> on 2 Wed, 11 Nov 1998 21:02:14 +0100. 3 4 It was downloaded from <fill in ftp site> 5 6 Upstream Author(s): <put author(s) name and email here> 7 8 Copyright: 9 10 <Must follow here>
(numery linii zostały dodane przeze mnie)
Ważnymi rzeczami, które powinieneś dodać do tego pliku, jest miejsce, z którego pobrałeś pakiet ze źródłami oraz informacje o prawach autorskich i licencji. Musisz dołączyć kompletną treść licencji, chyba że jest to jedna z popularnych licencji wolnego oprogramowania, takich jak GNU GPL czy LGPL, BSD lub licencja Artystyczna. W takiej sytuacji możesz po prostu odesłać do odpowiedniego pliku w katalogu /usr/share/common-licenses/, który występuje w każdym systemie Debian.
Poniżej pokazano w skrócie, jak powinien wyglądać plik `copyright' dla programu gentoo:
1 This package was debianized by Josip Rodin <joy-mg@debian.org> on 2 Wed, 11 Nov 1998 21:02:14 +0100. 3 4 It was downloaded from: ftp://ftp.obsession.se/gentoo/ 5 6 Upstream author: Emil Brink <emil@obsession.se> 7 8 This software is copyright (c) 1998-99 by Emil Brink, Obsession 9 Development. 10 11 You are free to distribute this software under the terms of 12 the GNU General Public License either version 2 of the License, 13 or (at your option) any later version. 14 On Debian systems, the complete text of the GNU General Public 15 License can be found in the file `/usr/share/common-licenses/GPL-2'.
(numery linii zostały dodane przeze mnie)
Prosimy postępować zgodnie z plikiem HOWTO z listy debian-devel-announce:
http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html
.
Jest plikiem wymaganym, którego format opisano w Polityce Debiana (sekcja 4.4 "debian/changelog"). Format ten jest wykorzystywany przez dpkg i inne programy do uzyskiwania informacji o numerze wersji, numerze rewizji (poprawki), dystrybucji i pilności Twojego pakietu.
Jest on także ważny dla Ciebie, ponieważ dobrze jest mieć udokumentowane wszystkie zmiany, których dokonałeś. Pomaga to ludziom pobierającym Twój pakiet zorientować się, czy nie zrobiłeś z pakietem czegoś, o czym powinni oni wiedzieć. Zmiany te zostaną zapisane do pliku `/usr/share/doc/gentoo/changelog.Debian.gz' w pakiecie binarnym.
Program dh_make również tworzy ten plik, którego zawartość wygląda mniej więcej tak:
1 gentoo (0.9.12-1) unstable; urgency=low 2 3 * Initial Release. 4 5 -- Josip Rodin <joy-mg@debian.org> Wed, 11 Nov 1998 21:02:14 +0100 6
(numery linii zostały dodane przeze mnie)
Linia 1. zawiera nazwę pakietu, wersję, dystrybucję i pilność. Nazwa musi się zgadzać z nazwą pakietu źródłowego, dystrybucja powinna mieć wartość albo `unstable' (albo nawet `experimental'), zaś pilności nie powinieneś zmieniać na wartość większą niż `low' (niska). :-)
Linie 3-5 to wpisy dziennika, w którym dokumentujesz zmiany dokonane w każdej z
poprawek pakietu (ale nie zmiany zewnętrzne - do tego celu służy specjalny plik
stworzony przez autorów programu, który później zainstalujesz jako
/usr/share/doc/gentoo/changelog.gz). Nowe linie muszą być umieszczone przed
znajdującą się na górze linią, która rozpoczyna się od gwiazdki (`*'). Możesz
to zrobić przy pomocy dch(1)
lub używając jakiegoś edytora tekstu.
Poprawiony będzie wyglądał jakoś tak:
1 gentoo (0.9.12-1) unstable; urgency=low 2 3 * Initial Release. 4 * This is my first Debian package. 5 * Adjusted the Makefile to fix $DESTDIR problems. 6 7 -- Josip Rodin <joy-mg@debian.org> Wed, 11 Nov 1998 21:02:14 +0100 8
(numery linii zostały dodane przeze mnie)
Więcej na temat pliku `changelog' bedziesz mógł przeczytać dalej w rozdziale Aktualizacja pakietu, Część 9.
Teraz musimy się przyjrzeć regułom (ang. rules), których użyje program
dpkg-buildpackage(1)
do zbudowania naszego pakietu. Plik ten jest
właściwie odmianą pliku Makefile, lecz różni się od tego/tych z programu
źródłowego. Inaczej niż pozostałe pliki znajdujące się w katalogu debian/, ma
on ustawiony atrybut wykonywalności.
Każdy plik `rules', tak samo jak inne pliki Makefile, zawiera różne reguły, które określają, jak postępować ze źródłem. Każda reguła z kolei zawiera cele (targets), czyli nazwy plików bądź akcji, które powinny być stworzone lub wykonane (na przykład `build:' lub `install:'). Reguły, które chcesz wykonać są wywoływane z linii komend jako argumenty poleceń (dla przykładu `./debian/rules build` albo `make -f rules install`). Po nazwie celu możesz wymienić zależność, program lub plik, który od tej reguły zależy. W kolejnych liniach można wymienić dowolną liczbę komend, rozpoczynając je od znaku <tab>. Nowa reguła zaczyna się od deklaracji w pierwszej kolumnie. Puste linie i linie rozpoczynające się od znaku `#' (hash) są traktowane jako komentarz i ignorowane.
Pewnie jesteś teraz nieco zagubiony, ale wszystko stanie się jasne w czasie przeglądania pliku `rules', który domyślnie jest tworzony przez program dh_make. Powinieneś też przeczytać o programie `make' (poprzez `info make'), aby uzyskać więcej informacji na jego temat.
Ważne jest, aby pamiętać, że plik `rules' tworzony przez dh_make jest tylko propozycją. Działa on z prostymi pakietami, ale w przypadku bardziej skomplikowanych nie obawiaj się go modyfikować, zależnie od potrzeb. Jedyną rzeczą, której nie możesz zmieniać to nazwy reguł, gdyż używają ich wszystkie narzędzia, zgodnie z wytycznymi zawartymi w Polityce Debiana.
Poniżej pokazano przykładowy domyślny plik debian/rules, który został wygenerowany przez program dh_make:
1 #!/usr/bin/make -f 2 # Sample debian/rules that uses debhelper. 3 # GNU copyright 1997 to 1999 by Joey Hess. 4 5 # Uncomment this to turn on verbose mode. 6 #export DH_VERBOSE=1 7 8 # This is the debhelper compatibility version to use. 9 export DH_COMPAT=4 10 11 CFLAGS = -g 12 ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS))) 13 CFLAGS += -O0 14 else 15 CFLAGS += -O2 16 endif 17 18 build: build-stamp 19 build-stamp: 20 dh_testdir 21 22 # Add here commands to compile the package. 23 $(MAKE) 24 #docbook-to-man debian/gentoo.sgml > gentoo.1 25 26 touch build-stamp 27 28 clean: 29 dh_testdir 30 dh_testroot 31 rm -f build-stamp 32 33 # Add here commands to clean up after the build process. 34 -$(MAKE) clean 35 36 dh_clean 37 38 install: build 39 dh_testdir 40 dh_testroot 41 dh_clean -k 42 dh_installdirs 43 44 # Add here commands to install the package into debian/gentoo. 45 $(MAKE) install DESTDIR=$(CURDIR)/debian/gentoo 46 47 # Build architecture-independent files here. 48 binary-indep: build install 49 # We have nothing to do by default. 50 51 # Build architecture-dependent files here. 52 binary-arch: build install 53 dh_testdir 54 dh_testroot 55 # dh_installdebconf 56 dh_installdocs 57 dh_installexamples 58 dh_installmenu 59 # dh_installlogrotate 60 # dh_installemacsen 61 # dh_installpam 62 # dh_installmime 63 # dh_installinit 64 dh_installcron 65 dh_installman 66 dh_installinfo 67 # dh_undocumented 68 dh_installchangelogs ChangeLog 69 dh_link 70 dh_strip 71 dh_compress 72 dh_fixperms 73 # dh_makeshlibs 74 dh_installdeb 75 # dh_perl 76 dh_shlibdeps 77 dh_gencontrol 78 dh_md5sums 79 dh_builddeb 80 81 binary: binary-indep binary-arch 82 .PHONY: build clean binary-indep binary-arch binary install
(numery linii zostały dodane przeze mnie; w rzeczywistym pliku
debian/rules
wiodące białe znaki są tabulatorami)
Z liniami takimi jak linia nr 1 prawdopodobnie spotkałeś się już w skryptach powłoki albo Perla. Mówi ona systemowi operacyjnemu, że plik ten ma być przetwarzany przez program `/usr/bin/make'.
Znaczenie zmiennych DH_*, których użyto w liniach 6. i 9. powinno być
zrozumiałe dzięki krótkiemu opisowi. Więcej informacji na temat zmiennej
DH_COMPAT znajdziesz w sekcji "Debhelper compatibility levels" na
stronie podręcznika programu debhelper(1)
.
Linie 11-16 to szablon obsługujący parametry DEB_BUILD_OPTIONS, które opisano w Polityce Debiana (sekcja 10.1 "Binaries"). Po prostu mówią one, czy w binaria mają być wbudowane symbole służące do odpluskwiania (ang. debugging) i czy powinny one być usunięte przy instalacji. I znów: to jest tylko szablon, wskazówka, którą powinineś uwzględnić. Powinieneś sprawdzić, w jaki sposób autor programu obsługuje włączanie symboli odpluskwiających oraz usuwanie ich po instalacji i zaimplementować to samemu.
Zwykle możesz nakazać kompilatorowi gcc użycie opcji "-g" przy pomocy zmiennej CFLAGS. Jeśli tak jest w przypadku Twojego pakietu, przekaż wartość tej zmiennej przez dodanie łańcucha CFLAGS="$(CFLAGS)" do wywołania $(MAKE) w regule `build' (zobacz poniżej). Jeśli zaś Twój pakiet używa skryptu konfiguracyjnego autoconfa, to możesz zmodyfikować konfigurację przez poprzedzenie powyższym łańcuchem wywołania skryptu ./configure w regule `build'.
Jeśli chodzi o pozbywanie się symboli odpluskwiających, to programy są na ogół
tak skonfigurowane, że instalują się z nimi i często nie mają opcji
umożliwiającej zmianę tego stanu. Na szczęście mamy program
dh_strip(1)
, który wykryje, gdy ustawiona jest opcja
DEB_BUILD_OPTIONS=nostrip i zakończy swe działanie.
Linie 18-26 opisują regułę `build' (i jej regułę potomną `build-stamp'), która
uruchamia program make na oryginalnym pliku Makefile aplikacji, aby skompilować
program. Jeśli pakiet używa narzędzi konfigurujących GNU do zbudowania
binariów, koniecznie przeczytaj
/usr/share/doc/autotools-dev/README.Debian.gz
. O zakomentowanym
przykładzie docbook-to-man opowiemy dalej w rozdziale Pliki `manpage.1.ex', `manpage.sgml.ex',
Rozdział 5.8.
Reguła `clean' zawarta w liniach 28-36 czyści wszystkie niepotrzebne pliki binarne i automatycznie wygenerowane rzeczy, które zostały po zbudowaniu pakietu. Reguła ta musi działać przez cały czas (nawet, gdy drzewo ze źródłami jest wyczyszczone!), zatem prosimy używać opcji wymuszającej (na przykład dla polecenia rm jest nią opcja `-f') lub ignorującej zwracane wartości (błędy) poprzez zastosowanie `-' przed poleceniem.
Reguła `install', która odpowiada za proces instalacji, rozpoczyna się w linii nr 38. Uruchamia ona po prostu regułę `install' z pliku Makefile programu i instaluje go w katalogu $(CURDIR)/debian/gentoo - oto dlaczego określiliśmy zmienną $(DESTDIR) jako katalog bazowy instalacji w pliku Makefile programu gentoo.
Jak tłumaczy komentarz, reguła `binary-indep', która znajduje się w linii 48., jest używana do budowania pakietów niezależnych od architektury procesora. Jeśli nie mamy takiego pakietu, żadna akcja nie zostanie przedsięwzięta.
Następną regułą jest `binary-arch' znajdująca się w liniach 52-79. Uruchamia ona kilka małych programów narzędziowych z pakietu debhelper, które wykonują różne operacje z plikami pakietu, aby uczynić go zgodnym z Polityką Debiana.
Gdy określiłeś architekturę Twojego pakietu jako `Architecture: all', będziesz musiał umieścić w tej regule wszystkie komendy do budowania pakietu i pozostawić pustą regułę `binary-arch'.
Nazwy programów wchodzących w skład pakietu debhelper rozpoczynają się od dh_. Reszta jest opisem tego, co dane narzędzie robi. Mimo, że dość dobrze same się one objaśniają, poniżej zamieszczono dodatkowe opisy:
dh_testdir(1)
sprawdza, czy jesteś we właściwym katalogu (tzn. na
samej górze katalogu ze źródłami)
dh_testroot(1)
sprawdza, czy masz uprawnienia administratora
systemu, których wymagają cele `binary-arch', `binary-indep' i `clean'
dh_installman(1)
kopiuje strony podręcznika systemowego we
właściwe miejsce w katalogu przeznaczenia. Musisz tylko powiedzieć, gdzie one
się znajdują, względem głównego katalagu ze źródłami
dh_strip(1)
usuwa z plików wykonywalnych i bibliotek nagłówki
służące do odpluskwiania, aby uczynić je mniejszymi
dh_compress(1)
pakuje programem gzip(1)
strony
podręcznika i dokumentację większą niż 4 kB
dh_installdeb(1)
kopiuje pliki związane z pakietem (na przykład
skrypty opiekuna) do katalogu debian/gentoo/DEBIAN
dh_shlibdeps(1)
wylicza zależności bibliotek i plików
wykonywalnych od bibliotek współdzielonych
dh_gencontrol(1)
instaluje finalną wersję pliku `control' w
katalogu debian/gentoo/DEBIAN
dh_md5sums(1)
generuje sumy kontrolne MD5 dla każdego pliku
zawartego w pakiecie
Pełniejsze informacje na temat działania każdego ze skryptów dh_* i ich parametrów wywołania znajdziesz na odpowiednich stronach podręcznika. Oprócz powyższych istnieją również inne użyteczne skrypty dh_*, które nie zostały tu wspomniane. Jeśli są potrzebne, czytaj dokumentację do pakietu debhelper.
W sekcji `binary-arch' powinieneś wykomentować lub usunąć linie z tymi skryptami dh_*, których nie chcesz wywoływać. Dla pakietu gentoo wykomentowałem wywołanie skryptów examples, cron, init, man i info, gdyż gentoo ich po prostu nie używa. W linii 68. zamieniłem `ChangeLog' na `FIXES', ponieważ jest to rzeczywista nazwa autorskiego pliku z dziennikiem zmian.
Dwie ostatnie linie (i pozostałe nie opisane tutaj) są mniej lub bardziej niezbędne. Na ich temat możesz poczytać na stronie podręcznika do programu make oraz w Polityce Debiana. W tym momencie są na tyle mało ważne, że nie będziemy ich opisywać.
[ powrót ] [ Spis treści ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ A ] [ dalej ]
Podręcznik dla nowych opiekunów pakietów Debiana
wersja oryginału: 1.2.11, 12-01-2007, wersja tłumaczenia: 1.2.5, 27-09-2007joy-mg@debian.org
ptecza@debianusers.pl
porridge@debian.org
wojtekz@comp.waw.pl