[ powrót ] [ Spis treści ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ dalej ]
W katalogu ze źródłami Twojego programu istnieje nowy podkatalog, który nazywa się `debian'. Zawiera on kilka plików, które będziemy edytować, aby dopasować 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
i
dselect
oraz inne narzędzia służące do zarządzania pakietem.
Poniżej przedstawiono plik control stworzony dla nas 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.5.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>
(Numery linii zostały dodane przeze mnie)
Linie 1-6 zawierają informacje kontrolne dla pakietu źródłowego.
Linia nr 1 zawiera nazwę pakietu źródłowego.
Linia nr 2 oznacza sekcję dystrybucji, do której należy pakiet.
Być może zauważyłeś już, ż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 wymaga oprogramowania, które nie jest wolne). Dodatkowo każda z sekcji dzieli się na logiczne podsekcje, które w skrócie mówią, 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 dla programistów, `doc' z dokumentacją, `libs' z bibliotekami, `mail' z programami do wysyłania/odbierania poczty elektronicznej i z demonami pocztowymi, `net' z aplikacjami sieciowymi i demonami usług sieciowych, `x11' z programami dla systemu X11, które nie pasują nigdzie indziej i wiele innych sekcji.
Zmieńmy ją zatem na x11. (Prefiks "main/" jest przyjmowany domyślnie, więc możemy go pominąć)
Linia nr 3 opisuje jak ważne jest to, aby użytkownik zainstalował dany pakiet. Więcej informacji na temat wartości jakie może przyjmować te 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 takie 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, to wartość tych dwóch pól może być nadpisana przez opiekunów archiwum FTP. W takich przypadkach zostaniesz o tym powiadomiony e-mailem.
Ponieważ jest to pakiet o normalnym priorytecie, to pozostawiamy tam wartość "optional".
Linia nr 4 zawiera imię i nazwisko oraz adres e-mail opiekuna pakietu. Upewnij się, że pole te zawiera wartość odpowiednią dla nagłówka "To:", 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. Unikaj stosowania przecinków, ampersandów (`&') i nawiasów.
Linia nr 5 zawiera listę pakietów wymaganych do zbudowania Twojego pakietu.
Niektóre pakiety, na przykład gcc i 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 w tej
linii są oddzielone od siebie za pomocą przecinków; poczytaj 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 w celu stworzenia pakietów przeznaczonych dla różnych platform komputerowych. Więcej informacji na temat zależności w trakcie budowania pakietu znajdziesz w podręczniku Polityki. Dokument Developers' Reference zawiera więcej szczegółów na temat innych platform (architektur) oraz adaptowania (ang. porting) do nich oprogramowania.
Poniżej pokazano sztuczkę, dzięki której odszukasz paczki, 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
Program gentoo wymaga do zbudowania pakietów xlibs-dev
,
libgtk1.2-dev
i libglib1.2-dev
, więc dodajmy je
tutaj, aby wykorzystał je debhelper
.
Linia nr 6 zawiera wersję standardów polityki Debiana, którą dany pakiet spełnia, wersję podręcznika Polityki, który czytasz w trakcie tworzenia Twojego pakietu.
Linia nr 8 to nazwa pakietu binarnego. Zwykle jest ona taka sama jak nazwa pakietu źródłowego, ale to nie jest regułą.
Linia nr 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), to 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 nr 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 stosunków między pakietami. Jeśli tak nie jest, to zostanie
to wkrótce wyjaśnione (więcej informacji znajdziesz na stronach podręcznika
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 spowoduje poważne szkody), jeśli jakiś szczególny pakiet nie jest jeszcze 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że zignorują te pole. Użyj tego pola 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 powinny się o nie troszczyć. Użyj tego pola dla pakietów, które będą dobrze działać 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ś szczególny pakiet jest wciąż 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 odseparowanych 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 >> i odpowiednio oznaczają: 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ś/powinnaś 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 on 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 zostało powiedziane, to możemy pozostawić linie nr 10 w takiej postaci jak teraz i wstawić po niej inną (Suggests: file), która będzie mówiła o pakiecie, które program gentoo sugeruje, ponieważ może on użyć niektórych funkcjonalności dostarczanych przez ten program/pakiet.
Linia nr 11 zawiera krótki opis pakietu. Ekrany większości ludzi mają 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+".
Od linii nr 12 zaczyna się dłuższy opis pakietu. Powinien to być paragraf dostarczający więcej szczegółów na temat pakietu. Kolumna nr 1 każdej linii długiego opisu powinna być pusta. Ponieważ opis ten nie może zawierać pustych linii, to 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. 9 . 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 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ż taki 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 i 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 `control' 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. 13 On Debian systems, the complete text of the GNU General Public 14 License can be found in the file `/usr/share/common-licenses/GPL'.
(Numery linii zostały dodane przeze mnie)
Obecność tego pliku jest wymagana. Jego specjalny 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, poprawce, 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 taki 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
(Numery linii zostały dodane przeze mnie)
Linia nr 1 zawiera nazwę pakietu, jego 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 dziennik, w którym dokumentujesz zmiany dokonane w poprawce
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.
Zakończ ten plik podobnie jak poniżej:
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ć później w sekcji Aktualizacja pakietu, Część 9.
Teraz musimy się przyjrzeć regułom, których użyje program
dpkg-buildpackage(1)
do stworzenia pakietu. Plikiem tym jest
obecnie Makefile, lecz inny niż ten/te znajdujący/znajdujące się w źródłach
programu. W odróżnieniu od innych plików znajdujących się w katalogu debian/
ma on ustawiony atrybut wykonywalności.
Każdy plik `rules', tak samo jak plik Makefile, zawiera różne reguły, które wyszczególniają 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 zostanie stworzony 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 pliki `rules' stworzone przez dh_make są po prostu tylko propozycjami. Działają one z prostymi pakietami, ale w przypadku bardziej skomplikowanych nie obawiaj się ich modyfikować. Dodawaj to, co jest potrzebne i usuwaj to, co jest zbędne. 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 (w przybliżeniu) domyślny plik debian/rules, który został dla nas 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)
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 wspierają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. To jest szablon, wskazówka, którą powinineś/powinnaś wykonać. Musisz również sprawdzić w jaki sposób zewnętrzny system obsługuje włączanie symboli odpluskwiających i 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 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 masz program
dh_strip(1)
, który wykryje, gdy ustawiona jest opcja
DEB_BUILD_OPTIONS=nostrip i bez rozgłosu zakończy swe działanie.
Linie 18-26 opisują regułę `build' (i jej dziecko `build-stamp'), która uruchamia program make na oryginalnym pliku Makefile aplikacji, aby skompilować program. Na temat wykomentowanego przykładu pokazującego w jaki sposób przekonwertować dokument w formacie DocBook na stronę podręcznika systemowego opowiemy dalej, w rozdziale Pliki `manpage.1.ex', `manpage.sgml.ex', Rozdział 5.8.
Reguła `clean' zawarta pomiędzy liniami 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 proszę używać opcji wymuszającej (na przykład dla komeny rm jest nią opcja `-f') lub ignorującej zwracane wartości (błędy) dzięki zastosowaniu opcji `-' przed nazwą komendy.
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 do instalacji w pliku Makefile programu gentoo.
Jak tłumaczy komentarz, reguła `binary-indep', która znajduje się w linii nr 48, jest używana do budowania pakietów niezależnych od architektury procesora. Jeśli nie mamy takiego pakietu, to żadna akcja nie zostanie wykonana.
Następną regułą jest `binary-arch' znajdująca się pomiędzy liniami 52-79. Uruchamia ona kilka małych programów narzędziowych z pakietu debhelper, które wykonują różne operacje z plikami Twojego pakietu, aby uczynić go zgodnym z Polityką Debiana.
Gdy określiłeś architekturę Twojego pakietu jako `Architecture: all', to będziesz musiał umieścić w tej regule wszystkie komendy do budowania pakietu i pozostawić pustą następną 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ą, to poniżej zamieszczono dodatkowe wytłumaczenia:
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 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 "ulepszoną" wersję pliku
`control' w katalogu debian/gentoo/DEBIAN
,
dh_md5sums(1)
generuje sumy kontrolne MD5 dla każdego pliku
zawartego w pakiecie.
Dokładne informacje na temat działania każdego skryptu dh_* i ich parametrów wywołania znajdziesz na odpowiedniej stronie podręcznika. Oprócz wymienionych powyżej, istnieją również inne użyteczne skrypty dh_*, które nie zostały tu wspomniane. Jeśli potrzebujesz ich, to poczytaj dokumentację do pakietu debhelper.
W sekcji `binary-arch' powinieneś naprawdę wykomentować linie z tymi wszystkimi 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 potrzebuje. W linii nr 68 zamieniłem `ChangeLog' na `FIXES', ponieważ jest to rzeczywista nazwa zewnętrznego pliku z dziennikiem zmian.
Dwie ostatnie linie (i pozostałe nie wyjaśnione 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 nie musisz o nich nic wiedzieć.
[ powrót ] [ Spis treści ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ dalej ]
Podręcznik dla nowych opiekunów pakietów Debiana
wersja oryginału: 1.2, 6 kwietnia 2002. wersja tłumaczenia: 1.2.2, 17 marca 2004joy-mg@debian.org
ptecza@debianusers.pl
porridge@debian.org