trunk/maint-guide/maint-guide.pl.sgml

<!DOCTYPE debiandoc PUBLIC "-//DebianDoc//DTD DebianDoc//EN" [

        <!-- textual data entities -->
        <!-- first definition wins in SGML -->
<!ENTITY % default  SYSTEM "default.ent">  %default;

]>
<!-- CVS revision of this document "$Revision: 1.22 $"  -->
<!-- CVS revision of original english document "1.115"  -->

<debiandoc>

 <book>

  <titlepag>

   <title>Podręcznik dla nowych opiekunów pakietów Debiana</title>

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

   <version>wersja oryginału: 1.2.11, 12-01-2007, wersja tłumaczenia: 1.2.5,
   27-09-2007</version>

   <copyright>
   <copyrightsummary>Copyright &copy; 1998-2002 Josip Rodin.</copyrightsummary>
   <copyrightsummary>Copyright &copy; 2005-2007 Osamu Aoki.</copyrightsummary>
   <copyrightsummary>Copyright &copy; polskiego tłumaczenia 2002-2004
   Paweł Tęcza, Marcin Owsiany.</copyrightsummary>
   <copyrightsummary>Copyright &copy; polskiego tłumaczenia 2007
   Wojciech Zaręba.</copyrightsummary>

   <p>Ten dokument może być używany zgodnie z zasadami licencji GNU GPL (General
   Public License) w wersji 2 lub wyższej.

   <p>Do stworzenia tego dokumentu wykorzystano, jako przykłady, następujące
   dokumenty:

   <p>Making a Debian Package (znany jako Debmake Manual), copyright &copy; 1997
   Jaldhar Vyas.

   <p>The New-Maintainer's Debian Packaging Howto, copyright &copy; 1997
   Will Lowe.
   </copyright>

  </titlepag>

  <toc sect>

  <!-- -------------------------------------------------------------------------->

  <chapt id="start">Rozpoczęcie, jak się należy

  <p>Ten dokument próbuje opisać proces budowania pakietów systemu Debian.
  Jest on przeznaczony dla zwykłych użytkowników Debiana i tych, którzy chcą
  zostać deweloperami. Używa zwykłego języka i daje dużo działających przykładów.
  Stare rzymskie przysłowie mówi <em>Longum iter est per preaecepta,
  breve et efficax per exempla</em> (Długa jest droga przez nakazy,
  krótka i skuteczna przez przykłady).
  
  <p>Jedną z rzeczy sprawiających, że Debian jest wyjątkową dystrybucją Linuksa,
  jest jego system pakietów. Mimo że istnieje ogromna ilość oprogramowania już
  spakowanego do formatu Debiana, to czasami zachodzi konieczność
  zainstalowania programu, który nie posiada swojej paczki. Pewnie się dziwisz,
  że możesz sam zbudować własne pakiety i myślisz, że to bardzo trudne zadanie.
  No cóż, jeśli jesteś zupełnym nowicjuszem w Linuksie, to rzeczywiście będziesz
  miał kłopoty, ale czy gdybyś był żółtodziobem, to czytałbyś teraz ten
  dokument? :-) Musisz trochę wiedzieć na temat programowania pod Unix'em,
  ale nie musisz od razu być ekspertem.

  <p>Jedna rzecz jest pewna: aby odpowiednio tworzyć i zarządzać pakietami
  Debiana konieczne są osobogodziny. Staraj się nie popełniać błędów,
  gdyż nasz system, aby działać, wymaga od opiekunów zarówno kompetencji
  technicznych jak i rzetelności.
  
  <p>Ten dokument wyjaśni wszystkie kroki potrzebne do zbudowania pakietu
  (choć niektóre z nich mogą na początku wydać się nieistotne) i pomoże Ci
  stworzyć Twój pierwszy pakiet. Dzięki niemu nabierzesz trochę doświadczenia,
  które przyda Ci się w trakcie budowania następnych wydań pakietu, a później może
  również do tworzenia innych paczek.

  <p>Najnowsza wersja tego dokumentu powinna być zawsze dostępna bezpośrednio
  na stronie <url name="http://www.debian.org/doc/maint-guide/"
  id="http://www.debian.org/doc/maint-guide"> oraz w pakiecie
  `<package>maint-guide</package>'. Polskie tłumaczenie jest również dostępne
  w pakiecie `<package>maint-guide-pl</package>'.

  <sect id="needprogs">Programy, których potrzebujesz do dewelopmentu

  <p>Zanim zaczniesz cokolwiek robić, powinieneś upewnić się, że masz
  zainstalowanych kilka dodatkowych pakietów niezbędnych do dewelopmentu.
  Zwróć uwagę, że na poniższej liście nie ma żadnych pakietów oznaczonych
  jako `niezbędne' (essential) lub `wymagane' (required). Po prostu
  zakładamy, że masz już je zainstalowane.
  
  <p>Ta wersja podręcznika została uaktualniona z myślą o pakietach
  wchodzących w skład Debiana 2.2 (`potato') oraz 3.0 (`woody').
  
  <p>Następujące pakiety wchodzą w skład standardowej instalacji Debiana,
  więc prawdopodobnie masz je (i dodatkowe pakiety, od których one zależą)
  już zainstalowane. Mimo to powinieneś sprawdzić ich status za pomocą
  polecenia `dpkg -s &lt;pakiet&gt;`.

  <list>
  
  <item><package>dpkg-dev</package> - pakiet zawierający narzędzia niezbędne do
  rozpakowywania, budowania i wysyłania pakietów źródłowych Debiana
  (więcej informacji znajdziesz na stronie podręcznika <manref name="dpkg-source"
  section="1">).

  <item><package>file</package> - przydatny program do określania typu pliku
  (zobacz <manref name="file" section="1">).
          
  <item><package>gcc</package> - kompilator GNU języka C, niezbędny gdy Twój
  program, tak jak większość programów, został napisany w języku C
  (zobacz <manref name="gcc" section="1">).
  Pakiet ten jest powiązany z kilkoma innymi pakietami, takimi jak
  <package>binutils</package>, który zawiera zestaw programów służących
  do asemblacji i konsolidacji plików wynikowych (zobacz
  `info binutils` w pakiecie <package>binutils-doc</package>) i
  <package>cpp</package>, zawierający preprocesor języka C (zobacz
  <manref name="cpp" section="1">).

  <item><package>g++</package> - kompilator GNU języka C++, niezbędny gdy Twój program
  został napisany w języku C++ (zobacz <manref name="g++" section="1">).

  <item><package>libc6-dev</package> - biblioteki języka C i pliki nagłówkowe
  kompilatora gcc niezbędne do konsolidacji plików wynikowych
  (zobacz `info libc` w pakiecie <package>glibc-doc</package>).

  <item><package>make</package> - na ogół proces tworzenia programu składa się z
  szeregu kroków. Zamiast ciągłego powtarzania w kółko tych samych komend,
  możesz posłużyć się programem, który automatyzuje cały proces. Jedyne co
  musisz zrobić, to stworzyć plik(i) `Makefile' (zobacz `info make`).

  <item><package>patch</package> - bardzo użyteczne narzędzie służące do
  tworzenia łat, czyli utworzonych przez program diff plików z różnicami
  pomiędzy plikami źródłowymi, i tworzenia w ten sposób "załatanych" (poprawionych)
  wersji programów (zobacz <manref name="patch" section="1">).

  <item><package>perl</package> - Perl jest jednym z najczęściej stosowanych
  interpretowanych języków skryptowych w systemach kompatybilnych z systemem
  Unix. Często określany jest jako "Uniksowy scyzoryk z piłą łańcuchową"
  (po angielsku znacznie zabawniej: Unix's Swiss Army Chainsaw) - zobacz
  <manref name="perl" section="1">.
  </list>

  <p>Najprawdopodobniej przydadzą się również następujące pakiety:

  <list>
  
  <item><package>autoconf</package> i <package>automake</package> - wiele
  nowszych programów używa skryptów konfiguracyjnych i plików Makefile
  przetworzonych za pomocą takich narzędzi (zobacz `info autoconf`
  i `info automake`).

  <item><package>dh-make</package> i <package>debhelper</package> - pakiet
  dh-make jest niezbędny do stworzenia szablonu naszego przykładowego pakietu.
  Używa on do tworzenia pakietów niektórych narzędzi z pakietu debhelper.
  Pakiety te nie są niezbędne do budowania paczek, ale są <strong>bardzo</strong>
  zalecane, szczególnie nowym opiekunom. Dzięki nim o wiele łatwiej rozpocząć
  proces budowania pakietu i kontrolować go później (zobacz <manref name="dh_make"
  section="1">, <manref name="debhelper" section="1"> i plik
  /usr/share/doc/debhelper/README).

  <item><package>devscripts</package> - pakiet zawierający parę użytecznych
  i pomocnych dla opiekuna skryptów, które nie są jednakże niezbędne do budowania
  pakietów (więcej informacji znajdziesz w pliku /usr/share/doc/devscripts/README.gz).

  <item><package>fakeroot</package> - narzędzie, które pozwala "udawać" bycie
  administratorem systemu (rootem). Uprawnienia administratora są niezbędne
  w niektórych etapach procesu budowania pakietu (zobacz <manref name="fakeroot"
  section="1">).

  <item><package>gnupg</package> - narzędzie umożliwiające cyfrowe
  <em>podpisanie</em> pakietów. Jest to szczególnie ważne, gdy zamierzasz
  rozpowszechniać swój pakiet, a na pewno będziesz musiał to zrobić, gdyby Twój
  pakiet miał być włączony do dystrybucji Debiana (zobacz <manref name="gpg"
  section="1">).

  <item><package>g77</package> - kompilator GNU języka Fortran 77,
  niezbędny gdy Twój program został napisany w języku Fortran (zobacz
  <manref name="g77" section="1">).

  <item><package>gpc</package> - kompilator GNU języka Pascal, niezbędny gdy Twój
  program został napisany w języku Pascal. Warty odnotowania w tym miejscu
  jest również pakiet <package>fp-compiler</package> (Free Pascal Compiler),
  który także nadaje się do tego celu (zobacz <manref name="gpc" section="1">
  i <manref name="ppc386" section="1">).

  <item><package>xutils</package> - niektóre programy, głównie dla X11,
  używają tych narzędzi do wygenerowania plików Makefile z zestawu
  makro-funkcji (zobacz <manref name="imake" section="1">
  i <manref name="xmkmf" section="1">).

  <item><package>lintian</package> - program służący do sprawdzania poprawności
  pakietów Debiana. Poinformuje Cię, gdy w zbudowanej paczce znajdzie 
  błędy i wyjaśni ich przyczynę (zobacz <manref name="lintian" section="1">
  oraz /usr/share/doc/lintian/lintian.html/index.html).
  
  <item><package>pbuilder</package> - ten pakiet zawiera programy, które
  są używane do tworzenia i zarządzania środowiskiem chroot. Budowanie
  pakietów Debiana w tym środowisku weryfikuje poprawność zależności
  i zapobiega powstawaniu błędów FTBFS (zobacz <manref name="pbuilder"
  section="8"> i <manref name="pdebuild" section="1">).
  
  </list>

  <p>Poniżej wymieniamy <em>bardzo ważną</em> dokumentację,
  która powinna być przeczytana razem z tym podręcznikiem:

  <list>
  
  <item><package>debian-policy</package> - Polityka Debiana opisuje strukturę
  i zawartość archiwum Debiana, sprawy dotyczące sposobu projektowania systemu
  operacyjnego, FHS (Standard Hierarchii Systemu Plików - Filesystem Hierarchy
  Standard), który mówi, gdzie powinny się znajdować pliki i katalogi itd.
  Dla Ciebie najważniejszy jest opis wymagań, które musi spełnić każdy pakiet,
  aby mógł być włączony do dystrybucji (zobacz &debian-policy;).

  <item><package>developers-reference</package> - opisuje wszystkie zagadnienia
  nie związane z technicznymi szczegółami procesu tworzenia pakietów,
  a więc strukturę archiwum, sposób zmian nazw pakietów, procedurę ich
  osierocania i adopcji, umieszczania pakietów w archiwum Debiana, również
  nie będąc opiekunem danego pakietu (Non-Maintainer Upload - NMU),
  jak zarządzać błędami, najlepsze praktyki dotyczące pakowania,
  kiedy i gdzie umieszczać pakiet itd. (zobacz &developers-reference;).
  </list>

  <p>Powyższe krótkie opisy służą jedynie jako wprowadzenie do opisu
  każdego z pakietów. Zanim przejdziesz dalej, prosimy gruntownie zapoznać
  się z dokumentacją do każdego z programów, a przynajmniej z ich standardowym
  użyciem. Być może wydaje Ci się to teraz trudne, ale później będziesz
  <em>bardzo</em> zadowolony z przeczytania tej dokumentacji.
  
  <p>Uwaga: pakiet <package>debmake</package> zawiera niektóre programy 
  zbliżone funkcjonalnie do dh-make, ale ten dokument <strong>nie</strong>
  omawia jego użycia, ponieważ jest on <em>przestarzały</em>.
  
  <sect id="debiandeveloper">Oficjalny Deweloper Debiana

  <p>Po zbudowaniu swojego pierwszego pakietu (albo w czasie budowania)
  być może zechcesz zostać oficjalnym Deweloperem Debiana, aby wprowadzić
  swój pakiet do kolejnej dystrybucji (jeśli program jest użyteczny, to
  czemu nie?).
  
  <p>Nie możesz zostać oficjalnym Deweloperem Debiana w ciągu jednej
  nocy, gdyż do tego potrzebne jest coś więcej, niż umiejętności
  techniczne. Niech Cię to jednak nie zniechęca. Możesz wysłać swój
  pakiet, jeśli jest użyteczny dla innych, jako opiekun sponsorowany
  przez zapisanie się na
  <url name="stronie Nowych Opiekunów" id="&nm-home;">.
  Sponsor jest oficjalnym Deweloperem Debiana, który pomaga opiekunom
  włączać pakiety do archiwum Debiana. Więcej o procedurze przyjmowania
  nowych opiekunów jest na stronie
  <url id="&mentors-faq;" name="debian-mentors FAQ">.

  <p>Zwracamy uwagę, że nie ma potrzeby tworzenia nowego pakietu, aby
  stać się oficjalnym Deweloperem Debiana. Rozwój istniejących pakietów
  jest również drogą mogącą prowadzić do zostania oficjalnym Deweloperem.

  <sect id="otherinfo">Inne informacje

  <p>Istnieją dwa rodzaje pakietów, jakie możesz stworzyć: źródłowe i binarne.
  Pakiet źródłowy zawiera kod, który możesz skompilować, aby otrzymać binarną
  postać programu. Pakiet binarny zawiera natomiast już gotowy do użycia
  program. Prosimy nie mylić takich pojęć, jak źródło programu i pakiet źródłowy!
  Więcej szczegółów na temat terminologii jest w innych podręcznikach.

  <p>W Debianie termin `opiekun' (maintainer) oznacza osobę, która tworzy
  pakiety (pakuje programy), `autor' (upstream author) - osobę, która tworzy program,
  a `zewnętrzny opiekun' (upstream maintainer) - osobę, która aktualnie opiekuje
  się programem, pozostając poza projektem Debian. Zwykle autor i zewnętrzny
  opiekun są tą samą osobą - czasem nawet tą samą osobą jest opiekun.
  Jeśli napisałeś jakiś program i chcesz, żeby wszedł w skład Debiana,
  przyślij swoje zgłoszenie i zostań opiekunem.
  
  <!-- -------------------------------------------------------------------------->

  <chapt id="first">Pierwsze kroki

  <sect id="choose">Wybierz swój program

  <p>Prawdopodobnie wybrałeś już pakiet, który chcesz zbudować. Pierwszą rzeczą,
  którą powinieneś zrobić, to sprawdzić, czy pakiet znajduje się już
  w dystrybucji, przy pomocy programu <prgn>aptitude</prgn>.
  Jeśli używasz dystrybucji 'stabilnej', zapewne najlepiej przejść do
  <url name="strony wyszukiwania pakietów" id="http://www.debian.org/distrib/packages">.

  <p>Jeśli pakiet już istnieje, to cóż, zainstaluj go! :-) Jeśli przypadkiem
  jest on osierocony (jego opiekunem jest "Debian QA Group"), to być może
  możesz się nim zaopiekować.

  <p>Sprawdź na stronie
  <url name="Pakietów Rokujących i Wymagających Pracy" id="http://www.debian.org/devel/wnpp/">
  i stronach powiązanych ostatni status adopcji/osierocenia pakietu.

  <p>Jeśli możesz zaadoptować pakiet, pobierz jego źródła (poleceniem
  <tt>apt-get source nazwa_pakietu</tt>) i przetestuj go. Niestety ten
  dokument nie zawiera informacji na temat adopcji pakietów. Za to
  nie musisz męczyć się, rozpracowując działanie danego pakietu, gdyż
  ktoś już wcześniej dokonał wstępnych ustawień. Ale czytaj dalej, bo
  poniższe porady będą z pewnością wartościowe również dla Ciebie.

  <p>Jeśli pakiet jest nowy i chciałbyś, żeby został włączony do dystrybucji
  Debiana, wykonaj poniższe instrukcje:

  <list>
  <item>sprawdź na stronie <url name="lista pakietów w opracowaniu"
  id="http://www.de.debian.org/devel/wnpp/being_packaged">, czy ktoś już nie
  pracuje nad tym pakietem. Jeśli ktoś już to robi, to możesz się z nim
  skontaktować, jeśli sądzisz, że mógłbyś mu pomóc. Jeśli nie - znajdź
  jakiś inny interesujący Cię program, który nie ma jeszcze swojego opiekuna.
  </item>

  <item>program <strong>musi</strong> mieć licencję i, jeśli to możliwe,
  najlepiej zgodną z <url name="Wytycznymi Debiana dotyczącymi Wolnego
  Oprogramowania" id="http://www.debian.org/social_contract.html#guidelines">
  oraz <strong>nie może</strong> wymagać pakietów spoza sekcji main
  do kompilacji lub wykonania, bo jest to niezgodne z Polityką Debiana.
  Jeśli nie zgadza się to z którąś z powyższych zasad, program może być
  włączony do sekcji `contrib' lub `non-free', zależnie od sytauacji.
  Gdy nie jesteś pewny, do której sekcji można włączyć program, wyślij tekst
  licencji na listę <email>debian-legal@lists.debian.org</email>
  i poproś o poradę.
  </item>

  <item>program z pewnością <strong>nie</strong> powinien być uruchamiany
  z ustanowionym identyfikatorem administratora systemu (setuid root), a
  jeszcze lepiej - nie powinien potrzebować ustanowionego żadnego
  identyfikatora użytkownika lub grupy.</item>

  <item>program nie powinien być demonem ani innym programem umieszczanym
  w katalogu */sbin, ani nie powinien otwierać portu jako administrator
  systemu.</item>

  <item>program powinien mieć binarną, wykonywalną formę, biblioteki są
  trudniejsze w utrzymaniu.</item>

  <item>program powinien być dobrze udokumentowany, a kod 
  zrozumiały (np. nie zagmatwany).</item>

  <item>powinieneś skontaktować się z autorem(ami) programu, aby sprawdzić
  czy zgadzają się na jego zapakowanie. Ważną rzeczą jest możliwość
  konsultacji z autorem w razie wystąpienia jakichś specyficznych problemów.
  Nie próbuj pakować oprogramowania, którym się nikt nie zajmuje.</item>

  <item>i na końcu, choć wcale nie jest to najmniej ważne, musisz wiedzieć jak
  program działa i wypróbować go przez pewien czas.</item>
  </list>

  <p>Oczywiście powyższe zalecenia to po prostu zabezpieczenia, które mają
  na celu uchronić Cię przed gniewem użytkowników, gdy zrobisz coś źle w
  jakimś demonie z ustanowionym identyfikatorem użytkownika...
  Gdy nabierzesz już więcej doświadczenia, będziesz mógł pakować
  nawet takie programy, ale nawet najbardziej doświadczeni deweloperzy
  konsultują się na liście dyskusyjnej Mentorów Debiana, gdy mają
  jakieś wątpliwości. Ludzie stamtąd z pewnością chętnie pomogą.

  <p>Więcej informacji na te tematy znajdziesz w dokumencie Developer's
  Reference.

  <sect id="getit">Weź program i wypróbuj go

  <p>Pierwszą rzeczą, którą powinieneś zrobić, to odnalezienie i pobranie
  oryginalnego pakietu. Zakładam, że już masz plik źródłowy, który pobrałeś
  ze strony domowej jego autora. Źródła z wolnym oprogramowaniem dla Uniksa
  są zwykle rozprowadzane w formacie tar/gzip, z rozszerzeniem
  .tar.gz. Pliki te na ogół zawierają podkatalog o nazwie program-wersja,
  w którym znajdują się wszystkie pliki źródłowe. Jeśli źródła wybranego przez
  Ciebie programu są rozprowadzane w innego rodzaju archiwum (na przykład pliki
  kończące się na ".Z" lub ".zip"), to wypakuj je przy pomocy odpowiedniego
  narzędzia. Gdy nie jesteś pewien, jak zrobić to poprawnie, zapytaj
  (po angielsku) na liście dyskusyjnej Mentorów Debiana (wskazówka:
  temat `file archive.extension`).

  <p>Jako przykładu będziemy używać programu o nazwie `gentoo' - menadżera
  plików dla systemu X Windows, który wykorzystuje bibliotekę GTK+. Zwróć
  uwagę, że program ten jest już zapakowany i znacznie się zmienił od czasu,
  gdy pisany był ten tekst.

  <p>W swoim katalogu domowym utwórz podkatalog o nazwie 'debian', 'deb' lub
  jakkolwiek uważasz za właściwe (np. po prostu <file>~/gentoo/</file>
  jest w tym przypadku dobrym rozwiązaniem). Umieść w nim pobrane archiwum
  i rozpakuj je (za pomocą `tar xzf gentoo-0.9.12.tar.gz`). Upewnij się, że nie
  ma żadnych błędów, nawet jakichś nieistotnych, ponieważ najprawdopodobniej
  pojawią się problemy w czasie rozpakowywania w systemach innych użytkowników,
  których narzędzia do wypakowywania mogą, ale nie muszą, ignorować takie
  nieprawidłowości.

  <p>Teraz w katalogu tym powinieneś mieć podkatalog o nazwie
  `gentoo-0.9.12'. Wejdź do niego i <strong>dokładnie</strong> przeczytaj
  znajdującą się tam dokumentację. Zwykle powinny tam być pliki o nazwach
  README*, INSTALL*, *.lsm lub *.html. Odszukaj w dokumentacji instrukcji,
  jak poprawnie skompilować i zainstalować program (najprawdopodobniej będą
  one zakładać, że chcesz zainstalować program do katalogu /usr/local/bin;
  ale Ty nie rób tak, więcej o tym w rozdziale <ref id="destdir">).

  <p>Proces instalacji różni się w zależności od programu, ale wiele
  nowoczesnych programów jest dostarczanych ze skryptem `configure',
  który konfiguruje źródła pod Twoim systemem i sprawdza, czy spełniają one
  warunki niezbędne do poprawnej kompilacji. Po zakończeniu konfiguracji
  wykonywanej za pomocą polecenia `./configure`, programy są na ogół
  kompilowane przy użyciu komendy `make`. Niektóre z nich pozwalają także
  na użycie `make check`, który uruchamia procedurę samosprawdzającą.
  Instalacja w katalogu przeznaczenia następuje zwykle po wydaniu polecenia
  `make install`.

  <p>Teraz spróbuj skompilować i uruchomić program, aby upewnić się czy działa
  on prawidłowo i nic się nie psuje w czasie instalacji lub wykonywania.

  <p>Możesz też zazwyczaj użyć polecenia `make clean` (lub lepiej `make
  distclean`), aby posprzątać w katalogu, w którym kompilowałeś. Czasem
  można nawet posłużyć się poleceniem `make uninstall`, które usunie wszystkie
  zainstalowane pliki.

  <sect id="namever">Nazwa pakietu i jego wersja

  <p>Powinieneś rozpocząć pakowanie z zupełnie wyczyszczonym
  (ang. pristine - pierwotnym) katalogiem źródłowym, ewentualnie ze świeżo
  rozpakowanymi źródłami.

  <p>Aby prawidłowo zbudować pakiet, musisz tak zmienić nazwę oryginalnego
  programu, żeby występowały w niej tylko małe litery (o ile występują tam
  jakieś wielkie litery). Powinieneś także przenieść katalog ze źródłami do
  katalogu &lt;nazwa_pakietu&gt;-&lt;wersja&gt;.

  <p>Jeśli nazwa programu składa się z więcej niż jednego wyrazu, to skróć
  ją do jednego wyrazu albo utwórz skrót. Na przykład program
  "John's little editor for X" powinien się nazywać johnledx, jle4x lub
  jakoś tak. Pamiętaj jednak, aby jego długość nie przekraczała jakiejś
  rozsądnej wartości, np. 20 znaków.

  <p>Sprawdź także dokładnie wersję programu (będzie ona włączona do nazwy
  pakietu). Jeśli do oznaczenia jego wersji autor nie użył konwencji X.Y.Z,
  ale posłużył się datą, to Ty również możesz jej użyć do określenia wersji
  pakietu, poprzedzając ją ciągiem "0.0." (na wypadek gdyby autor
  programu zdecydował się kiedyś wydać wersję o miło brzmiącym numerze 1.0).
  Zatem, jeśli datą wydania danej wersji programu było 19 grudnia 1998 r.,
  to powinieneś oznaczyć jego wersję jako 0.0.19981219.

  <p>Niektóre programy nie są jednak w żaden sposób numerowane. W takich
  przypadkach powinieneś skontaktować się z zewnętrznym opiekunem, aby
  dowiedzieć się, czy używa on jakiejś innej metody do oznaczania kolejnych
  poprawek programu.

  <sect id="dh_make">Wstępna "debianizacja"

  <p>Upewnij się, że jesteś w katalogu ze źródłami programu i wydaj następujące
  polecenie:

  <p><example>
  dh_make -e twój.adres@opiekuna.pl -f ../gentoo-0.9.12.tar.gz
  </example>

  <p>Oczywiście musisz zastąpić ciąg "twój.adres@opiekuna.pl" adresem Twojej
  skrzynki pocztowej, gdyż zostanie on wpisany do pliku ze zmianami
  (changelog) i innych plików, oraz zastąpić nazwę pliku
  nazwą Twojego archiwum źródłowego. Więcej szczegółów znajdziesz
  na stronie podręcznika <manref name="dh_make" section="1">.

  <p>Trzeba też wprowadzić kilka dodatkowych informacji. Zostaniesz poproszony
  o podanie typu pakietu, który tworzysz. Gentoo to pojedynczy pakiet binarny
  - tworzy on tylko plik binarny, a zatem jeden plik .deb. W takim wypadku
  zaznaczamy pierwszą opcję za pomocą klawisza `s'. Następnie sprawdzamy
  informacje na ekranie i, jeśli wszystko się zgadza, potwierdzamy je
  naciskając &lt;enter&gt;.
  
  <p>Po wykonaniu <prgn>dh_make</prgn> jest tworzona kopia autorskiego
  archiwum jako <file>gentoo_0.9.12.orig.tar.gz</file>, w katalogu
  nadrzędnym, w celu dostosowania, jako niedebianowego pakietu
  pakietu źródłowego, do <file>diff.gz</file>.
  Nazwa tego pliku ma 2 zasadnicze właściwości:
  
  <list compact>
  <item>Nazwa pakietu i wersja są rozdzielone przez "<tt>_</tt>" .
  <item>Został dodany sufiks "<tt>orig.</tt>" przed "<tt>tar.gz</tt>" .
  </list>
  
  <p>Powtórzmy: ponieważ jesteś jeszcze nowym opiekunem, odradzamy
  Ci tworzenie skomplikowanych pakietów, takich jak:
  <list compact>
  <item>wielokrotne pakiety binarne
  <item>pakiety bibliotek
  <item>z plików źródłowych innych niż <tt>tar.gz.</tt> lub <tt>tar.bz2</tt>, czy też
  <item>z archiwów, których zawartość nie może być dystrybuowana.
  </list>

  <p>Prosimy zauważyć, że powinno się uruchomić program <prgn>dh_make</prgn>
  <strong>tylko jeden raz</strong>, gdyż nie zachowa się on poprawnie, gdy
  uruchomisz go ponownie w tym samym już "zdebianizowanym" katalogu. Oznacza
  to również, że będziesz musiał użyć innej metody, aby wprowadzić
  w przyszłości nową poprawkę lub nową wersję pakietu. Więcej informacji
  na ten temat znajdziesz dalej w rozdziale <ref id="update">.

  <!-- -------------------------------------------------------------------------->

  <chapt id="modify">Modyfikacja źródła

  <p>Normalnie programy instalują się w podkatalogach katalogu /usr/local.
  Pakiety Debiana nie mogą jednak używać tego katalogu, gdyż jest on
  zarezerwowany do prywatnego użycia przez administratora (lub użytkowników)
  systemu. Oznacza to, że musisz się przyjrzeć, jak budowany jest Twój program,
  zwykle za pomocą pliku Makefile. Jest to skrypt programu <manref name="make"
  section="1"> używanego do automatycznego budowania programu. Więcej szczegółów
  na temat plików Makefile znajdziesz w rozdziale <ref id="rules">.

  <p>Zwróć też uwagę na to, czy Twój program używa programów GNU
  <manref name="automake" section="1"> i/lub <manref name="autoconf"
  section="1">, czyli czy źródła programu zawierają plik Makefile.am i/lub
  Makefile.in, to je będziesz musiał wtedy modyfikować. Dzieje się tak,
  ponieważ każde wywołanie programu automake powoduje ponowne utworzenie pliku
  Makefile.in z informacjami wygenerowanymi z pliku Makefile.am. Także każde
  wywołanie skryptu ./configure zrobi to samo z plikiem Makefile, na podstawie
  pliku Makefile.in. Edycja plików Makefile.am wymaga pewnej wiedzy
  na temat programu automake, możesz o nim poczytać za pomocą komendy `info
  automake'. Edytowanie plików Makefile.in odbywa się niemal tak samo, jak
  w przypadku plików Makefile, po prostu trzeba zwracać uwagę na zmienne,
  tzn. wszystkie łańcuchy otoczone przez znaki `@', dla przykładu zmienna
  @CFLAGS@ lub @LN_S@ będzie zastępowana odpowiednią wartością przy każdym
  wywołaniu skryptu ./configure. Przeczytaj dokumentację
  <file>&autotools-dev;</file>, zanim zaczniesz modyfikacje.

  <p>Zauważ również, że nie ma tu wystarczającego miejsca, aby opisać
  <em>wszystkie</em> szczegóły na temat poprawiania zewnętrznych źródeł.
  Przedstawiam tu jedynie kilka problemów, z którymi często można się
  spotkać.

  <sect id="destdir">Instalacja w podkatalogu

  <p>Wiekszość programów posiada swój własny sposób instalowania się
  w istniejącej strukturze katalogów systemu. Binaria trafiają do katalogów
  określonych zmienną środowiskową $PATH, zaś dokumentacja i strony podręcznika
  są umieszczane w zwykle stosowanych miejscach. Jednakże, jeśli pozwolisz
  na takie działanie, program może się zainstalować w każdym miejscu systemu.
  Może sprawić to problemy narzędziom do obsługi pakietów, gdyż nie będą one
  wiedziały, które pliki należą do Twojej paczki, a które nie.

  <p>Zatem musisz zrobić coś innego: zainstalować swój program w tymczasowym
  katalogu, z którego narzędzia opiekuna zbudują działający pakiet .deb.
  Wszystko co zawiera ten katalog, zostanie zainstalowane w systemie
  użytkowników, gdy zdecydują się oni zainstalować Twój pakiet, z tą tylko
  różnicą, że program dpkg zainstaluje pliki względem katalogu głównego
  systemu.

  <p>Ten tymczasowy katalog jest zazwyczaj tworzony wewnątrz Twojego
  katalogu debian/ w rozpakowanym drzewie ze źródłami. Na ogół ma on nazwę
  <file>debian/nazwa_pakietu</file>.

  <p>Pamiętaj, że nie wystarczy, żeby program zachowywał się poprawnie,
  gdy zostanie on zainstalowany się w katalogu debian/nazwa_pakietu. Musi on
  zachowywać się właściwie także, gdy zostanie umieszczony w głównym katalogu
  systemu. Zatem nie wolno pozwolić, żeby w plikach pakietu zostały "zaszyte"
  pełne ścieżki, np. <tt>/home/ja/deb/gentoo-0.9.12/usr/share/gentoo</tt>.

  <p>Sprawa jest prosta, gdy programy używają narzędzia GNU autoconf.
  Większość z nich posiada pliki Makefile, które domyślnie są ustawione w taki
  sposób, aby zezwalać na instalację w dowolnym podkatalogu zakładając,
  że katalog /usr (dla przykładu) jest kanonicznym prefiksem. Gdy zostanie
  wykryte, że Twój program używa autoconfa, to dh_make ustawi
  odpowiednie polecenia tak, żeby wszystko zostało zrobione automatycznie.
  W takich przypadkach możesz nawet ominąć dalsze czytanie tej sekcji.
  Jednak z innymi programami będziesz miał więcej pracy i prawdopodobnie
  będziesz musiał przejrzeć i wyedytować pliki Makefile.

  <p>Poniżej znajduje się odpowiednia część pliku Makefile programu gentoo:

  <p><example>
  # Katalog binariów dla 'make install'
  BIN     = /usr/local/bin

  # Katalog ikon dla 'make install'
  ICONS   = /usr/local/share/gentoo
  </example>

  <p>Widzimy, że pliki te zostaną zainstalowane w katalogu
  <file>/usr/local</file>. Zmieńmy zatem ścieżki na następujące:

  <p><example>
  # Katalog binariów dla 'make install'
  BIN     = $(DESTDIR)/usr/bin

  # Katalog ikon dla 'make install'
  ICONS   = $(DESTDIR)/usr/share/gentoo
  </example>

  <p>Ale dlaczego właśnie w tym katalogu, a nie w jakimś innym? Ponieważ pakiety
  Debiana nigdy nie instalują plików w katalogu <file>/usr/local</file>.
  Ten katalog jest zarezerwowany na potrzeby administratora systemu. W systemie
  Debian zaś takie pliki trafiają do katalogu <file>/usr</file>.

  <p>Dokładniejsze informacje na temat położenia binariów, ikon, dokumentacji
  itd. są opisane w dokumencie Filesystem Hierarchy Standard (zobacz
  w katalogu /usr/share/doc/debian-policy/fhs/). Polecamy Ci przejrzenie tego
  dokumentu i przeczytanie tych sekcji, które mogą dotyczyć Twojego pakietu.

  <p>Zatem powinniśmy instalować pliki binarne w katalogu /usr/bin, a nie
  w /usr/local/bin, strony podręcznika w katalogu /usr/share/man/man1, a nie
  w /usr/local/man/man1 itd. Zauważ, że w pliku Makefile programu gentoo nie
  wspomniano o jego stronie podręcznika, ale ponieważ Polityka Debiana wymaga,
  żeby każdy program posiadał taką stronę, to stworzymy ją później
  i zainstalujemy w katalogu /usr/share/man/man1.

  <p>Niektóre programy nie używają zmiennych w plikach Makefile do definiowania
  ścieżek, takich jak te powyżej. Oznacza to, że będziesz musiał wyedytować
  niektóre źródła napisane w języku C i tak je poprawić, aby używały właściwych
  katalogów. Ale gdzie i czego właściwie szukać? Możesz to odnaleźć wydając
  polecenie:

  <p><example>
  grep -nr -e 'usr/local/lib' --include='*.[c|h]' .
  </example>

  <p>Program grep przeszuka rekursywnie całe drzewo ze źródłami i wypisze
  nazwy plików i numery linii, gdy odnajdzie szukany wzorzec.

  <p>Wyedytuj te pliki i w odnalezionych liniach zastąp ciąg /usr/local/*
  ciągiem usr/* &mdash; i to już wszystko. Zrób to uważnie, aby nie zepsuć
  pozostałej części kodu! :-)

  <p>Następnie powinieneś odnaleźć w pliku Makefile cel `install'
  (szukaj linii rozpoczynającej się od ciągu "install:') i zmienić wszystkie
  odniesienia do katalogów innych, niż te zdefiniowane na początku
  pliku Makefile. Przed zmianą, cel `install' programu gentoo był następujący:

  <p><example>
  install:        gentoo
                  install ./gentoo $(BIN)
                  install icons/* $(ICONS)
                  install gentoorc-example $(HOME)/.gentoorc
  </example>

  <p>Po wykonaniu zmian wygląda on następująco:

  <example>
  install:        gentoo-target
                  install -d $(BIN) $(ICONS) $(DESTDIR)/etc
                  install ./gentoo $(BIN)
                  install -m644 icons/* $(ICONS)
                  install -m644 gentoorc-example $(DESTDIR)/etc/gentoorc
  </example>

  <p>Na pewno zauważyłeś, że teraz przed pozostałymi poleceniami w tej
  regule będzie wykonywana komenda <tt>install -d</tt>. Oryginalny plik
  Makefile nie miał jej, gdyż zwykle katalog /usr/local/bin i inne katalogi
  istnieją już w systemie, zanim wyda się polecenie `make install`.
  Jednakże, gdy instalujemy program do własnego, pustego (lub nawet
  nie istniejącego) katalogu, to będziemy musieli utworzyć każdy z tych
  katalogów.

  <p>Możemy również dodać inne rzeczy na końcu tej reguły, na przykład
  instalację dodatkowej dokumentacji, którą autor programu czasem pomija:

  <p><example>
                  install -d $(DESTDIR)/usr/share/doc/gentoo/html
                  cp -a docs/* $(DESTDIR)/usr/share/doc/gentoo/html
  </example>

  <p>Uważny czytelnik zauważy, że zmieniliśmy `gentoo' na `gentoo-target' w linii
  rozpoczynającej się od ciągu `install:'. To jest tzw. poprawka niedotycząca
  (unrelated bug fix) :-)

  <p>Ilekroć dokonasz zmian, które nie są ściśle związane z pakietem Debiana,
  poinformuj o nich opiekuna zewnętrznego, aby mógł on je włączyć do następnej
  wersji programu i by również ktoś inny mógł z nich skorzystać.
  Pamiętaj także, żeby tworzyć poprawki nie specyficzne dla Debiana,
  Linuksa (lub nawet Uniksa!) przed ich wysłaniem &mdash; niech będą one
  przenośne. Dzięki temu Twoje łaty będzie łatwiej nałożyć.

  <p>Zauważ, że nie musisz wysyłać autorowi programu plików debian/*.

  <sect id="difflibs">Nie zgadzające się biblioteki

  <p>Tutaj mamy pewien dość powszechny problem: biblioteki często różnią się
  pomiędzy platformami. Dla przykładu, plik Makefile może zawierać odwołania
  do biblioteki, której nie ma Debianie. W takim przypadku musimy zamienić ją
  na bibliotekę, która jest dostępna w Debianie i służy tym samym celom.

  <p>Jeśli zatem w pliku Makefile (lub Makefile.in) Twojego programu istnieje
  linia podobna do tej poniżej (i Twój program nie chce się skompilować):

  <p><example>
  LIBS = -lcurses -lcoś -lcoś_innego
  </example>
  
  <p>to zmień ją w pokazany sposób i to powinno pomóc:

  <p><example>
  LIBS = -lncurses -lcoś -lcoś_innego
  </example>

  <p>(Autor zdaje sobie sprawę, że to nie jest najlepszy przykład,
  zważywszy na to, że pakiet libncurses jest teraz dostarczany wraz z
  dowiązaniem symbolicznym do biblioteki libcurses.so, ale nie mógł wymyślić
  niczego lepszego. Sugestie będą bardzo mile widziane :-)

  <!-- -------------------------------------------------------------------------->

  <chapt id="dreq">Rzeczy wymagane w katalogu debian/

  <p>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.

  <sect id="control">Plik `control'

  <p>Ten plik zawiera różne informacje, których używaja programy <prgn/dpkg/,
  <prgn/dselect/ oraz inne narzędzia służące do zarządzania pakietem.

  <p>Poniżej przedstawiono plik control utworzony przez program dh_make:

  <p><example>
  1  Source: gentoo
  2  Section: unknown
  3  Priority: optional
  4  Maintainer: Josip Rodin &lt;joy-mg@debian.org&gt;
  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: &lt;insert up to 60 chars description&gt;
  12  &lt;insert long description, indented with spaces&gt;
  </example>
  (dodałem numery linii)

  <p>Linie 1-6 zawierają informacje kontrolne dla pakietu źródłowego.
        
  <p>Linia 1. zawiera nazwę pakietu źródłowego.

  <p>Linia 2. oznacza sekcję dystrybucji, do której należy pakiet źródłowy.
        
  <p>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.

  <p>Zmieńmy ją zatem na x11. Prefiks "main/" jest przyjmowany domyślnie,
  więc możemy go pominąć.

  <p>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".

  <p>Sekcja (Section) i priorytet (Priority) są używane przez nakładki,
  jak program <prgn/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.

  <p>Ponieważ jest to pakiet o normalnym priorytecie i nie jest w konflikcie
  z innym pakietem, to pozostawiamy tam wartość "optional".

  <p>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 (`&amp;') i nawiasów.

  <p>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 <package/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.

  <p>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.

  <p>Poniżej pokazano sztuczkę, dzięki której odszukasz pakiety,
  których potrzebuje do zbudowania Twój pakiet:

  <example>
  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
  </example>

  <p>Aby ręcznie znaleźć kompletny zestaw zależności dla programu
  <prgn><var>/usr/bin/foo</var></prgn>, wykonaj
  <example>
  objdump -p <var>/usr/bin/foo</var> | grep NEEDED
  </example>
  a dla każdej znalezionej biblioteki, np. <prgn>libfoo.so.6</prgn>, wykonaj
  <example>
  dpkg -S libfoo.so.6 
  </example>
  Potem tylko weź wersję -dev każdej z nich jako pozycję w `Build-deps'.
  Jeśli używasz do tego celu <prgn>ldd</prgn>, pokazuje on
  również zależności niebezpośrednie, co skutkuje zbyt dużą liczbą
  wykazywanych zależności.

  <p>Tak więc program gentoo wymaga do zbudowania pakietów <package/xlibs-dev/,
  <package/libgtk1.2-dev/ i <package/libglib1.2-dev/, więc dodajmy je
  za pakietem <package/debhelper/.

  <p>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.

  <p>Linia 8. to nazwa pakietu binarnego. Zwykle jest ona taka sama jak nazwa
  pakietu źródłowego, ale nie musi to być regułą.

  <p>Linia 9. opisuje architekturę procesora, dla którego może być
  skompilowany pakiet. Pozostawimy w niej "any", gdyż pakiet
  <manref name="dpkg-gencontrol" section="1"> sam wstawi w tym miejscu
  odpowiednią wartość dla każdego typu maszyny, na której kompilowany jest
  pakiet.

  <p>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 <ref id="rules"> na temat używania reguły
  `binary-indep' zamiast `binary-arch' do budowania pakietu.

  <p>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:.

  <p>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 <manref name="dpkg" section="8">,
  <manref name="dselect" section="8">, <manref name="apt" section="8">,
  <manref name="aptitude" section="1">, itd.).

  <p>Pola te oznaczają:

  <p><list>
  <item>Depends: (Wymaga)
  <p>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.</item>

  <item>Recommends: (Zaleca)
  <p>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.</item>

  <item>Suggests: (Poleca)
  <p>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.</item>

  <item>Pre-Depends: (Przed-Wymaga)
  <p>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 <em>poprawnie skonfigurowane</em>. Używaj tego pola
  <strong>bardzo</strong> oszczędnie i jedynie po przedyskutowaniu tego na
  liście debian-devel. Czytaj: nie używaj go nigdy. :-)</item>

  <item>Conflicts: (PowodujeKonflikt)
  <p>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.</item>

  <item>Provides: (Dostarcza)
  <p>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.</item>

  <item>Replaces: (Zastępuje)
  <p>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.
  </item>
  </list>

  <p>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 <tt>|</tt>
  (symbol potoku).

  <p>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ą: <tt>&lt;&lt;</tt>, <tt>&lt;=</tt>, <tt>=</tt>,
  <tt>&gt;=</tt> i <tt>&gt;&gt;</tt>, odpowiednio: wcześniejszy, wcześniejszy
  lub równy, dokładnie równy, późniejszy lub równy i późniejszy. Dla przykładu:

  <p><example>
  Depends: foo (>= 1.2), libbar1 (= 1.3.4)
  Conflicts: baz
  Recommends: libbaz4 (>> 4.0.7)
  Suggests: quux
  Replaces: quux (<< 5), quux-foo (<= 7.6)
  </example>

  <p>Ostatnią cechą, o której powinieneś wiedzieć, jest ${shlibs:Depends}.
  Gdy Twój pakiet zostanie zbudowany i zainstalowany w tymczasowym katalogu,
  program <manref name="dh_shlibdeps" section="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
  <manref name="dh_gencontrol" section="1"> umieści ich nazwy we właściwym
  miejscu, więc nie musisz się o to martwić.

  <p>Skoro już wszystko to zostało powiedziane, możemy pozostawić linię 10.
  w takiej postaci jak teraz i wstawić po niej <tt>Suggests: file</tt>,
  ponieważ gentoo może użyć niektórych funkcjonalności dostarczanych przez
  ten program/pakiet.

  <p>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+).

  <p>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.

  <p>A oto końcowa postać uaktualnionego pliku `control':

  <p><example>
  1  Source: gentoo
  2  Section: x11
  3  Priority: optional
  4  Maintainer: Josip Rodin &lt;joy-mg@debian.org&gt;
  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).
  </example>
  (numery linii zostały dodane przeze mnie)

  <sect id="copyright">Plik `copyright'

  <p>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").

  <p>Program dh_make stworzył już domyślny plik, którego zawartość jest
  podobna do tej poniżej:

  <p><example>
  1  This package was debianized by Josip Rodin &lt;joy-mg@debian.org&gt; on
  2  Wed, 11 Nov 1998 21:02:14 +0100.
  3
  4  It was downloaded from &lt;fill in ftp site&gt;
  5
  6  Upstream Author(s): &lt;put author(s) name and email here&gt;
  7
  8  Copyright:
  9
  10 &lt;Must follow here&gt;
  </example>
  (numery linii zostały dodane przeze mnie)

  <p>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.

  <p>Poniżej pokazano w skrócie, jak powinien wyglądać plik `copyright' dla
  programu gentoo:

  <p><example>
  1  This package was debianized by Josip Rodin &lt;joy-mg@debian.org&gt; 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 &lt;emil@obsession.se&gt;
  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'.
  </example>
  (numery linii zostały dodane przeze mnie)

  <p>Prosimy postępować zgodnie z plikiem HOWTO z listy debian-devel-announce:
  <url id="&copyright-howto;">.

  <sect id="changelog">Plik `changelog'

  <p>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.

  <p>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.

  <p>Program dh_make również tworzy ten plik, którego zawartość wygląda mniej
  więcej tak:

  <p><example>
  1  gentoo (0.9.12-1) unstable; urgency=low
  2
  3   * Initial Release.
  4
  5  -- Josip Rodin &lt;joy-mg@debian.org&gt;  Wed, 11 Nov 1998 21:02:14 +0100
  6
  </example>
  (numery linii zostały dodane przeze mnie)

  <p>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). :-)

  <p>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 <manref name="dch" section="1"> lub używając
  jakiegoś edytora tekstu.

  <p>Poprawiony będzie wyglądał jakoś tak:

  <p><example>
  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 &lt;joy-mg@debian.org&gt; Wed, 11 Nov 1998 21:02:14 +0100
  8
  </example>
  (numery linii zostały dodane przeze mnie)

  <p>Więcej na temat pliku `changelog' bedziesz mógł przeczytać dalej
  w rozdziale <ref id="update">.

  <sect id="rules">Plik `rules'

  <p>Teraz musimy się przyjrzeć regułom (ang. rules), których użyje program
  <manref name="dpkg-buildpackage" section="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.

  <p>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
  &lt;tab&gt;. 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.

  <p>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.

  <p>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.

  <p>Poniżej pokazano przykładowy domyślny plik debian/rules, który został
  wygenerowany przez program dh_make:

  <p><example>
&makefile;
  </example>
  (numery linii zostały dodane przeze mnie; w rzeczywistym pliku
  <file>debian/rules</file> wiodące białe znaki są tabulatorami)

  <p>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'.

  <p>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 <manref name="debhelper" section="1">.

  <p>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.

  <p>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 <em>dodanie</em> łańcucha <tt>CFLAGS="$(CFLAGS)"</tt> 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 <em>poprzedzenie</em> powyższym łańcuchem wywołania skryptu ./configure
  w regule `build'.

  <p>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
  <manref name="dh_strip" section="1">, który wykryje, gdy ustawiona jest
  opcja DEB_BUILD_OPTIONS=nostrip i zakończy swe działanie.

  <p>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 <file>&autotools-dev;</file>.
  O zakomentowanym przykładzie docbook-to-man opowiemy dalej w
  rozdziale <ref id="manpage">.

  <p>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 <em>jest</em> 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.

  <p>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 <tt>$(CURDIR)/debian/gentoo</tt> -
  oto dlaczego określiliśmy zmienną $(DESTDIR) jako katalog bazowy
  instalacji w pliku Makefile programu gentoo.

  <p>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.

  <p>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.

  <p>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'.

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

  <list>

  <item><manref name="dh_testdir" section="1"> sprawdza, czy jesteś we właściwym
      katalogu (tzn. na samej górze katalogu ze źródłami)
  <item><manref name="dh_testroot" section="1"> sprawdza, czy masz uprawnienia
      administratora systemu, których wymagają cele `binary-arch',
      `binary-indep' i `clean'
  <item><manref name="dh_installman" section="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
  <item><manref name="dh_strip" section="1"> usuwa z plików wykonywalnych
      i bibliotek nagłówki służące do odpluskwiania, aby uczynić je
      mniejszymi
  <item><manref name="dh_compress" section="1"> pakuje programem
      <manref name="gzip" section="1"> strony podręcznika i dokumentację
      większą niż 4 kB
  <item><manref name="dh_installdeb" section="1"> kopiuje pliki związane
      z pakietem (na przykład skrypty opiekuna) do katalogu
      <file>debian/gentoo/DEBIAN</file>
  <item><manref name="dh_shlibdeps" section="1"> wylicza zależności bibliotek
      i plików wykonywalnych od bibliotek współdzielonych
  <item><manref name="dh_gencontrol" section="1"> instaluje finalną wersję
      pliku `control' w katalogu <file>debian/gentoo/DEBIAN</file>
  <item><manref name="dh_md5sums" section="1"> generuje sumy kontrolne MD5 dla
      każdego pliku zawartego w pakiecie
  </list>

  <p>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.

  <p>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.

  <p>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ć.

  <!-- -------------------------------------------------------------------------->

  <chapt id="dother">Inne pliki z katalogu debian/

  <p>Jak zobaczysz, w katalogu debian/ znajdują się jeszcze różne inne pliki,
  większość z nich kończy się przyrostkiem `.ex', oznaczającym, że są to
  przykłady. Przyjrzyj się im wszystkim. Jeśli chcesz lub musisz użyć
  którejś z ich funkcjonalności, to:

  <list>
    <item>zajrzyj do odpowiedniej dokumentacji (wskazówka: podręcznik Polityki
      Debiana)
    <item>jeśli to konieczne, zmodyfikuj zawartość plików według potrzeb
    <item>usuń z ich nazwy przyrostek `.ex', jeśli taki posiadają
    <item>usuń z ich nazwy przedrostek `ex.', jeśli taki posiadają
    <item>zmodyfikuj plik `rules' według potrzeb
  </list>

  <p>Niektóre z tych plików, najczęściej używane, są objaśnione w poniższych
  sekcjach.

  <sect id="readme">Plik `README.Debian'

  <p>W tym pliku powinny być udokumentowane dodatkowe szczegóły lub
  rozbieżności pomiędzy oryginalnym pakietem i Twoją "zdebianizowaną" wersją.

  <p>Program dh_make tworzy domyślny plik README.Debian, który wygląda jakoś tak:

  <p><example>
  gentoo for Debian
  -----------------

  &lt;possible notes regarding this package - if none, delete this file&gt;

   -- Josip Rodin &lt;joy-mg@debian.org&gt;, Wed, 11 Nov 1998 21:02:14 +0100
  </example>

  <p>Ponieważ nie musimy niczego umieszczać w tym pliku, możemy go skasować.

  <sect id="conffiles">Plik `conffiles.ex'

  <p>Jedną z najbardziej irytujących rzeczy związanych z oprogramowaniem jest
  to, że po poświęceniu dużej ilości czasu i wysiłku na dostosowanie programu,
  jego aktualizacja wszystko "zadeptuje". Debian rozwiązał ten problem przez
  znakowanie plików konfiguracyjnych. Zatem jeśli uaktualniasz program do
  nowszej wersji, to zostaniesz zapytany o to, czy chcesz zachować swoją starą
  konfigurację, czy nie.

  <p>Aby to uzyskać, musisz wprowadzić pełną ścieżkę do każdego pliku
  konfiguracyjnego (zwykle znajdują się w katalogu /etc), jednego w
  każdej linii, w pliku nazwanym <tt/conffiles/. Program gentoo ma jeden
  plik konfiguracyjny, /etc/gentoorc, zatem podamy ścieżkę do
  niego w pliku <tt/conffiles/.

  <p>Jeśli Twój program używa plików konfiguracyjnych, ale sam zmienia ich
  zawartość, to najlepiej będzie nie umieszczać ich w pliku <tt/conffiles/,
  ponieważ program dpkg będzie za każdym razem prosił użytkowników o
  weryfikację zmian.

  <p>Jeśli program, który pakujesz, wymaga od każdego użytkownika
  modyfikacji pliku konfiguracyjnego, aby w ogóle zadziałać, to również
  powinieneś zrezygnować z umieszczania go w pliku <tt>conffiles</tt>.

  <p>Przykładowe pliki konfiguracyjne możesz znaleźć w `skryptach opiekuna
  pakietu'. Więcej szczegółów na ich temat zamieszczono w sekcji
  <ref id="maintscripts">.

  <p>Jeśli Twój program nie posiada plików konfiguracyjnych, to możesz
  bez obaw wykasować plik <tt/conffiles/ z katalogu debian/.

  <sect id="crond">Plik `cron.d.ex'

  <p>Jeśli Twój pakiet do prawidłowego działania wymaga regularnie wykonywanych
  zadań, to możesz do tego celu wykorzystać właśnie plik <tt/cron.d/.

  <p>Zwróć uwagę, że to nie obejmuje zagadnień związanych z rotacją plików
  logów. Więcej informacji na ten temat znajdziesz na stronach podręcznika
  <manref name="dh_installlogrotate" section="1"> i <manref name="logrotate"
  section="8">.

  <p>Jeśli nie potrzebujesz tego pliku, usuń go.

  <sect id="dirs">Plik `dirs'

  <p>Plik ten określa katalogi, które są potrzebne, ale których normalna
  procedura instalacyjna (make install) nie tworzy.

  <p>Domyślnie plik ten wygląda następująco:

  <p><example>
  usr/bin
  usr/sbin
  </example>

  <p>Zwróć uwagę, iż przed nazwami katalogów nie występują znaki ukośników
  (`/'). Normalnie zmienilibyśmy go w następujący sposób:

  <p><example>
  usr/bin
  usr/man/man1
  </example>

  <p>ale ponieważ katalogi te są tworzone przez Makefile, to nie
  potrzebujemy pliku `dirs' i możemy go usunąć.

  <sect id="docs">Plik `docs'

  <p>Ten plik określa nazwy plików z dokumentacją, którą program dh_installdocs
  zainstaluje w tymczasowym katalogu.

  <p>Domyślnie obejmuje to także pliki istniejące już w katalogu głównym ze źródłami
  programu, takie jak "BUGS", "README*", "TODO" itp.

  <p>Dla programu gentoo dołączyłem również inne pliki:

  <p><example>
  BUGS
  CONFIG-CHANGES
  CREDITS
  ONEWS
  README
  README.gtkrc
  TODO
  </example>

  <p>Możemy też usunąć ten plik i, zamiast podawać listę plików, użyć
  ich nazw jako argumentów wejściowych dla programu <tt/dh_installdocs/
  wywoływanego w pliku <tt/rules/:

  <p><example>
        dh_installdocs BUGS CONFIG-CHANGES CREDITS ONEWS README \
                       README.gtkrc TODO
  </example>

  <p>Może się tak zdarzyć, że nie będziesz mieć żadnego z tych plików w źródłach
  Twojego pakietu. W takim przypadku możesz bezpiecznie usunąć plik <tt/docs/.
  Nie usuwaj jednak wywołania programu <tt/dh_installdocs/ z pliku <tt/rules/,
  ponieważ jest on używany również do instalacji pliku <tt/copyright/ i
  innych rzeczy.

  <sect id="emacsen">Plik `emacsen-*.ex'

  <p>Jeśli Twój pakiet zawiera pliki Emacsa, które mogą być skompilowane do
  kodu bajtowego w czasie instalacji, to możesz użyć tych plików właśnie w tym
  celu.

  <p>Pliki te są instalowane w katalogu tymczasowym przez program
  <manref name="dh_installemacsen" section="1">, zatem jeśli chcesz go wywołać,
  nie zapomnij odkomentować odpowiedniej linii w pliku <tt/rules/.

  <p>Jeśli zaś nie potrzebujesz tych plików, możesz je usunąć.

  <sect id="initd">Plik `init.d.ex'

  <p>Jeśli Twój pakiet jest demonem, który musi być uruchamiany w czasie startu
  systemu, to znaczy, że nie posłuchałeś moich zaleceń we wstępie do tego
  podręcznika, nieprawdaż? :-)

  <p>Plik ten jest prostym szablonem skryptu umieszczanego w katalogu
  <file>/etc/init.d/</file>, zatem będziesz musiał znacznie go przerobić.
  Zostanie on zainstalowany w katalogu tymczasowym przez program
  <manref name="dh_installinit" section="1">.

  <p>Jeśli nie potrzebujesz tego pliku, usuń go.

  <sect id="manpage">Pliki `manpage.1.ex', `manpage.sgml.ex'

  <p>Twój program(y) powinien mieć stronę podręcznika systemowego.
  Jeśli jeszcze jej nie ma, to możesz użyć tych plików jako szablonów.

  <p>Strony podręcznika są zwykle napisane w formacie <manref name="nroff"
  section="1">. W formacie tym napisano właśnie przykładowy plik
  <tt/manpage.1.ex/. Zobacz stronę podręcznika programu <manref name="man"
  section="7">, jest tam krótki opis, jak poprawiać tego typu pliki.

  <p>Jeśli zamiast formatu nroff wolisz pisać dokumenty w formacie SGML,
  to możesz wykorzystać szablon <tt/manpage.sgml.ex/. W takim przypadku
  musisz:

  <list>
    <item>zainstalować pakiet <package/docbook-to-man/
    <item>dopisać <tt/docbook-to-man/ do linii <tt/Build-Depends/ w pliku
          <tt/control/
    <item>usunąć znak komentarza przed wywołaniem programu docbook-to-man
      w regule `build' pliku <tt/rules/
  </list>

  <p>Pamiętaj o zmianie nazwy pliku na coś w stylu <tt/gentoo.sgml/!

  <p>Docelowa nazwa pliku ze stroną podręcznika systemowego powinna zawierać nazwę
  programu, który opisuje, zatem zmień ją z "manpage" na "gentoo".
  Nazwa tego pliku zawiera także przyrostek ".1", który mówi, że jest to
  strona z sekcji poleceń użytkownika. Upewnij się, do której sekcji powinna
  należeć strona Twojego pakietu. Poniżej zamieszczono krótką listę sekcji
  podręcznika:

  <p><example>
  Sekcja |        Opis          |          Uwagi
     1    Polecenia użytkownika   Wykonywalne komendy lub skrypty.
     2    Wywołania systemowe     Funkcje jądra systemu.
     3    Wywołania biblioteczne  Funkcje bibliotek systemowych.
     4    Pliki specjalne         Zwykle umieszczone w katalogu /dev.
     5    Formaty plików          Na przykład format pliku /etc/passwd.
     6    Gry                     Lub inne programy rozrywkowe.
     7    Pakiety makr            Takie jak makra programu man.
     8    Administracja systemem  Programy zwykle uruchamiane tylko przez administratora.
     9    Procedury jądra         Niestandardowe wywołania i procedury wewnętrzne.
  </example>

  <p>Zatem podręcznik programu gentoo powinien nazywać się <tt/gentoo.1/.
  Ponieważ w oryginalnych źródłach nie było
  strony podręcznika `gentoo.1', napisałem ją sam, używając informacji
  znalezionych w przykładach i dokumentacji dołączonej do źródeł.

  <sect id="menu">Plik `menu.ex'

  <p>Użytkownicy systemu X Window zwykle posługują się menadżerami okien,
  umożliwiającymi uruchamianie programów poprzez rozwijalne menu, które można
  dostosowywać do własnych potrzeb. Jeśli zainstalowali oni pakiet
  <package/menu/, to zostanie utworzony zestaw menu służący do
  uruchamiania programów w systemie.

  <p>Poniżej pokazano plik <tt/menu.ex/, domyślnie utworzony przez program
  dh_make:

  <p><example>
  ?package(gentoo):needs="X11|text|vc|wm" section="Apps/see-menu-manual"\
    title="gentoo" command="/usr/bin/gentoo"
  </example>

  <p>Pierwszym polem po znaku dwukropka jest pole "needs", które określa,
  jakiego rodzaju interfejsu wymaga program. Zmień je na jedną z wymienionych
  możliwości, na przykład "text" lub "X11".

  <p>Następnym polem jest "section", które mówi, w jakim menu i podmenu powinien
  znaleźć się wpis z programem gentoo. Aktualną listę sekcji można znaleźć na
  stronie <file>/usr/share/doc/debian-policy/menu-policy.html/ch2.html#s2.1</file>.

  <p>Pole "title" to nazwa programu. Jeśli chcesz, możesz rozpocząć
  ją od wielkiej litery. Powinna być krótka.

  <p>Wreszcie pole "command" to nazwa polecenia, które uruchamia program.

  <p>Po zmianach wpis do menu wygląda następująco:

  <p><example>
  ?package(gentoo): needs="X11" section="Apps/Tools" title="Gentoo" command="gentoo"
  </example>

  <p>Możesz również dodać inne pola, na przykład "longtitle", "icon",
  "hints" itd. Więcej informacji możesz znaleźć na stronach podręcznika
  <manref name="menufile" section="5">, <manref name="update-menus"
  section="1"> i w katalogu /usr/share/doc/debian-policy/menu-policy.html/.

  <sect id="watch">Plik `watch.ex'

  <p>Plik ten jest używany do konfigurowania programów <manref name="uscan"
  section="1"> i <manref name="uupdate" section="1"> (zawartych w pakiecie
  <package/devscripts/). Są one używane do sprawdzania strony internetowej,
  z której pobrałeś źródła dla swojego pakietu.

  <p>W tym pliku umieściłem:

  <p><example>
# watch control file for uscan
# Site            Directory  Pattern               Version  Script
ftp.obsession.se  /gentoo    gentoo-(.*)\.tar\.gz  debian   uupdate
  </example>

  <p>Wskazówka: połącz się z internetem i spróbuj uruchomić program "uscan"
  w katalogu, w którym stworzyłeś plik `watch'. I czytaj strony
  podręczników! :)

  <sect id="doc-base">Plik `ex.package.doc-base'

  <p>Jeśli Twój pakiet ma dokumentację w postaci innej niż strony podręcznika
  i dokumentacja przeglądana za pomocą programu "info", to powinieneś użyć
  pliku `<package/doc-base/', aby ją zarejestrować. Użytkownik będzie
  mógł ją wtedy znaleźć, na przykład za pomocą <manref name="dhelp" section="1">,
  <manref name="dwww" section="1"> lub <manref name="doccentral" section="1">.

  <p>Na ogół obejmuje to pliki HTML, PS i PDF umieszczone w katalogu
  <file>/usr/share/doc/nazwa_pakietu/</file>.

  <p>Plik <tt>gentoo.doc-base</tt> dla programu gentoo wygląda następująco:

  <p><example>
  Document: gentoo
  Title: Gentoo Manual
  Author: Emil Brink
  Abstract: This manual describes what Gentoo is, and how it can be used.
  Section: Apps/Tools

  Format: HTML
  Index: /usr/share/doc/gentoo/html/index.html
  Files: /usr/share/doc/gentoo/html/*.html
  </example>

  <p>Informacje na temat formatu tego pliku znajdziesz na stronie podręcznika
  <manref name="install-docs" section="8"> oraz w podręczniku <package/doc-base/
  (katalog <file>/usr/share/doc/doc-base/doc-base.html/</file>).

  <p>Więcej szczegółów nt. instalowania dokumentacji w sekcji <ref id="destdir">.

  <sect id="maintscripts">postinst.ex, preinst.ex, postrm.ex, prerm.ex

  <p>Pliki te są nazywane skryptami opiekuna. Umieszczone są one w obszarze
  kontrolnym pakietu i uruchamiane przez program <prgn/dpkg/, gdy Twój pakiet
  jest instalowany, uaktualniany do nowszej wersji lub usuwany.

  <p>Na razie powinieneś unikać ręcznych modyfikacji tych skryptów,
  ponieważ często są one skomplikowane. Więcej informacji znajdziesz
  w podręczniku Polityki Debiana, w rozdziale 6. Zerknij także na przykładowe
  pliki wygenerowane przez program dh_make.

  <!-- -------------------------------------------------------------------------->

  <chapt id="build">Budowanie pakietu

  <p>Teraz już powinniśmy być gotowi do zbudowania pakietu.

  <sect id="completebuild">Całkowita przebudowa

  <p>Wejdź do katalogu głównego programu i wydaj w nim polecenie:

  <p><example>
  dpkg-buildpackage -rfakeroot
  </example>

  <p>Wykona ono wszystko, to znaczy:
  <list>
    <item>wyczyści drzewo źródeł programu (debian/rules clean) używając programu <prgn/fakeroot/
    <item>zbuduje pakiet źródłowy (dpkg-source -b)
    <item>zbuduje program (debian/rules build)
    <item>zbuduje pakiet binarny (debian/rules binary), używając programu
      <prgn/fakeroot/
    <item>podpisze źródłowy plik <tt/.dsc/, używając programu <prgn/gnupg/
    <item>utworzy i podpisze umieszczany w archiwum Debiana plik <tt/.changes/
      przy pomocy programów <prgn/dpkg-genchanges/ i <prgn/gnupg/
  </list>

  <p>Będziesz musiał tylko dwukrotnie wprowadzić hasło do Twojego prywatnego
  klucza GPG.

  <p>Po zakończeniu procesu zobaczysz następujące pliki w katalogu nadrzędnym
  (<tt>~/gentoo/</tt>):

  <p><list>
  <item><em>gentoo_0.9.12.orig.tar.gz</em>

  <p>To archiwum z oryginalnym kodem źródłowym programu. Jego nazwa została
  zmieniona w powyższy sposób, aby zachować standard Debiana. Zwróć uwagę,
  że plik ten został utworzony przy użyciu opcji `-f' przez program
  <prgn/dh_make/, gdy na początku go uruchomiliśmy.

  <item><em>gentoo_0.9.12-1.dsc</em>

  <p>To jest streszczenie zawartości kodu źródłowego. Plik ten jest
  generowany na podstawie pliku `control' i używany w czasie rozpakowywania
  źródła przez program <manref name="dpkg-source" section="1">. Jest on
  podpisany cyfrowo, aby inni mogli być pewni, że jest naprawdę Twój.

  <item><em>gentoo_0.9.12-1.diff.gz</em>

  <p>Ten plik jest skompresowany i zawiera wszystkie zmiany, których dokonałeś
  w oryginalnym kodzie źródłowym. Zmiany te są zapisane w formacie znanym jako
  "unified diff". Plik jest utworzony i używany przez program
  <manref name="dpkg-source" section="1">. Uwaga: jeśli nie nazwałeś
  oryginalnego archiwum ze źródłami programu w sposób: nazwapakietu_wersja.orig.tar.gz,
  to program <prgn/dpkg-source/ nie wygeneruje poprawnego pliku .diff.gz!

  <p>Gdyby ktoś jeszcze chciał ponownie utworzyć Twój pakiet zaczynając
  procedurę od początku, to może łatwo to zrobić używając trzech
  powyższych plików. Procedura postępowania w takich przypadkach jest wręcz
  banalna: po prostu należy gdzieś skopiować te trzy pliki i wydać komendę
  <tt>dpkg-source -x gentoo_0.9.12-1.dsc</tt>.

  <item><em>gentoo_0.9.12-1_i386.deb</em>

  <p>To kompletny pakiet binarny. Możesz użyć programu <prgn/dpkg/, aby
  zainstalować go lub usunąć w taki sam sposób, jak każdy inny pakiet.

  <item><em>gentoo_0.9.12-1_i386.changes</em>

  <p>Plik ten opisuje wszystkie zmiany dokonane w obecnej poprawce pakietu.
  Używają go programy obsługi archiwów FTP Debiana do zainstalowania
  pakietów binarnych i źródłowych. Jest on częściowo generowany z plików
  `changelog' i .dsc. Plik ten jest podpisany cyfrowo, aby inni
  mogli być pewni, że jest naprawdę Twój.

  <p>W czasie, gdy będziesz się zajmował pakietem, zmieni się pewnie jego
  działanie i dodane zostaną nowe funkcjonalności. Ludzie pobierający Twój
  pakiet mogą w tym pliku szybko zobaczyć, co się zmieniło.
  Programy zarządzające archiwum Debiana wyślą również zawartość tego pliku
  na listę dyskusyjną debian-devel-changes.
  </list>

  <p>Długie łańcuchy liczb w plikach .dsc i .changes to sumy kontrolne MD5
  wspomnianych plików. Osoby pobierające Twoje pliki mogą sprawdzić je
  używając programu <manref name="md5sum" section="1"> i jeśli sumy nie będą
  się zgadzać, będą wiedzieć, że plik jest uszkodzony lub został przez kogoś
  zmieniony.

  <sect id="quickrebuild">Szybka przebudowa

  <p>Gdy masz duży pakiet, to możesz nie chcieć budować go od nowa za każdym
  razem, gdy zmienisz jakiś szczegół w pliku <file>debian/rules</file>.
  Dla celów testowych możesz stworzyć plik .deb bez przebudowywania
  źródeł programu:

  <p><example>
  fakeroot debian/rules binary
  </example>

  <p>Gdy już zakończyłeś szlifowanie Twojego pakietu, pamiętaj o
  przebudowaniu go zgodnie z powyższą, pełną procedurą. Może Ci się nie udać
  umieścić go w archiwum Debiana, gdy próbujesz zamieścić tam pliki .deb
  zbudowane w skrócony sposób.

  <sect id="debuild">Polecenie <prgn>debuild</prgn>

  <p>Możesz zautomatyzować proces budowania pakietu za pomocą polecenia
  <prgn>debuild</prgn>. Zobacz <manref name="debuild" section="1">.

  <p>Można skonfigurować działanie programu debuild poprzez pliki
  <file>/etc/devscripts.conf</file> lub <file>~/.devscripts</file>.
  Chciałbym zasugerować co najmniej:

  <p><example>
  DEBSIGN_KEYID="Your_GPG_keyID"
  DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -ICVS -I.svn"
  </example>
  W ten sposób możesz budować pakiet zawsze ze swoim kluczem GPG i bez
  niepotrzebnych komponenetów (zwłasza pomocne przy sponsoringu). Przykładowo
  czyszczenie źródeł i przebudowa pakietu z konta użytkownika jest tak
  proste:

  <p><example>
  debuild clean
  debuild
  </example>

  <sect id="dpatch">Systemy <prgn>dpatch</prgn> i <prgn>quilt</prgn>

  <p>Proste użycie <prgn>dh_make</prgn> i <prgn>dpkg-buildpackage</prgn>
  spowoduje utworzenie pojedynczego dużego pliku <file>diff.gz</file>,
  zawierającego pliki obsługujące pakiet w katalogu <file>debian/</file>
  i plików łat do źródeł. Taki pakiet jest uciążliwy podczas późniejszego
  sprawdzania dla kogoś, kto powinien zrozumieć wszystkie wprowadzane
  do źródeł zmiany. Nie jest to zbyt przyjemne
  <footnote>
  Jeśli nie jesteś jeszcze Deweloperem Debiana i prosisz swojego sponsora
  o wgranie pakietu po jego sprawdzeniu, powinieneś przygotować pakiet
  w sposób możliwie czytelny.
  </footnote>.

  <p>Zaproponowano różne matody obsługiwania łat i używa się ich w pakietach
  Debiana. Systemy <prgn>dpatch</prgn> i <prgn>quilt</prgn> są najprostszymi z nich.
  Z innych wymienimy dbs, cdbs itd.

  <p>Pakiet, który został poprawnie zbudowany za pomocą systemu
  <prgn>dpatch</prgn> lub <prgn>quilt</prgn>, posiada dobrze udokumentowane poprawki w źródłach
  jako zbiór plików łat -pl z nagłówkiem w katalogu <file>debian/patches/</file>
  i niezmienionym drzewem źródeł poza katalogiem <file>debian/</file>.
  Kiedy prosisz sponsora o wgranie Twojego pakietu, tego rodzaju wyraźne
  rozdzielenie i udokumentowanie Twoich zmian jest bardzo ważne dla
  sprawnego przejrzenia ich przez sponsora. Użycie <prgn>dpatch</prgn>
  oraz <prgn>quilt</prgn>
  jest opisane w podręcznikach <manref section="1" name="dpatch">,
  <manref section="1" name="dpatch-edit-patch">
  i <manref section="1" name="quilt">.
  Oba programy udostępniają wygodne do umieszczenia w
  <file>debian/rules</file> pliki <file>/usr/share/dpatch/dpatch.make</file> i
  <file>/usr/share/quilt/quilt.make</file>.

  <p>Kiedy ktoś (włączając Ciebie) chce wdrożyć poprawki do źródeł,
  modyfikacja pakietu jest całkiem prosta:

  <list compact>
    <item>Wyedytuj łatę, tak aby otrzymać plik -pl jako poprawkę do źródeł.
    <item>W przypadku <prgn>dpatch</prgn> dodaj nagłówek poleceniem `<tt>dpatch patch-template</tt>'.
    <item>Przenieś nagłówek do katalogu <file>debian/patches</file>.
    <item>Dodaj nazwy plików do pliku <file>debian/patches/00list</file>
        (dla <prgn>dpatch</prgn>) lub <file>debian/patches/series</file>
        (dla <prgn>quilt</prgn>).
  </list>

  <p><prgn>dpatch</prgn> posiada też możliwość wykonywania poprawek zależnych
  od architektury za pomocą makra CPP.

  <sect id="option-sa">Dołączanie <file>orig.tar.gz</file> podczas wgrywania

  <p>Kiedy pierwszy raz wgrywasz pakiet do archiwum, powinieneś załączyć
  oryginalny plik źródłowy <file>orig.tar.gz</file>. Jeśli wersja pakietu
  nie jest rewizją <tt>-0</tt> lub <tt>-1</tt>, musisz wykonać polecenie
  <prgn>dpkg-buildpackage</prgn> z opcją "<tt>-sa</tt>". Z drugiej strony
  opcja "<tt>-sd</tt>" wymusi wyłączenie oryginalnego źródła
  <file>orig.tar.gz</file>.

  <!-- -------------------------------------------------------------------------->

  <chapt id="checkit">Sprawdzanie pakietu pod kątem błędów

  <sect id="lintians">Pakiety <package>lintian</package>

  <p>Uruchom programy <manref name="lintian" section="1"> podając jako argument
  swój plik .changes. Programy ten sprawdzają pakiet pod kątem wielu
  błędów występujących podczas pakowania. Robi się to poleceniami:

  <p><example>
  lintian -i gentoo_0.9.12-1_i386.changes
  </example>

  <p>Oczywiście zastąp nazwę pliku .changes nazwą pliku wygenerowanego dla
  Twojego pakietu. Jeśli pojawią się informacje o błędach (linie rozpoczynające
  się od "E:"), to przeczytaj ich objaśnienie (linie rozpoczynające się od
  "N:"), popraw błędy i ponownie zbuduj pakiet w sposób opisany w sekcji
  <ref id="completebuild">. Linie, które zaczynają się od "W:", to ostrzeżenia.
  Oczywiście powinieneś albo coś poprawić, albo upewnić się, że nie są ważne
  (i w takim przypadku wymusić na Lintianie ich ignorowanie; wiecej szczegółów
  znajdziesz w dokumentacji).

  <p>Zwróć uwagę, że możesz w jednym kroku zbudować pakiet za pomocą programu
  <prgn>dpkg-buildpackage</prgn> i uruchomić programy <prgn/lintian/
  korzystając z narzędzia <manref name="debuild" section="1">.

  <sect id="mc">Polecenie <prgn>mc</prgn>

  <p>Możesz rozpakować zawartość pliku <file>*.deb</file> przy pomocy
  polecenia <manref name="dpkg-deb" section="1">. Możesz też zobaczyć
  zawartość utworzonego pakietu Debiana używając <manref name="debc" section="1">.

  <p>Można to również osiągnąć w sposób bardziej intuicyjny za pomocą
  managera plików np. <manref name="mc" section="1">, który pozwala
  przeglądać nie tylko zawartość pliku <file>*.deb</file>, ale również
  pliki <file>*.diff.gz</file> i <file>*.tar.gz</file>.

  <p>Zwróć przy tym uwagę na zbędne pliki o zerowej wielkości, zarówno
  binarne, jak i źródłowe. Często nie są one kasowane w sposób prawidłowy;
  popraw plik rules, tak aby usunąć tę wadę.

  <p>Porada: `<tt>zgrep ^+++ ../gentoo_0.9.12-1.diff.gz</tt>' poda
  listę Twoich zmian w plikach źródłowych, a `<tt>dpkg-deb
  -c gentoo_0.9.12-1_i386.deb</tt>' lub `<tt>debc
  gentoo_0.9.12-1_i386.changes</tt>' - listę plików w pakiecie
  binarnym.

  <sect id="debdiff">Polecenie <prgn>debdiff</prgn>

  <p>Możesz porównać listy plików w dwóch pakietach binarnych Debiana
  za pomocą polecenia <manref name="debdiff" section="1">. Jest to
  bardzo użyteczne do sprawdzenia, że żadne pliki nie zostały błędnie
  przesunięte lub wykasowane, lub też nie zostały dokonane inne
  niepożądane zmiany podczas modyfikacji pakietu. Możesz sprawdzić
  całą grupę plików <file>*.deb</file> przez wywołanie `<tt>debdiff
  old-package.change new-package.change</tt>'.

  <sect id="interdiff">Polecenie <prgn>interdiff</prgn>

  <p>Możesz porównać dwa pliki <file>diff.gz</file> za pomocą polecenia
  <manref name="interdiff" section="1">. Jest to pomocne w celu sprawdzenia,
  czy nie zostały przez nieuwagę opiekuna wprowadzone jakieś zmiany do
  plików źródłowych podczas modyfikacji pakietów. Uruchom po prostu
  `<tt>interdiff -z old-package.diff.gz new-package.diff.gz</tt>'.

  <sect id="debi">Polecenie <prgn>debi</prgn>

  <p>Zainstaluj pakiet dla przetestowania go, np. za pomocą polecenia
  <manref name="debi" section="1">, wywołanego jako root. Spróbuj zainstalować
  i uruchomić go na innych maszynach, kontrolując, czy w czasie instalacji
  lub działania nie pojawiają się komunikaty o błędach lub ostrzeżenia.

  <sect id="pbuilder">Pakiet <package>pbuilder</package>

  <p>Pakiet <package>pbuilder</package> jest bardzo użyteczny w przypadku
  weryfikacji zależności dla programów uruchamianych w tzw. środowisku
  czystej przestrzeni (chroot). Zapewnia on "czystą" budowę pakietu ze
  źródeł za pomocą auto-buildera dla różnych architektur i zapobiega
  powstawaniu szeregu błędów FTBFS (Fails To Build From Source), które
  zawsze należą do kategorii RC (release critical - krytyczne dla wydania).
  Zobacz stronę <url id="&buildd-home;"> o debianowym pakiecie auto-builder.

  <p>Najbardziej podstawowym użyciem pakietu <package>pbuilder</package>
  jest bezpośrednie wywołanie polecenia <prgn>pbuilder</prgn> jako root.
  Dla przykładu spróbuj wywołać poniższe polecenia w katalogu, gdzie
  znajdują się pliki
  <file>.orig.tar.gz</file>, <file>.diff.gz</file> i <file>.dsc</file>:
  <example>
  root # pbuilder create # za drugim razem: pbuilder update
  root # pbuilder build foo.dsc
  </example>
  Nowozbudowany pakiet znajdzie się w katalogu
  <file>/var/cache/pbuilder/result/</file>, właścicielem będzie root.

  <p>Polecenie <prgn>pdebuild</prgn> pomaga wykorzystywać fukcje
  pakietu <package>pbuilder</package> z konta zwykłego użytkownika.
  Z katalogu źródeł pakietu, gdzie w katalogu nadrzędnym znajduje się
  plik <file>orig.tar.gz</file>, wykonaj polecenia:
  <example>
  $ sudo pbuilder create # za drugim razem: sudo pbuilder update
  $ pdebuild
  </example>
  Nowozbudowany pakiet znajdzie się w katalogu
  <file>/var/cache/pbuilder/result/</file>, właścicielem będzie użytkownik (nie-root)
  <footnote>
  W chwili obecnej zalecam dostosowanie systemu przez umożliwienie zapisu
  w katalogu <file>/var/cache/pbuilder/result/</file> przez użytkowników
  i dodanie w pliku <file>~/.pbuilderrc</file> lub <file>/etc/pbuilderrc</file>
  wpisu
  <example>
  AUTO_DEBSIGN=yes
  </example>
  Pozwoli to na podpisywanie tworzonych pakietów Twoim kluczem GPG z pliku
  <file>~/.gnupg/</file>. Ponieważ pakiet <package>pbuilder</package>
  jest ciągle rozwijany, sprawdź w jego bieżącej dokumentacji, w jaki sposób
  powinieneś go skonfigurować.
  </footnote>.

  <p>Jeśli chcesz dodać nowe źródło apta, tak aby było używane przez
  pakiet <package>pbuilder</package>, ustaw <tt>OTHERMIRROR</tt> w
  <file>~/.pbuilderrc</file> lub
  <file>/etc/pbuilderrc</file> i wykonaj (dla sarge):
  <example>
  $ sudo pbuilder update --distribution sarge --override-config
  </example>
  Użycie <tt>--override-config</tt> jest konieczne do zaktualizowania
  źródeł apt w środowisku chroot.

  <p>Zobacz <url id="&pbuilder-home;">,
  <manref section="1" name="pdebuild">,
  <manref section="5" name="pbuilderrc"> i
  <manref section="8" name="pbuilder">.

  <!-- -------------------------------------------------------------------------->

  <chapt id="upload">Wgrywanie pakietu

  <p>Gdy już gruntownie przetestowałeś swój nowy pakiet, jesteś gotowy,
  aby wziąć udział w procesie przyjmowania do Debiana nowego opiekuna pakietów.
  Jest to opisane na stronie
  <url id="http://www.debian.org/devel/join/newmaint">.

  <sect id="upload-debian">Wgrywanie pakietu do archiwum Debiana

  <p>Gdy już zostałeś oficjalnym deweloperem, powinieneś umieścić swój
  pakiet w archiwum Debiana. Możesz zrobić to ręcznie, ale łatwiej jest użyć
  specjalnie do tego celu stworzonych narzędzi, które automatyzują cały
  proces. Należą do nich takie programy, jak <manref name="dupload"
  section="1"> i <manref name="dput" section="1">. Opiszemy tutaj, w jaki
  sposób posługiwać się programem <prgn/dupload/.

  <p>Pierwszą rzeczą, którą powinieneś zrobić, jest edycja jego pliku
  konfiguracyjnego. Możesz wyedytować zarówno przeznaczony dla całego systemu
  plik <file>/etc/dupload.conf</file>, jak i swój własny plik
  <file>~/.dupload.conf</file>, który nadpisuje te rzeczy, które chcesz
  zmienić. Umieść w nim coś takiego:

  <p><example>
  package config;

  $default_host = "anonymous-ftp-master";

  $cfg{'anonymous-ftp-master'} = {
        fqdn => "ftp-master.debian.org",
        method => "ftp",
        incoming => "/pub/UploadQueue/",
        # files pass on to dinstall on ftp-master which sends emails itself
        # pliki przekazywane do dinstall na ftp-master, które wysyłają maile
        dinstall_runs => 1,
  };

  1;
  </example>

  <p>Możesz przeczytać stronę podręcznika <manref name="dupload.conf" section="5">,
  aby zrozumieć, co oznacza każda z użytych opcji.

  <p>Uwagi wymaga zmienna $default_host -- określa ona, która z kolejek
  służących do umieszczania pakietów jest używana domyślnie. Główną kolejka
  jest "anonymous-ftp-master", ale możliwe jest, że będziesz chciał użyć innej,
  szybszej. Więcej informacji na temat kolejek znajdziesz
  w dokumencie Developers' Reference, w sekcji "Uploading a package",
  która znajduje się w dokumencie <file>&uploading;</file>.

  <p>Następnie połącz się z internetem i wydaj polecenie:

  <p><example>
  dupload gentoo_0.9.12-1_i386.changes
  </example>

  <p>Program <prgn/dupload/ sprawdzi, czy zgadzają się sumy kontrolne MD5 plików
  z sumami zapisanymi w pliku .changes. Jeśli sumy kontrolne pasują do siebie,
  pakiet może być umieszczony w archiwum. Jeśli sumy się nie zgadzają,
  zostaniesz ostrzeżony, aby móc przebudować pakiet zgodnie z procedurą
  opisaną w rozdziale <ref id="completebuild">.

  <p>Jeśli stwierdzisz jakiś problem z wgrywaniem w kolejce
  <url id="&ftp-uploadqueue;">,
  możesz naprawić go ręcznie poprzez wgranie podpisanego pliku
  <file>*.commands</file> do <url id="&ftp-uploadqueue;"> za pomocą programu
  <prgn>ftp</prgn>
  <footnote>
  Zobacz <url id="&ftp-command;">. Możesz też użyć programu
  <prgn>dcut</prgn> z pakietu <package>dput</package>.
  </footnote>.
  Przykładowy plik <file>hello.commands</file>:

<example>
-----BEGIN PGP SIGNED MESSAGE-----

Uploader: Roman Hodek &lt;Roman.Hodek@informatik.uni-erlangen.de&gt;
Commands: 
 rm hello_1.0-1_i386.deb
 mv hello_1.0-1.dsx hello_1.0-1.dsc

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia

iQCVAwUBNFiQSXVhJ0HiWnvJAQG58AP+IDJVeSWmDvzMUphScg1EK0mvChgnuD7h
BRiVQubXkB2DphLJW5UUSRnjw1iuFcYwH/lFpNpl7XP95LkLX3iFza9qItw4k2/q
tvylZkmIA9jxCyv/YB6zZCbHmbvUnL473eLRoxlnYZd3JFaCZMJ86B0Ph4GFNPAf
Z4jxNrgh7Bc=
=pH94
-----END PGP SIGNATURE-----
</example>
  
  <sect id="upload-private">Wgrywanie do prywatnego archiwum

  <p>Jeśli chcesz utworzyć swoje prywatne archiwum na stronie
  <tt>URL="http://people.debian.org/~<var>account_name</var>"</tt> jako 
  deweloper, a potem w prosty sposób wywoływać
  <tt>dupload -t <var>target_name</var></tt>, powinieneś dodać następujące linie 
  do pliku <file>/etc/dupload.conf</file>:

  <example>
# Developer account
$cfg{'<var>target_name</var>'} = {
        fqdn =&gt; "people.debian.org",
        method =&gt; "scpb",
        incoming =&gt; "/home/<var>account_name</var>/public_html/package/",
        # I do not need to announce
        dinstall_runs =&gt; 1,
};
$cfg{'<var>target_name</var>'}{preupload}{'changes'} = "
        echo 'mkdir -p public_html/package' | ssh people.debian.org  2&gt;/dev/null ; 
        echo 'Package directory created!'";

$cfg{'<var>target_name</var>'}{postupload}{'changes'} = "
        echo 'cd public_html/package ;
        dpkg-scanpackages . /dev/null &gt;Packages || true ;
        dpkg-scansources . /dev/null &gt;Sources || true ;
        gzip -c Packages >Packages.gz ;
        gzip -c Sources &gt;Sources.gz ' | ssh people.debian.org  2&gt;/dev/null ;
        echo 'Package archive created!'";

  </example>

  Tutaj archiwum APT jest budowane poprzez szybkie i nie sprawdzane
  zdalne wywołanie powłoki przez SSH. Nadpisywane pliki wymagane przez
  <prgn>dpkg-scanpackages</prgn> i <prgn>dpkg-scansources</prgn>
  są podstawiane przez <file>/dev/null</file>. Technika ta może być stosowana
  przez nie-deweloperów Debiana do wprowadzania ich pakietów na ich
  osobiste strony internetowe. Można też używać <prgn>apt-ftparchive</prgn>
  albo innych skryptów do tworzenia archiwów APT.

  <!-- -------------------------------------------------------------------------->

  <chapt id="update">Aktualizacja pakietu

  <sect id="newrevision">Nowa poprawka Debiana

  <p>Powiedzmy, że do Twojego pakietu został zgłoszony raport o błędzie o
  numerze #54321, opisujący problem, który możesz rozwiązać. Aby stworzyć
  nową poprawkę (revision) pakietu Debiana, musisz wykonać następujące
  czynności:

  <list>

  <item>Oczywiście najpierw popraw błąd w źródłach pakietu.

  <item>Dodaj nową poprawkę na początku pliku `changelog', na przykład za
  pomocą `<tt>dch -i</tt>` lub wręcz
  `<tt>dch -v &lt;wersja&gt;-&lt;rewizja&gt;</tt>'
  i za pomocą ulubionego edytora tekstu wstaw komentarze.
  <p>Porada: w jaki sposób najłatwiej pobrać datę w wymaganym formacie?
  Użyj komendy `<tt>822-date</tt>' lub `<tt>date -R</tt>'.

  <item>Dołącz krótki opis błędu i jego rozwiązania do pliku `changelog'
  oraz napis: "Closes: #54321". W ten sposób raport o błędzie zostanie
  automatycznie "zamknięty" przez oprogramowanie obsługujące archiwum
  Debiana w chwili, gdy pakiet zostanie w nim zaakceptowany.

  <item>Powtórz kroki wykonywane w rozdziałach <ref id="completebuild">,
  <ref id="checkit"> i <ref id="upload">. Jedyną różnicą będzie to, 
  że nie zostaną wgrane oryginalne źródła, gdyż nie zmieniły się i
  znajdują się już w archiwum Debiana.

  </list>

  <sect id="newupstream">Nowe wydanie autorskie (prosto)

  <p>Rozważmy teraz trochę inną, troszkę bardziej skomplikowaną sytuację
  - została wydana nowa, zewnętrzna wersja programu i oczywiście chcemy
  ją zapakować. Trzeba wykonać następujące czynności:

  <list>

  <item>Pobierz archiwum z nowymi źródłami (na przykład
  `<file>gentoo-0.9.13.tar.gz</file>') i umieść je w katalogu nadrzędnym
  do katalogu ze starym drzewem źródeł (dla przykładu <file>~/gentoo/</file>).

  <item>Wejdź do katalogu ze starymi źródłami i wykonaj:
  <example>
  uupdate -u gentoo-0.9.13.tar.gz
  </example>
  <p>Oczywiście musisz zastąpić nazwę pliku nazwą archiwum ze źródłami Twojego
  programu. Program <manref name="uupdate" section="1"> odpowiednio zmieni
  nazwę tego archiwum, spróbuje nałożyć wszystkie zmiany z Twojego poprzedniego
  pliku <file>.diff.gz</file> i uaktualni plik <file>debian/changelog</file>.

  <item>Zmień katalog na `<file>../gentoo-0.9.13</file>', czyli drzewo z nowym
  źródłem pakietu i powtórz to, co robiłeś w rozdziałach <ref id="completebuild">,
  <ref id="checkit"> i <ref id="upload">.

  </list>
  
  <p>Zauważ, że jeśli skonfigurowałeś plik `<file>debian/watch</file>', jak to
  opisano w sekcji <ref id="watch">, to możesz uruchomić program <manref name="uscan"
  section="1">, aby automagicznie odszukiwać poprawione źródła, pobierać je
  i uruchamiać program <prgn>uupdate</prgn>.

  <sect id="newupstream-real">Nowe wydanie autorskie (realistycznie)

  <p>Kiedy przygotowujesz pakiety dla archiwum Debiana, musisz szczegółowo
  sprawdzać rezultaty swoich działań. Przedstawiam poniżej bardziej realistyczny
  przykład takiej procedury.

  <enumlist compact>

  <item>Sprawdź zmiany w źródłach zewnętrznych

  <list compact>

  <item>Przeczytaj autorskie pliki <file>changelog</file>, <file>NEWS</file>
  i inną dokumentację, która może się odnosić do nowej wersji.

  <item>Wykonaj `<tt>diff -urN</tt>' pomiędzy starymi i nowymi źródłami
  autorskimi, aby zapoznać się z dokonanymi zmianami (a które mogą
  powodować potencjalne błędy), miej oczy otwarte na wszystko, co
  wygląda podejrzanie.

  </list>

  <item>Zaadaptuj stary pakiet do nowej wersji.

  <list compact>

  <item>Rozpakuj archiwum źródłowe i zmień nazwę jego głównego katalogu na
  <file>&lt;nazwa_pakietu&gt;-&lt;wersja_autora&gt;/</file> i przejdź
  `<tt>cd</tt>' do tego katalogu.

  <item>Skopiuj archiwum źródłowe w katalogu nadrzędnym z nową nazwą
  <file>&lt;nazwa_pakietu&gt;_&lt;wersja_autora&gt;.orig.tar.gz</file> .

  <item>Wykonaj takie same czynności na nowych źródłach, jakie wykonałeś
  na starych. Są możliwe następujące sposoby:
  
  <list compact>
  <item>polecenie `<tt>zcat <var>/path/to/</var>&lt;nazwa_pakietu&gt;_&lt;stara_wersja&gt;.diff.gz | patch -p1</tt>'
  <item>polecenie `<prgn>uupdate</prgn>'
  <item>polecenie `<tt>svn merge</tt>', jeśli źródła są w repozytorium Subversion lub
  <item>po prostu przekopiuj katalog <file>debian/</file> ze starych źródeł,
  jeśli były spakowane przy pomocy <package>dpatch</package> lub <package>quilt</package>.
  </list>

  <item>Zachowaj stare wpisy w pliku changelog (wydaje się oczywiste, ale
  różnie to bywa...)

  <item>Nowa wersja pakietu będzie miała numer autorski uzupełniony przez
  <tt>-1</tt> - numer rewizji Debiana, np. `<tt>0.9.13-1</tt>'.

  <item>Dodaj wpis "New upstream release" na początku pliku
  <file>debian/changelog</file>. Możesz to zrobić np. przez wywołanie
  `<tt>dch -v 0.9.13-1</tt>'.

  <item>Zwięźle opisz (po angielsku oczywiście <em>[uwaga tłumacza]</em>) zmiany dokonane
  <em>w</em> nowej wersji autorskiej, które naprawiają zgłoszone błędy i zamknij
  te zgłoszenia w pliku changelog.

  <item>Zwięźle opisz zmiany dokonane przez opiekuna <em>odnoszące się do</em>
  nowej wersji autorskiej, które naprawiają zgłoszone błędy i zamknij zgłoszenia.

  <item>Jeśli poprawka (patch/merge) nie może być zaaplikowana w sposób bezpośredni,
  zbadaj sytuację, żeby stwierdzić jaka jest przyczyna powstawania trudności
  (na podstawie wpisów w plikach <file>.rej</file>). W większości przypadków
  problem polega na tym, że poprawka została uwzględniona przez autora
  i nie jest już potrzebna.

  <item>Aktualizacja do nowej wersji powinna przebiegać w sposób nieabsorbujący
  użytkownika (użytkownicy nie powinni zauważać tego faktu, poza stwierdzeniem,
  że błędy zostały poprawione lub dodano nowe funkcje)
  <footnote>
  Proszę przygotować również prawidłową aktualizację pliku konfiguracyjnego
  Twojego pakietu za pomocą dobrze napisanych skryptów <prgn>postinst</prgn>
  itp., tak aby <strong>nie</strong> działy się rzeczy zaskakujące użytkowników!
  To m. in. jest jednym z czynników, <strong>dla których</strong> ludzie
  wybierają Debiana.
  <p>Jeśli rzeczywiście istnieje konieczność ręcznej interwencji (np.
  konfiguracja dla różnych katalogów domowych o całkowicie odmiennej
  strukturze), pomyśl o domyślnym skonfigurawaniu pakietu w sposób
  najbardziej bezpieczny (np. przez wyłączenie usługi) i przygotowaniu
  właściwej dokumentacji (pliki <file>README.Debian</file> i
  <file>NEWS.Debian</file>), jako ostateczność. Nie zajmuj jednak
  użytkownika komunikatami debconfa.
  </footnote>.

  <item>Jeśli z jakiegoś powodu trzeba dodać skasowane wcześniej
  pliki szablonów, możesz uruchomić program <prgn>dh_make</prgn> w już
  wcześniej "zdebianizowanym" katalogu z opcją <tt>-o</tt>, a następnie
  uważnie je wyedytować.

  <item>Uprzednio istniejące zmiany Debiana powinny zostać ponownie wprowadzone;
  odrzuć poprawki, które zostały już zostały uwzględnione (w ten czy inny sposób)
  przez autora zewnętrznego, ale pamiętaj o tych pozostałych, aż do chwili, kiedy
  naprawdę przestaną być potrzebne.

  <item>Jeśli były jakieś zmiany w systemie budującym (mam nadzieję, że wiesz
  o tym z kroku 1.), popraw plik <file>debian/rules</file> i,
  jeśli to konieczne, zależności w pliku <file>debian/control</file>.

  </list>

  <item>Zbuduj nowy pakiet jak w rozdziale <ref id="debuild"> lub
  <ref id="pbuilder">. Użycie pakietu <package>pbuilder</package> jest
  wskazane.

  <item>Sprawdź, czy nowe pakiety zostały zbudowane w sposób prawidłowy.

  <list compact>

  <item>Przeprowadź <ref id="checkit">.

  <item>Wykonaj <ref id="upgrading">.

  <item>Sprawdź ponownie, czy nie ma poprawionych błędów otwartych w
  <url name="Debian Bug Tracking System (BTS)" id="http://www.debian.org/Bugs/">.

  <item>Sprawdź zawartość pliku .changes i upewnij się, że wgrywasz zmiany
  do odpowiedniej dystrybucji, zostały ujęte właściwe zgłoszenia błędów
  w polu Closes:, pola Maintainer: i Changed-By: są prawidłowe, istnieje
  podpis GPG itp.

  </list>

  <item>Jeśli wykonywałeś jakieś zmiany, aby coś poprawić, wróć do kroku
  2., aż do osiągnięcia pozytywnego rezultatu.

  <item>Jeśli wgrywanie odbywa się przez sponsora, odnotuj wszelkie dodatkowe
  opcje wymagane do zbudowania pakietu (np. '<tt>dpkg-buildpackage
  -sa -v ...</tt>') i poinformuj o nich sponsora, tak aby mógł również
  prawidłowo go zbudować.

  <item>Jeśli sam wykonujesz wgrywanie, przeprowadź <ref id="upload">.

  </enumlist>

  <sect id="orig-tar">Plik <file>orig.tar.gz</file>

  <p>Jeśli próbujesz zbudować pakiet tylko z nowego katalogu źródłowego
  z podkatalogiem <file>debian/</file> bez pliku <file>orig.tar.gz</file>
  w katalogu nadrzędnym, zakończy się to utworzeniem
  pakietu źródłowego, bez powstania pliku <file>diff.gz</file>.
  Taki sposób pakowania jest prawidłowy jedynie dla specyficznych
  pakietów Debiana, które są bezużyteczne w innych dystrybucjach.

  <footnote>
  Niektórzy twierdzą, że nawet dla specyficznych pakietów Debiana jest
  lepszą praktyką przechowywanie zawartości katalogu <file>debian/</file>
  w pliku <file>diff.gz</file>, niż w <file>orig.tar.gz</file>.
  </footnote>

  <p>W celu uzyskania nie-natywnego pakietu źródłowego, który pozwala na
  uzyskanie zarówno pliku <file>orig.tar.gz</file> jak i <file>diff.gz</file>,
  musisz ręcznie skopiować archiwum autorskie do katalogu nadrzędnego i
  zmienić jego nazwę na
  <file>&lt;nazwa_pakietu&gt;_&lt;wersja_autorska&gt;.orig.tar.gz</file>, jak
  zrobił to program <prgn>dh_make</prgn> w rozdziale <ref id="dh_make">.

  <sect id="cvs-buildpackage">Polecenie <prgn>cvs-buildpackage</prgn> i jemu podobne

  <p>Rozważ użycie systemu zarządzania kodem źródłowym do zarządzania plikami
  zmienianymi w czasie pakowania. Jest kilka skryptów do pakowania przystosowanych
  do najbardziej popularnych z nich.
  <list compact>
  <item>CVS
  <list compact>
  <item><package>cvs-buildpackage</package>
  </list>
  <item>Subversion
  <list compact>
  <item><package>svn-buildpackage</package>
  </list>
  <item>Git (git-core)
  <list compact>
  <item><package>git-buildpackage</package>
  </list>
  </list>

  <p>Polecenia te automatyzują też pakowanie nowych wydań autorskich.

  <sect id="upgrading">Weryfikowanie uaktualnienia pakietu do nowszej wersji

  <p>Kiedy już zbudowałeś nową wersję pakietu, powinieneś wykonać następującą
  procedurę, żeby upewnić się, że aktualizacja pakietu do nowej wersji
  przebiega bezbłędnie:

  <p><list>
  <item>uaktualnij pakiet z poprzedniej wersji
  <item>powróć ponownie do poprzedniej wersji (downgrade), a następnie usuń go
  <item>zainstaluj pakiet jako nowy pakiet
  <item>odinstaluj go i następnie zainstaluj ponownie
  <item>wyczyść (purge) pakiet
  </list>

  <p>Jeśli pakiet zawiera nietrywialne skrypty pre/post/inst/rm, przetestuj
  ścieżki działania każdego z nich.

  <p>Miej świadomość, że jeśli Twój pakiet był poprzednio wydany w Debianie,
  to ludzie często będą go uaktualniać z wersji, która była w ostatnim wydaniu
  Debiana. Pamiętaj, żeby przetestować także uaktualnianie do nowszej wersji
  z tamtej wersji.

  <!-- -------------------------------------------------------------------------->

  <chapt id="helpme">Gdzie prosić o pomoc

  <p>Zanim zdecydujesz się zadać pytanie w jakimś publicznym miejscu,
  proszę najpierw zajrzeć do odpowiedniego podręcznika. Dokumentacja do
  programów wymienionych w tym dokumencie znajduje się w
  <file>/usr/share/doc/dpkg</file>,
  <file>/usr/share/doc/debian</file>, <file>&autotools-dev;</file>, 
  <file>/usr/share/doc/package/*</file>, a także w plikach info i man
  omawianych programów.
  Zobacz też inforamcje na <url id="&nm-home;"> i <url id="&mentors-faq;">.

  <p>Jeśli masz pytanie na temat pakowania, na które nie znalazłeś odpowiedzi
  w powyższej dokumentacji, powinieneś je zadać na liście Mentorów Debiana,
  która dostępna jest pod adresem <email/debian-mentors@lists.debian.org/.
  Bardziej doświadczeni deweloperzy Debiana chętnie Ci pomogą, ale przed
  zadaniem pytania przeczytaj dokumentację!

  <p>Więcej informacji na temat tej listy dyskusyjnej znajdziesz na stronie
  <url id="http://lists.debian.org/debian-mentors/">.

  <p>Kiedy odbierzesz raport o błędzie (tak, prawdziwy raport o błędzie!),
  to znak, że czas zaznajomić się z <url name="Systemem śledzenia błędów
  Debiana (BTS)" id="http://www.debian.org/Bugs/"> i przeczytać znajdującą się
  tam dokumentację, aby móc sprawnie radzić sobie z takimi raportami.
  Polecam głównie przeczytanie rozdziału "Handling Bugs" z dokumentu
  Developers' Reference w <file>&bughandling;</file>.

  <p>Jeśli wciąż masz pytania, pytaj na liście Deweloperów Debiana,
  która jest dostępna pod adresem <email/debian-devel@lists.debian.org/.
  Więcej informacji na temat tej listy dyskusyjnej znajdziesz na stronie
  <url id="http://lists.debian.org/debian-devel/">.

  <p>Nawet, gdy wszystko działa dobrze, to czas, żeby zacząć się modlić.
  Dlaczego? Ponieważ już za kilka godzin (lub dni) użytkownicy z całego świata
  zaczną używać Twojego pakietu i jeśli popełniłeś jakiś krytyczny błąd,
  wielu rozgniewanych użytkowników Debiana zasypie Cię listami...
  To tylko żart. :-)

  <p>Zrelaksuj się i bądź gotowy na raporty o błędach, ponieważ masz jeszcze sporo
  do zrobienia, zanim Twój pakiet będzie w pełni zgodny z Polityką
  Debiana (powtarzam: przeczytaj <em>prawdziwą dokumentację</em>,
  aby dowiedzieć się więcej szczegółów). Powodzenia!

  <!-- -------------------------------------------------------------------------->

  <appendix id="pkg-eg">Przykłady

  <p>Mamy do zapakowania archiwum autorskie <var>gentoo-1.0.2</var>.tar.gz i
  wgrywamy wszystkie pakiety do <tt><var>nm_target</var></tt>.

  <sect id="pkg-simple">Prosty przykład pakowania

  <p>
  <example>
  $ mkdir -p <var>/path/to</var> # nowy pusty katalog
  $ cd <var>/path/to</var>
  $ tar -xvzf <var>/path/from/gentoo-1.0.2</var>.tar.gz # rozpakowujemy źródła
  $ cd <var>gentoo-1.0.2</var>
  $ dh_make -e <var>name@domain.dom</var> -f <var>/path/from/gentoo-1.0.2</var>.tar.gz
  ... Odpowiedz na pytania
  ... Popraw drzewo źródeł
  ... Jeśli jest to pakiet skryptowy, wpisz "Architecture: all" do debian/control
  ... Nie kasuj ../<var>gentoo_1.0.2</var>.orig.tar.gz
  $ debuild
  ... Nie powinno być ostrzeżeń
  $ cd ..
  $ dupload -t <var>nm_target</var> <var>gentoo_1.0.2-1</var>_i386.changes
  </example>


  <sect id="pkg-dpatch">Przykład z <package>dpatch</package> i <package>pbuilder</package>
  <p>
  <example>
  $ mkdir -p <var>/path/to</var> # nowy pusty katalog
  $ cd <var>/path/to</var>
  $ tar -xvzf <var>/path/from/gentoo-1.0.2</var>.tar.gz
  $ cp -a  <var>gentoo-1.0.2</var> <var>gentoo-1.0.2-orig</var>
  $ cd <var>gentoo-1.0.2</var>
  $ dh_make -e <var>name@domain.dom</var> -f /path/from/<var>gentoo-1.0.2</var>.tar.gz
  ... Odpowiedz na pytania
  </example>

  Tu mamy fragment oryginalnego pliku <file>debian/rules</file>:
  <example>
  configure: configure-stamp
  configure-stamp:
        dh_testdir
        # Add here commands to configure the package.
        touch configure-stamp
  build: build-stamp
  build-stamp: configure-stamp 
        dh_testdir
        # Add here commands to compile the package.
        $(MAKE)
        #docbook-to-man debian/gentoo.sgml > gentoo.1
        touch $@
  clean:
        dh_testdir
        dh_testroot
        rm -f build-stamp configure-stamp
        # Add here commands to clean up after the build process.
        -$(MAKE) clean
        dh_clean 
  </example>
  Za pomocą edytora zmień <file>debian/rules</file> w następujący sposób,
  tak aby używać <package>dpatch</package> oraz dodaj <package>dpatch</package>
  w linii <tt>Build-Depends:</tt> pliku <file>debian/control</file>:
  <example>
  configure: configure-stamp
  configure-stamp: patch
        dh_testdir
        # Add here commands to configure the package.
        touch configure-stamp
  build: build-stamp
  build-stamp: configure-stamp 
        dh_testdir
        # Add here commands to compile the package.
        $(MAKE)
        #docbook-to-man debian/gentoo.sgml > gentoo.1
        touch $@
  clean: clean-patched unpatch
        dh_testdir
        dh_testroot
        rm -f build-stamp configure-stamp
        # Add here commands to clean up after the build process.
        -$(MAKE) clean
        dh_clean 
  patch: patch-stamp
  patch-stamp:
        dpatch apply-all
        dpatch call-all -a=pkg-info >patch-stamp
  unpatch:
        dpatch deapply-all
        rm -rf patch-stamp debian/patched
  </example>

  <p>W ten sposób możesz już pakować źródła za pomocą systemu
  <package>dpatch</package> używając programu <prgn>dpatch-edit-patch</prgn>.

  <example>
  $ dpatch-edit-patch patch 10_firstpatch
  ... Popraw źródła edytorem
  $ exit 0
  ... Spróbuj zbudować pakiety przy użyciu "debuild -us -uc"
  ... Wyczyść źródła wywołując "debuild clean"
  ... Powtarzaj dpatch-edit-patch aż do zbudowania pakietów ze źródeł
  $ sudo pbuilder update
  $ pdebuild
  $ cd /var/cache/pbuilder/result/
  $ dupload -t <var>nm_target</var> <var>gentoo_1.0.2-1</var>_i386.changes
  </example>

 </book>

</debiandoc>