[ 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
Część 4 - Rzeczy wymagane w katalogu debian/


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.


4.1 Plik `control'

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ą:

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)


4.2 Plik `copyright'

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.


4.3 Plik `changelog'

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.


4.4 Plik `rules'

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:

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-2007

Josip Rodin joy-mg@debian.org
polskie tłumaczenie: Paweł Tęcza ptecza@debianusers.pl
korekta tłumaczenia: Marcin Owsiany porridge@debian.org
wznowienie tłumaczenia: Wojciech Zaręba wojtekz@comp.waw.pl