[ 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.5 "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 # -*- makefile -*- 3 # Sample debian/rules that uses debhelper. 4 # This file was originally written by Joey Hess and Craig Small. 5 # As a special exception, when this file is copied by dh-make into a 6 # dh-make output file, you may use that output file without restriction. 7 # This special exception was added by Craig Small in version 0.37 of dh-make. 8 # Uncomment this to turn on verbose mode. 9 #export DH_VERBOSE=1 10 configure: configure-stamp 11 configure-stamp: 12 dh_testdir 13 # Add here commands to configure the package. 14 touch configure-stamp 15 build: build-stamp 16 build-stamp: configure-stamp 17 dh_testdir 18 # Add here commands to compile the package. 19 $(MAKE) 20 #docbook-to-man debian/testpack.sgml > testpack.1 21 touch $@ 22 clean: 23 dh_testdir 24 dh_testroot 25 rm -f build-stamp configure-stamp 26 # Add here commands to clean up after the build process. 27 $(MAKE) clean 28 dh_clean 29 install: build 30 dh_testdir 31 dh_testroot 32 dh_clean -k 33 dh_installdirs 34 # Add here commands to install the package into debian/testpack. 35 $(MAKE) DESTDIR=$(CURDIR)/debian/testpack install 36 # Build architecture-independent files here. 37 binary-indep: build install 38 # We have nothing to do by default. 39 # Build architecture-dependent files here. 40 binary-arch: build install 41 dh_testdir 42 dh_testroot 43 dh_installchangelogs 44 dh_installdocs 45 dh_installexamples 46 # dh_install 47 # dh_installmenu 48 # dh_installdebconf 49 # dh_installlogrotate 50 # dh_installemacsen 51 # dh_installpam 52 # dh_installmime 53 # dh_python 54 # dh_installinit 55 # dh_installcron 56 # dh_installinfo 57 dh_installman 58 dh_link 59 dh_strip 60 dh_compress 61 dh_fixperms 62 # dh_perl 63 # dh_makeshlibs 64 dh_installdeb 65 dh_shlibdeps 66 dh_gencontrol 67 dh_md5sums 68 dh_builddeb 69 binary: binary-indep binary-arch 70 .PHONY: build clean binary-indep binary-arch binary install configure
(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 8. 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