#use wml::debian::template title="System pakietów Debiana" NOHEADER="yes"

System pakietów Debiana

Autor: Piotr Roszatycki

Artykuł wyjaśnia zasadę działania systemu pakietów Debiana oraz opisuje budowę pakietów binarnych, źródłowych i dystrybucyjnych. Zawarte w nim informacje szczególnie przydadzą się osobom tworzącym własne pakiety oraz administratorom systemu pragnącym poznać znaczenie plików systemowych. Niektóre wskazówki mogą się także przydać zwykłemu użytkownikowi, który chciałby umieć odczytywać informacje zawarte w pakietach Debiana.

Administrowanie systemem wyposażonym w dużą ilość oprogramowania nie jest proste. Instalacja dodatkowego lub aktualizacja wcześniej zainstalowanego oprogramowania dokonywana w tradycyjny sposób, czyli przez rozpakowanie i kompilowanie, pochłania dużo czasu i nakładów pracy. Nierzadko problemem jest także wykonanie zmian w oryginalnych źródłach, tak aby dostosować dany program do konkretnej instalacji systemu. Usuwanie oprogramowania bywa nawet bardziej kłopotliwe od instalacji - oprócz samych plików binarnych czy bibliotek należy także skasować pliki konfiguracyjne itd. Pół biedy, jeśli wiemy gdzie się znajdują. W przeciwnym razie skazani jesteśmy na przeszukiwanie drzewa katalogów. Innym źródłem problemów mogą być wymagania systemowe nowego oprogramowania. Przed zainstalowaniem nowego programu należy upewnić się, czy niczego mu nie brakuje - bibliotek, dodatkowych programów itd.

Wystarczy sprawdzić ilość plików znajdujących się w katalogu /usr/bin, aby uzmysłowić sobie jak wiele czasu może zająć chociażby aktualizacja tych wszystkich programów. Nieocenioną pomocą administratora wielu systemów jest system pakietów, który automatyzuje większość czynności związanych z zarządzaniem oprogramowaniem.

Rozbicie systemu na integralne części stworzyło potrzebę przechowywania jego elementów w osobnych archiwach. Archiwum plików wraz z dodatkowymi informacjami o tworzą pakiet. O rodzaju tych informacji oraz sposobie ich wykorzystania decyduje system pakietów. W najprostszym przypadku system taki po prostu zainstaluje archiwum plików w systemie lub skasuje te pliki, których ścieżka pokrywa się ze ścieżką plików z archiwum. W praktyce takie rozwiązanie nie różni się zbytnio od działania narzędzi typu tar lub ar. Ale w pakiecie przechowuje się także dodatkowe informacje, m.in. opis danego pakietu, wymagania systemowe, skrypty do wykonania przed/po instalacji samego archiwum plików, sumy kontrolne itd.

Narzędzia systemu pakietów mogą udostępniać szereg dodatkowych usług, od pobrania pakietu z odległego serwera FTP, aż po sprawdzanie integralności zainstalowanych w systemie plików danego pakietu.

Koncepcja systemu pakietów Debiana

Zdecydowana większość dystrybucji Linuksa, a także niektóre inne systemy operacyjne (m.in. FreeBSD), posiada jakiś system pakietów. Oryginalny system stworzony na potrzeby dystrybucji Debian jest rozwijany od pięciu lat, choć sama ogólna zasada działania uległa niewielkim zmianom.

Koncepcja systemu pakietów Debiana opiera się na kilku założeniach:

Pakiet binarny (*.deb)

Podstawę dystrybucji Debiana stanowi pakiet binarny, czyli plik *.deb. Do niewątpliwych zalet korzystania z pakietów binarnych należy prosta instalacja pakietu oraz późniejsza aktualizacja czy usunięcie. Twórcy pakietów binarnych starannie testują ich działanie, można więc mieć gwarancję, że dany pakiet będzie funkcjonować poprawnie także w naszym systemie, a ewentualne problemy można śmiało zgłaszać autorowi jako błąd.

Z drugiej strony, uzależnienie się od tej formy archiwum dystrybucyjnego wiąże się z koniecznością dbania o porządek w systemie pakietów, co w praktyce oznacza konieczność korzystania z oryginalnych pakietów. W przypadku zaistnienia konieczności dokonania zmian w oryginalnym pakiecie, zmuszeni jesteśmy do samodzielnego przygotowania pakietu binarnego, co może być bardziej uciążliwe od tradycyjnej metody instalacji oprogramowania. Dochodzą do tego problemy z koniecznością posiadania w systemie bibliotek o konkretnych wersjach. Mimo to jednak korzyści płynące ze stosowania pakietów binarnych warte są wysiłku włożonego w zachowanie spójności systemu pakietów.

Format pliku *.deb jest zgodny z formatem archiwum programu ar. Oznacza to, że do rozpakowania pliku *.deb można wykorzystać polecenie ar x nazwa-pliku.deb, co niekiedy przydaje się, gdy w systemie brakuje polecenia dpkg. Archiwum składa się z kilku części zwanych członkami archiwum. Pierwszym członkiem archiwum jest plik debian-binary zawierający numer wersji formatu archiwum. Obecnie jest to format 2.0, co można sprawdzić poleceniem file nazwa-pliku.deb.

Kolejnym elementem pliku *.deb jest archiwum kontrolne control.tar.gz. Ponieważ znajduje się ono na początku pliku pakietu, tuż za numerem wersji, aby pobrać informacje o tym pakiecie wystarczy odczytać początek pakietu.

Niektóre pliki tego archiwum są rozpoznawane przez program dpkg lub inne programy. Część z nich jest opcjonalna.

control
Najważniejszy plik w archiwum kontrolnym. Informacje o pakiecie zawarte są w formie pliku tekstowego w formacie kontrolnym. Plik tworzony jest zwykle na podstawie pliku debian/control z pakietu źródłowego za pomocą narzędzi dpkg-gencontrol oraz dpkg-shlibdeps.

Tylko ten plik jest wymagany (obecność pozostałych jest opcjonalna). Możliwe jest także umieszczanie własnych rozszerzeń w postaci nowych plików archiwum kontrolnego.

preinst
Program wykonywany przed rozpakowaniem pakietu binarnego i zainstalowaniem jego plików w systemie. Najczęściej służy do zatrzymania uruchomionych usług związanych z pakietem na czas aktualizacji.

postinst
Program wykonywany po zainstalowaniu pakietu w systemie, podczas konfiguracji. W tym czasie użytkownik może zostać zapytany o szczegółowe ustawienia i tym samym wpłynąć na późniejsze funkcjonowanie pakietu. Skrypt postinst wykonuje także czynności niezbędne do poprawnego działania pakietu (np. polecenie ldconfig dla pakietu z bibliotekami) lub uruchamia dany serwis wywołując odpowiedni skrypt z katalogu /etc/init.d.

prerm
Program wykonywany przed usunięciem pakietu lub jego aktualizacją. Zwykle zatrzymuje uruchomione usługi związane z pakietem.

postrm
Program wykonywany po zakończeniu usuwania lub czyszczenia pakietu. W zależności od sytuacji, program może usunąć dodatkowe katalogi czy pliki wykorzystywane przez ten pakiet, a które po jego usunięciu będą zbędne w systemie.

shlibs
Plik pojawia się w pakietach zawierających biblioteki dynamiczne i wykorzystywany jest przez program dpkg-shlibdeps do ustalania zależności od pakietów zawierających biblioteki dynamiczne.

md5sums
Dodatkowy plik zawierający sumy kontrolne, które mogą posłużyć do sprawdzenia spójności zainstalowanego pakietu za pomocą narzędzia debsums. Plik ten nie jest częścią oryginalnego systemu pakietów i nie pojawia się we wszystkich pakietach.

templates, config
Pliki wykorzystywane przez system zarządzania konfiguracją Debconf. Pierwszy z nich zawiera informacje pojawiające się w oknach dialogowych lub na konsoli, drugi jest programem wykorzystującym interfejs programistyczny systemu Debconf do przeprowadzenia dialogu z użytkownikiem.

conffiles
Plik zawierający listę plików konfiguracyjnych. Po obliczeniu sum kontrolnych MD5 tych plików, lista zostanie dołączona do pliku /var/lib/dpkg/status.

Pliki archiwum kontrolnego control.tar.gz mają swoje odzwierciedlenie w postaci plików katalogu /var/lib/dpkg/info/. Przed nazwą danego pliku dodawana jest nazwa pakietu, po czym dany plik umieszczany jest w tym katalogu, jako np. /var/lib/dpkg/info/nazwa-pakietu.postinst. Plik control wyjątkowo dołączany jest do bazy danych zainstalowanych pakietów, czyli do pliku /var/lib/dpkg/status, zaś lista plików zawartych w pakiecie zapisywana jest jako /var/lib/dpkg/info/nazwa-pakietu.list.

Skoro znamy format danych przechowywanych w bazie systemu pakietów i dobrze władamy standardowymi poleceniami cat, ls, grep, sed i innymi, zyskujemy nieograniczone możliwości operowania danymi pakietu.

W pliku *.deb przewidziano także miejsce dla przyszłych członków archiwum. Ostatnie miejsce jest zarezerwowane na archiwum z danymi data.tar.gz. Archiwum to jest zwykłym, skompresowanym archiwum tar, zawierającym pliki i katalogi, które zostaną zainstalowane w systemie. Jak już zostało wspomniane, lista tych plików jest zapisywana do pliku *.info w odpowiednim katalogu.

Nazwa pliku binarnego może być praktycznie dowolna, gdyż brane są pod uwagę informacje pobrane z pliku kontrolnego control. Pliki w archiwum FTP mają nazwy tworzone według pewnego schematu, aby możliwe było sprawne zarządzanie takim archiwum. Nazwa pliku składa się nazwy pakietu, znaku podkreślenia, numeru wersji, znaku podkreślenia, kropki oraz rozszerzenia .deb. Jeśli nie jest to określone w nazwie katalogu, przed rozszerzeniem nazwy pliku opcjonalnie dodaje się znak podkreślenia i nazwę architektury. Wzór pełnej nazwy pliku jest więc następujący:

nazwa-pakietu_1.2.3wersjazrodla-4wersjapakietu_i386.deb

Pakiet źródłowy (*.dsc)

Pakiet binarny Debiana jest budowany na podstawie zawartości katalogu roboczego dla programu dpkg-deb. Zawartość katalogu roboczego, wraz z plikami, trafia do pakietu binarnego do archiwum data.tar.gz, z wyjątkiem podkatalogu DEBIAN/, który tworzy archiwum kontrolne control.tar.gz. Taki katalog roboczy można przygotować ręcznie poprzez stworzenie odpowiednich plików. Aby usprawnić i w dużej mierze zautomatyzować proces budowania pakietów binarnych, stworzono formę pakietu źródłowego.

Proces przygotowania pakietu źródłowego polega na rozpakowaniu oryginalnego źródła i zmianie nazwy katalogu ze źródłami na nazwa-pakietu-123numer.4oryginalnej5.wersji6. W tym katalogu tworzymy dodatkowo podkatalog debian/ w którym umieszczamy niezbędne pliki (debian/control, debian/changelog, debian/rules). Taka operacja przygotowania pakietu źródłowego Debiana nazywa się ,,debianizacją''.

Charakterystyczne dla pakietów źródłowych Debiana jest to, że składają się z kilku plików scalonych oddzielnym plikiem *.dsc. Jeżeli oryginalne źródło nie jest napisane bezpośrednio dla dystrybucji Debiana, to znajduje się w pliku *.orig.tar.gz. Dodatkowe poprawki do tego źródła, jak i cały katalog źródłowy debian/, znajdują się w kolejnym pliku *.diff.gz, jako łata oryginalnego źródła. W przypadku, gdy źródło zawiera już w sobie pliki wykorzystywane do zbudowania pakietu Debiana, dodatkowy ,,patch'' jest zbędny, a zamiast pliku *.orig.tar.gz występuje plik *.tar.gz (bez przyrostka ,,orig'').

Plik *.dsc zawiera opis pakietu źródłowego. Jest on odpowiednikiem pliku control z pakietu binarnego i - podobnie jak w tym ostatnim - informacje w nim przechowywane są w formacie tekstowym. Zawiera m.in. numer wersji pakietu, nazwę pakietu źródłowego i pakietów binarnych, adres e-mail opiekuna pakietu itd.

Ze względów bezpieczeństwa, plik *.dsc ma zwykle podpis elektroniczny swego autora (PGP lub GPG), co umożliwia weryfikację autentyczności wszystkich plików składających się na pakiet źródłowy.

Aby można było uznać pakiet źródłowy za poprawny, po rozpakowaniu musimy otrzymać katalog ze źródłami oraz specjalny podkatalog debian/. W tym podkatalogu muszą się znaleźć co najmniej trzy pliki:

debian/control
Na podstawie tego pliku zostaną stworzone pliki kontrolne wszystkich pakietów binarnych zbudowanych z danego pakietu źródłowego. Plik składa się z kilku akapitów rozdzielonych pustą linią. Pierwszy paragraf zawiera opis pakietu źródłowego, następne zawierają opisy kolejnych pakietów źródłowych.
 
debian/changelog
Plik zawierający historię danego pakietu źródłowego. Każda zmiana w pakiecie źródłowym powoduje dodanie nowego elementu pliku historii. Oprócz wypunktowanych zmian, zapisanych w postaci zrozumiałej dla człowieka, każdy element zawiera informacje wykorzystywane przy procesie budowy pakietów binarnych i pakietu dystrybucyjnego.
 
debian/rules
Jest to program, który poprzez wywołanie odpowiednich programów zewnętrznych dokona kompilacji pakietów binarnych. Wywoływany jest z odpowiednimi argumentami i w zależności od tych argumentów wykonywana jest odpowiednia czynność (kompilacja źródeł, zbudowanie pakietu, usunięcie pozostałości po kompilacji). Utarło się, że programem tym jest skrypt Makefile, ale program może mieć zupełnie dowolną postać - np. skryptu powłoki.

Reszta plików z katalogu debian/ pakietu źródłowego jest opcjonalna i służy do przygotowania archiwum control.tar.gz lub data.tar.gz pakietów binarnych.

Pakiet dystrybucyjny (*.changes)

Model dystrybucji Debiana zakłada, że dystrybucję tworzy wielu opiekunów pakietów, którzy wysyłają swoje efekty pracy do centralnego archiwum. Opiekun dostarcza zarówno pakiet źródłowy jak i pakiety binarne zebrane razem w formie pakietu dystrybucyjnego. Pliki binarne i źródłowe wiąże w całość plik tekstowy *.changes w formacie pliku kontrolnego Debiana.

Plik *.changes zawiera informacje o właścicielu pakietu dystrybucyjnego, plikach składających się na taki pakiet dystrybucyjny oraz o lokalizacji poszczególnych plików w archiwum. Podobnie jak plik *.dsc, ten także może być podpisany elektronicznie.

Z pakietami dystrybucyjnymi mamy do czynienia, gdy poszczególne pliki wchodzące w skład pakietu dystrybucyjnego nie zostały rozlokowane w swoich katalogach docelowych.

Informacje dla systemu pakietów (control)

Dane przeznaczone dla systemu pakietów przechowywane są w formacie tekstowym, jako tzw. plik kontrolny. Plik taki składa się z jednego lub kilku akapitów rozdzielonych pustym wierszem. Akapit składa się z wierszy zawierających nazwę pola, dwukropek i wartość pola. Nazwa pola nie może zawierać znaków spacji ani innych separatorów. Gdy zawartość pola nie mieści się w jednym wierszu (maksymalnie 80 znaków), kontynuowana jest w kolejnym wierszu od znaku spacji, już bez nazwy pola i dwukropka. Jeżeli w tym polu musi wystąpić wiersz pusty, oznacza się go pojedynczą kropką.

Przykładem wykorzystania tej formy przechowywania danych może być choćby książka telefoniczna:

Tytuł: Ania
Telefon: 23789343
Opis: Koleżanka z pracy, ale nie tylko...

Tytuł: Policja
Telefon: 997
Opis: Najbliższy posterunek policji

Tytuł: Internet
Telefon: 0202122
Opis: tak zwany bezpłatny numer dostępowy
.
użytkownik: ppp, hasło: ppp
Modem: tak

Obecność niektórych pól nie jest obowiązkowa, dla innych format wartości pola może zostać ściśle określony. Poniższe zestawienie dotyczy pól wykorzystywanych przez system pakietów Debiana.

Package
Nazwa pakietu binarnego. Nazwa składa się z liter alfabetu łacińskiego, cyfr oraz znaków + - . (plus, minus, kropka). Nazwa musi mieć przynajmniej dwa znaki i rozpoczynać się od litery lub cyfry. Przyjęło się korzystać tylko z małych liter alfabetu łacińskiego, ale w przypadku znalezienia pakietu którego nazwa zawiera wielkie litery, należy pamiętać że sortowanie uwzględnia wielkość liter.

Version
Numer wersji pakietu binarnego lub źródłowego. Numer ten wykorzystuje się najczęściej podczas porównywania ze sobą dwóch wersji w celu określenia, która z nich jest późniejsza.

Numer wersji składa się z trzech części: epoki z dwukropkiem (opcjonalnie), wersji oryginalnego źródła oraz minusa po którym następuje wersja pakietu(opcjonalnie). Ich znaczenie jest następujące:

epoka
Pojedyncza cyfra, którą można pominąć jeśli wynosi zero. Gdy numer epoki pominięto, numer wersji oryginalnego źródła nie może zawierać dwukropka.
 
Numer epoki ma największe znaczenie przy porównywaniu numerów wersji pakietu. Wykorzystuje się go w przypadku, gdy kolejny numer wersji musi być niższy, a jednocześnie pakiet ma być uznany za nowszy. Taka sytuacja następuje, gdy nastąpił błąd w numeracji pakietu lub gdy w oryginalnym źródle zmieniono sposób numeracji wersji.
 
dpkg wyświetla numer epoki tylko wtedy, gdy jest on większy od zera. dselect w ogóle pomija ten numer, wyświetlając jedynie numer wersji źródła i numer wersji pakietu.
 
numer wersji oryginalnego źródła
Najważniejsza część numeru wersji. Najczęściej jest to numer wersji oryginalnego źródła będącego podstawą pakietu Debiana. Zwykle numer ten jest zgodny z numeracją przyjętą przez autora źródła, ale czasem wymagana jest zmiana oryginalnego numeru, tak by pasował do schematu przyjętego przez Debiana (np. rezygnacja z notacji rzymskiej).
 
Numer wersji źródła może zawierać jedynie litery, cyfry oraz znaki + - . : (plus, minus, kropka, dwukropek) i musi zaczynać się od cyfry. Dwukropek nie może występować, jeżeli nie określono numeru epoki; minus jest niedozwolony, gdy brak numeru wersji pakietu.
 
numer wersji pakietu
Ta część numeru wersji oznacza numer kolejnej wersji pakietu binarnego, zbudowanego z tego samego oryginalnego źródła. Format jest taki sam jak w przypadku numeru wersji źródła.
 
Jeżeli pakiet został zbudowany bezpośrednio dla dystrybucji Debiana, jak np. dpkg, kernel-package itd., numer ten jest pomijany gdyż zmiany w numeracji dotyczą jedynie numeru wersji oryginalnego źródła.
 
Przyjęte jest, że po zmianie numeru wersji oryginalnego źródła numer wersji pakietu rozpoczyna się znów od jedynki.
 
Gdy brak jest tego numeru, dpkg przy porównywaniu wersji przyjmie jedynkę za numer wersji pakietu.
 
Przy porównywaniu ze sobą dwóch numerów wersji, największe znaczenie ma numer epoki. Jeżeli te numery są sobie równe (najczęściej obydwa wynoszą zero), porównywane są numery wersji oryginalnego pakietu. Numery te są porównywane od strony lewej do prawej w taki sposób, że najpierw liczbowo dokonuje się porównywania występujących cyfr, następnie według tabeli kodów ASCII porównuje się dalsze znaki nie będące cyframi, aż do pojawienia się kolejnych cyfr - wtedy algorytm jest powtarzany. Porównywanie numerów wersji oryginalnego pakietu kończy znak minusa; rozpoczyna on natomiast proces porównywania wersji pakietu binarnego.
 
Oto przykładowe wyniki takiego porównywania: 1.1 > 1.0.1, 1.1.1 > 1.1, 11a > 1a, 1:1.0 > 1.1, 1.1 > 1.1-0, 1.1-1 > 1.1
 
W dwóch ostatnich przypadkach brak numeru wersji pakietu binarnego oznacza, że ,,jest mniejszy'' od 1 ale ,,jest większy'' od 0.

Architecture
Pole określające architekturę pakietu binarnego. Podczas instalowania pakietu architektura systemu jest sprawdzana i porównywana z informacją w pakiecie. Jeżeli architektury się zgadzają, pakiet zostanie zainstalowany.

Obecnie dpkg obsługuje architektury i386, sparc, sparc64, alpha, m68k, arm, powerpc, mips oraz mipsel dla systemu operacyjnego Linux. dpkg został także przeniesiony na system operacyjny HURD - jest on przeznaczony dla procesorów Intela, a więc nazwa tej architektury to hurd-i386.

Znane są próby przeniesienia dpkg na inne systemy, m.in. Solaris, HP-UX, IRIX, FreeBSD, jednak oficjalnie dpkg nie obsługuje tych systemów.

Specjalnym oznaczeniem architektury jest all, które mówi, że pakiet binarny nie jest zależny od konkretnej architektury i może zostać zainstalowany w dowolnej.

To pole można znaleźć także w pakiecie źródłowym, w pliku *.dsc - oznacza ono architekturę docelową, czyli tę dla której przeznaczony jest skompilowany pakiet binarny. Dodatkową architekturą dla pakietu źródłowego może być any, oznaczająca że pakiet źródłowy można skompilować dla dowolnej architektury.

Maintainer
Opiekun pakietu. To pole zawiera imię, nazwisko oraz e-mail opiekuna pakietu. Jeżeli rolę opiekuna pełni lista mailingowa, zamiast imienia i nazwiska znajdzie się tu nazwa listy lub grupy osób. Dane opiekuna zapisane są w formacie RFC822, czyli najpierw nazwisko lub nazwa, a następnie adres w nawiasach trójkątnych ,,<>''.

Pole opiekuna jest opcjonalne, jednak na adres podany w tym polu użytkownicy pakietu najczęściej wysyłają pytania lub uwagi, więc jego brak może utrudnić kontakt.

Source
Nazwa pakietu źródłowego. To pole dotyczy pakietu źródłowego, a jego zawartość jest analogiczna do pola Package, poza tym że po samej nazwie pakietu można umieścić w nawiasach okrągłych numer wersji pakietu. Numer wersji najczęściej jest pomijany, jeśli jest zgodny z numerem w polu Version pakietu binarnego.

Depends
Definicja całkowitej zależności - pakiet zależy od innego pakietu.

To i poniższe pola mają taki sam format: lista pakietów rozdzielona przecinkami. Pakiety mogą być też rozdzielone znakiem kreski pionowej ,,|'', co oznacza logiczne LUB - poprawna jest przynajmniej jedna z kilku opcji.

Każdy z elementów tej listy (nie dotyczy to pola Provides) może obok nazwy pakietu zawierać w nawiasach okrągłych operator porównania wraz z numerem wersji. Operatory porównania to <<, <=, =, => i >>, czyli: mniejsze, mniejsze lub równe, równe, większe lub równe, większe. Na przykład:

Depends: perl5, libapache-mod-perl (<= 1.15-2), libmldbm-perl (<= 2.00-1), libdigest-md5-perl, data-dumper (<= 2.09-1) | perl-5.005, libwww-perl (<= 5.42-1)

Pole Depends zawiera listę pakietów wymaganych do zainstalowania bieżącego pakietu. Mówiąc dokładniej, dany pakiet nie zostanie skonfigurowany jeżeli pakiety od których zależy nie są poprawnie zainstalowane w systemie. Ponadto, nie można usunąć pakietu, który jest zależny od bieżącego.

Pakiety od których zależny jest pakiet bieżący mogą być zainstalowane, ale nie skonfigurowane. W praktyce oznacza to, że proces instalacji - a później konfiguracji tych wszystkich pakietów - może się odbywać w ramach jednej operacji.

W wyjątkowych sytuacjach zależności można pominąć, uruchamiając dpkg z opcją wymuszania, jednak powoduje to zburzenie spójności bazy systemu pakietów.

Recommends
Definicja silnej zależności - pakiet zaleca inny pakiet.

Pole Recommends jest ignorowane przez program dpkg i nie dotyczy zastosowań z wiersza poleceń. Informacje tego pola są przetwarzane przez narzędzia pełnoekranowe, takie jak dselect czy capt. W przypadku dselect wystąpienie tego typu zależności spowoduje wyświetlenie listy zależności z domyślnie wybranym tym pakietem. Dzięki temu w szybki sposób można wybrać domyślne pakiety.

Zależność ta powinna oznaczać, że dodatkowe pakiety są przydatne, ale nie stanowią niezbędnego warunku działania programu.

Suggests
Definicja słabej zależności - pakiet sugeruje inny pakiet.

Podobnie jak w poprzednim wypadku, pole to interpretowane jest jedynie przez narzędzia pełnoekranowe. dselect dołączy wskazane pakiety do listy zależności, ale pakiety nie będą domyślnie wybrane do zainstalowania.

Najczęściej sugerowane są dodatkowe moduły rozszerzające możliwości danego pakietu albo dokumentacja.

Pre-Depends
Podobnie jak Depends, ale wymagany pakiet musi być poprawnie zainstalowany i skonfigurowany przez rozpoczęciem procedury instalacji bieżącego pakietu.

Jeżeli do instalacji wybrano dwa pakiety, w tym jeden dla którego określono ,,przed-zależność'', dpkg musi zainstalować i skonfigurować pierwszy pakiet, a następnie uruchomić się po raz drugi dla kolejnego pakietu. Ważna jest kolejność instalowania wybranych pakietów. Kolejność wywoływania programu dpkg powinien ustalić program dselect lub apt.

,,Przed-zależność'' jest niezbędna jedynie wtedy, gdy do skonfigurowania bieżącego pakietu potrzebny jest funkcjonujący poprawnie (czyli wcześniej skonfigurowany) inny pakiet. Istotne pakiety, takie jak libc6 czy bash, i tak instalowane są we wczesnym etapie, tak więc najczęściej wystarcza użycie zwykłej zależności - pola Depends.

Conflicts
Konflikt pomiędzy pakietami oznacza, że nie mogą istnieć w systemie w tym samym czasie. Jeżeli konflikt został wykryty przez dpkg, zostanie zgłoszony błąd, a proces instalacji zatrzymany. dselect w takim przypadku wyświetli listę konfliktów, co umożliwi użytkownikowi podjęcie decyzji, który pakiet należy przeznaczyć do skasowania, a który do zainstalowania.

Specjalnym przypadkiem konfliktu jest konflikt z pakietem o takiej samej nazwie, ewentualnie o nazwie takiej jak pakietu wirtualnego, którego dostarcza (Provides) ten sam pakiet. Wymusza to sytuację, w której może istnieć w systemie tylko jeden pakiet, dostarczający pakietu wirtualnego o tej danej nazwie.

Jeżeli konflikt dotyczy pakietu o wersji ,,wcześniejszej'' niż podana, powstaje problem: drugi pakiet musi być wcześniej usunięty lub zaktualizowany. Kolejność instalowania czy usuwania pakietów może zostać źle określona przez dselect i radzi sobie z nią dopiero system apt.

Replaces
Zastąpienie pakietu powodującego konflikt. Jeżeli wymieniony w tym polu pakiet został także wymieniony w polu Conflicts, dpkg automatycznie zastąpi go bieżącym, bez ingerencji administratora.

Pole Replaces nie dotyczy pakietów wirtualnych, a więc nazwa użyta w tym polu musi określać prawdziwy pakiet.

Enhances
Rozszerzenie funkcji innego pakietu. To pole jest niejako odwrotnością pola Suggests. W chwili obecnej jest ignorowane, ale zostało przewidziane do użycia w najbliższej przyszłości.

Niektóre pakiety z podstawowej dystrybucji (main) sugerują wykorzystanie pakietów spoza głównego archiwum (np. non-free lub non-US). Może to spowodować kłopot, gdy dodatkowe archiwum nie jest dostępne, a dselect zgłosi brak niektórych pakietów. Rozwiązaniem ma być właśnie to pole - wtedy pakiety spoza archiwum głównego zgłoszą fakt, że są dodatkiem do pakietów z tego archiwum.

Provides
Udostępnianie wirtualnego pakietu. Dany pakiet może występować pod kilkoma nazwami: jedną prawdziwą i pozostałymi określającymi pakiety wirtualne. Jeżeli inny pakiet zależy od pakietu wirtualnego, wystarczy obecność w systemie przynajmniej jednego pakietu, który dostarcza ten pakiet wirtualny.

Dla przykładu, gdy pakiet wymaga edytora emacs:

Package: vm
Depends: emacs

wystarczy, że w systemie znajduje się jakiś pakiet, który spełnia funkcje tego edytora:

Package: xemacs
Provides: emacs

Pakiet wirtualny nie posiada wersji, toteż nie można uzależnić innego pakietu od obecności pakietu wirtualnego w określonej wersji. W przypadku odwołania się do numeru wersji, zależność będzie dotyczyć tylko prawdziwego pakietu.

Build-Depends
To pole, jak i trzy poniższe, dotyczy wyłącznie pakietów źródłowych. Dany pakiet źródłowy nie może zostać skompilowany, jeżeli w systemie nie zostaną zachowane podane zależności.

Format listy pakietów występujący tym i poniższych polach jest identyczny, jak w przypadku pól zależności dotyczących pakietów binarnych. Ponadto, po nazwie pakietu tworzącego zależność można umieścić rozdzielone spacjami nazwy architektur, dla których ten pakiet ma występować. Jeżeli nazwa architektury poprzedzona jest znakiem wykrzyknika, oznacza to negację wszystkich architektur oprócz podanej.

Przykład wykorzystania tego pola w opisie pakietu źródłowego:

Build-Depends: kernel-headers-2.2.10 [!hurd-i386], hurd-dev [hurd-i386], gnumach-dev [hurd-i386]

Pole Build-Depends określa zależność od pakietów binarnych dla celu build, binary, binary-arch oraz binary-indep.

Build-Conflicts
Pole zawiera listę pakietów binarnych, których obecność w systemie uniemożliwia skompilowanie pakietu dla celu build, binary, binary-arch oraz binary-indep.

Build-Depends-Indep
Pole zawiera listę pakietów binarnych wymaganych do skompilowania pakietu dla celu binary oraz binary-indep.

Build-Conflicts-Indep
Pole zawiera listę pakietów binarnych, których obecność w systemie uniemożliwia skompilowanie pakietu dla celu build oraz binary-indep.

Description
Opis pakietu źródłowego lub binarnego. Pierwszy wiersz to skrócony opis pakietu, zazwyczaj wyświetlany przez pełnoekranowe narzędzia (dselect, capt) na liście pakietów. Szczegółowy opis pakietu rozpoczyna się w następnym wierszu. Zgodnie z formatem danych zawartych w pliku kontrolnym, pierwszym znakiem wiersza jest spacja, zaś wiersz zawierający wyłącznie spację i kropkę reprezentuje wiersz pusty.

Opis pakietu zwykle wzięty jest z podręcznika głównego programu tego pakietu lub z pliku README. Ponieważ opis ten często decyduje o tym, czy administrator zdecyduje się zainstalować dany pakiet, pole to powinno zawierać starannie dobrane informacje.

Dla pliku *.changes pole to ma specjalne znaczenie i zawiera spis skróconych opisów poszczególnych pakietów binarnych zbudowanych z danego pakietu źródłowego. Pierwszy wiersz pola tego pliku jest pusty, kolejne zawierają nazwę pakietu binarnego, znak minusa oraz skrócony opis pakietu.

Essential
Pole określające czy pakiet binarny jest istotny, czyli czy dpkg pozwoli usunąć go z systemu.

Pole może przyjmować dwie wartości: yes lub no. Druga wartość ma takie samo działanie, jakby w pliku kontrolnym w ogóle nie było tego pola.

Section
Sekcja dla pakietu binarnego lub źródłowego. Dany pakiet może zostać umiejscowiony w jednym z wielu podkatalogów grupujących pakiety o podobnym działaniu. Sekcja może także określać archiwum, w którym znajduje się dany pakiet, jeżeli nie jest to archiwum main.

To pole jest przeznaczone dla programów pełnoekranowych, które przedstawiając listę pakietów mogą ją uporządkować według sekcji. dpkg nie uwzględnia pola Section.

Nazwa sekcji odzwierciedla miejsce pliku w archiwum FTP. W chwili obecnej istnieje podział na następujące sekcje:

admin
narzędzia tylko dla administratora - modyfikujące pliki systemowe i wpływające na działanie systemu
 
base
specjalna sekcja określająca pakiety, które zostaną zainstalowane przez program instalacyjny
 
comm
programy komunikacyjne wykorzystujące modem lub faks
 
devel
kompilatory, narzędzia do tworzenia programów, biblioteki przeznaczone dla debuggera, kody źródłowe
 
doc
dokumentacja systemowa oraz dla innych pakietów, programy do jej przeglądania, biuletyny i czasopisma w postaci elektronicznej
 
editors
edytory tekstu wraz z odpowiednimi modułami
 
electronics
programy do wykorzystania w elektronice, narzędzia do projektowania i analizowania układów elektronicznych
 
games
gry i innego rodzaju programy do przyjemnego marnowania czasu
 
graphics
edytory i inne narzędzia do obróbki grafiki bitmapowej, wektorowej lub 3D; przeglądarki plików graficznych oraz programy demonstracyjne
 
hamradio
narzędzia dla użytkowników hamradio
 
interpreters
interpretery, biblioteki dla języków skryptowych
 
libs
biblioteki dla innych programów
 
mail
serwery i klienty poczty elektronicznej
 
math
narzędzia do zastosowań matematycznych
 
misc
pakiety, które nie trafiły do innej sekcji
 
net
serwery i klienty usług sieciowych, narzędzia administracyjne i diagnostyczne dla sieci LAN i WAN
 
news
serwery i klienty USENET
 
oldlibs
stare wersje bibliotek lub kompilatory tworzące kod wykorzystujący wyłącznie stare biblioteki
 
otherosfs
narzędzia do korzystania z innych systemów operacyjnych lub systemów plików, emulatory
 
science
narzędzia do wykorzystania w zastosowaniach naukowych
 
shells
alternatywne powłoki systemowe
 
sound
narzędzia związane z dźwiękiem lub plikami muzycznymi
 
tex
narzędzia oraz moduły dla systemu publikacji TeX
 
text
narzędzia do przetwarzania i drukowania plików tekstowych, procesory tekstu, słowniki
 
utils
wszelkiego rodzaju programy narzędziowe do wykorzystania przez wszystkich użytkowników
 
web
serwery i klienty WWW, narzędzia do tworzenia publikacji WWW oraz administrowania serwisami webowymi
 
x11
programy, biblioteki i moduły związane z systemem X Window
Oprócz tych sekcji istnieje także podział pakietów ze względu na archiwum w jakim się znajdują:
contrib/{admin,base,comm,...}
pakiety spełniające zasady wolnego oprogramowania, ale do pełnego działania wymagające pakietów nie będących wolnymi pakietami
 
non-free/{admin,base,comm,...}
pakiety nie będące wolnymi w rozumieniu Debiana (DFSG)
 
non-US/{main,contrib,non-free}
pakiety, które ze względu na prawo amerykańskie nie mogą być udostępniane na tamtejszych serwerach (dotyczy to przede wszystkim oprogramowania wykorzystującego techniki kryptograficzne)
Ten podział na sekcje jest oczywiście zupełnie umowny i inne dystrybucje mogą wprowadzić swój własny. Dla przykładu, Corel wprowadził swoją dodatkową sekcję Corel Desktop.

Priority
Priorytet pakietu binarnego lub źródłowego, czyli jego ważność. Podobnie jak pole Section, jest ono ignorowane przez dpkg, a może być brane pod uwagę przez narzędzia wyższego poziomu, np. dselect. Informacja z tego pola może być wykorzystywana przy grupowaniu pakietów na liście, a bardziej zaawansowane programy mogą dzięki niej ustalić kolejność instalowania pakietów według ważności. Poniżej prezentujemy listę priorytetów określonych w Debian Policy i rozpoznawanych przez dpkg.

required
Pakiety wymagane, niezbędne do poprawnego funkcjonowania systemu. Ich odinstalowanie może spowodować niemożność ponownej instalacji. System, w którym zainstalowane są tylko pakiety wymagane potrafi sam wystartować i zainstalować inne pakiety.
 
important
Pakiety ważne, których brak byłby szczególnie dotkliwy dla użytkowników systemów uniksowych, m.in. narzędzia bez których pozostała część systemu mogłaby nie działać poprawnie. Ważnymi pakietami nie mogą być duże programy, takie jak Emacs, system X Window czy TeX.
 
standard
Pakiety standardowe dostarczają skromne, ale zupełnie poprawnie działające środowisko tekstowe. Te pakiety są instalowane domyślnie, jeżeli użytkownik samodzielnie nie określi pakietów przeznaczonych do zainstalowania. Standardowo instalowany jest m.in. edytor Emacs oraz podstawowe komponenty systemu TeX i LaTeX.
 
optional
Pakiety opcjonalne - te które powinny znaleźć się w każdym w pełni skonfigurowanym systemie. Można je zainstalować ,,w ciemno'', bez wczytywania się w opis. Pakiety te nie mają dodatkowych wymagań. Do tej kategorii zaliczyć można pełną dystrybucję TeX-a, system X Window i wiele innych powszechnie używanych aplikacji.
 
extra
Pakiety dodatkowe mogą powodować konflikt z pakietami o innym priorytecie, mieć specjalne wymagania systemowe lub są przeznaczone do specjalnych zastosowań.
Pakiety binarne o danym priorytecie nie mogą być zależne od pakietów o niższym priorytecie.

Binary
Pole pakietu źródłowego określające nazwy pakietów binarnych rozdzielonych spacjami lub przecinkami, które można zbudować z danego pakietu źródłowego. Nie wszystkie pakiety można uzyskać dla danej architektury, szczegółowe informacje znajdują się w pliku kontrolnym.

Gdy pole występuje w pliku *.changes, wymienione są tam nazwy pakietów binarnych dostarczanych wraz z pakietem źródłowym.

Installed-Size
Pole pakietu binarnego lub pliku opisu archiwum Packages, określające ilość kilobajtów wolnej pamięci dyskowej potrzebnej do zainstalowania danego pakietu.

Files
Pole dotyczące pakietu źródłowego lub dystrybucyjnego, zawierające listę plików z których składa się pakiet źródłowy.

Lista plików jest podzielona na wiersze, dane o pliku w każdym z wierszy rozdzielone są spacjami.

Dane dla pakietu źródłowego (plik *.dsc) to suma kontrolna MD5 pliku, rozmiar pliku i nazwa pliku. Suma kontrolna i rozmiar są sprawdzane podczas rozpakowywania pakietu źródłowego przez program dpkg-source.

Dane dla pakietu dystrybucyjnego (plik *.changes) to suma kontrolna MD5 pliku, rozmiar pliku, sekcja danego pakietu, priorytet danego pakietu i nazwa pliku. Informacje o sekcji i priorytecie pakietu mogą określać położenie pliku w archiwum FTP.

Standards-Version
To pole określa numer wersji standardu, z jakim zgodny jest dany pakiet źródłowy. Dla dystrybucji Debiana standard określony jest w dokumencie Debian Policy.

Pole może być wykorzystywane przez narzędzia do sprawdzania poprawności budowy pakietu źródłowego - tak jak to robi lintian.

Distribution
Pole dotyczy pakietu dystrybucyjnego, a jego wartość jest ustalana na podstawie zawartości pliku changelog pakietu źródłowego. Określa docelową dystrybucję dla danego pakietu dystrybucyjnego.

Dystrybucje zostały podzielone ze względu na stan zaawansowania prac nad pakietami:

unstable
Wszystkie nowe pakiety są umieszczane w dystrybucji unstable. Pakiet taki może nie funkcjonować poprawnie; mogą nawet wystąpić kłopoty z instalacją.
 
frozen
Co jakiś czas dystrybucja unstable zostaje ,,zamrożona'', co oznacza, że nie są dodawane do niej nowe pakiety, a jedynie usuwane błędy istniejących pakietów. Proces testowania takiej dystrybucji trwa od kilku do kilkunastu tygodni, po czym dystrybucji nadaje się miano stabilnej.
 
Najczęściej poprawki dla dystrybucji frozen trafiają także do dystrybucji unstable, tak więc w polu Distribution mogą być określone te dwie dystrybucje.
 
stable
Dystrybucja stabilna to dystrybucja w danym czasie ,,oficjalna'', w której nie przewiduje się już zmian poza poprawkami poważnych błędów, przede wszystkim dotyczących bezpieczeństwa. Dopiero ta dystrybucja, oprócz nazwy kodowej, otrzymuje numer wersji. W przypadku opublikowania zmian aktualnej wersji zmienia się także jej numer (np. 2.2r1 staje się 2.2r2, później 2.2r3 itd.).
 
experimental
Pakiety z dystrybucji eksperymentalnej są zazwyczaj we wczesnym stadium rozwoju, który nie pozwala na umieszczenie ich w normalnej dystrybucji. Korzystanie z tych pakietów jest najbardziej ryzykowne i nie ma żadnej gwarancji, że uda się je choćby zainstalować.

Urgency
Wartość tego pola jest ustalana na podstawie zawartości pliku changelog i pojawia się w pliku opisu pakietu dystrybucyjnego *.changes. Wartością jest jedno słowo kluczowe, po którym może następować komentarz. W polu tym znajdziemy informacje o tym, jak ważne jest dokonanie aktualizacji danego pakietu.

low
Nowy pakiet poprawia mało istotne błędy lub dostarcza nowej wersji oryginalnego źródła.
 
medium
W nowym pakiecie poprawiono błędy, które wpływały na bezpieczeństwo systemu lub uniemożliwiały poprawne funkcjonowanie pakietu. Aktualizację pakietu warto wykonać w najbliższym czasie.
 
high
Korzystanie ze starego pakietu zagraża spójności systemu. Jak najszybciej należy zaktualizować ten pakiet.

Date
Pole określające datę zbudowania pakietu dystrybucyjnego, pojawiające się w pliku *.changes.

Format
Pole określające numer wersji formatu pliku *.changes, pojawiające się w tym właśnie pliku. Ten dokument dotyczy formatu w wersji 1.6.

Changes
To pole pojawia się w opisie pakietu dystrybucyjnego w pliku *.changes i zawiera opis zmian wprowadzonych w aktualnej wersji pakietu, w formie czytelnej dla człowieka.

Wartość tego pola jest ustalana na podstawie pliku changelog z pakietu źródłowego.

Closes
To pole także dotyczy pliku *.changes, a zawiera informacje przeznaczone dla systemu śledzenia błędów BTS.

Jeżeli w danym pakiecie usunięto błąd, który został wcześniej zgłoszony i któremu został nadany numer rekordu bazy danych BTS, w pliku changelog (oraz w polu Changes) w spisie zmian może pojawić się informacja tekstowa closes: #11111, #22222, .... W informacji tej podane są numery błędów uznanych za zamknięte, czyli usunięte lub zignorowane. Numery te zostają powtórzone w polu Closes, jako lista rozdzielona spacjami.

Filename
Pole pojawia się w pliku opisu archiwum Packages i zawiera ścieżkę do pliku z pakietem, określoną względem katalogu głównego archiwum Debiana. Jeżeli pakiet został podzielony na kilka plików, pole może zawierać kilka wartości rozdzielonych spacjami.

MSDOS-Filename
Pole jest analogiczne do poprzedniego, z tym że nazwa pliku jest zgodna z systemem plików MSDOS (8.3 - osiem znaków nazwy pliku, kropka, trzy znaki rozszerzenia nazwy pliku).

Size
Pole pojawia się w pliku opisu archiwum Packages i zawiera rozmiar pliku z pakietem lub - jeżeli został od podzielony na części - rozmiary plików rozdzielone spacjami. Rozmiar pliku określony jest w bajtach.

MD5sum
Pole pojawia się w pliku opisu archiwum Packages i zawiera sumę kontrolną MD5 dla pliku z pakietem lub - jeżeli został od podzielony na części -, sumy kontrolne plików rozdzielone spacjami.

Status
Pole pojawia się w pliku stanu bazy danych systemu pakietów status i zwiera informacje o stanie pakietu w systemie. Informacje zostały podzielone na trzy klasy: stan bieżący, stan wyboru oraz znacznik. Wartości te mogą zostać zmienione za pomocą programu dpkg lub dselect.

Stan bieżący pakietu:

installed (zainstalowany)
Pakiet jest rozpakowany i poprawnie skonfigurowany.
 
half-installed (zainstalowany częściowo)
Instalacja pakietu została rozpoczęta, ale niedokończona z pewnych powodów.
 
not-installed (niezainstalowany)
Pakiet nie jest zainstalowany w systemie.
 
unpacked (rozpakowany)
Pakiet jest rozpakowany ale nie skonfigurowany.
 
half-configured (skonfigurowany częściowo)
Pakiet jest rozpakowany a konfiguracja została rozpoczęta, ale niedokończona z pewnych powodów.
 
config-files (pliki konfiguracyjne)
Tylko pliki konfiguracyjne pakietu zostały w systemie.
Stan wyboru pakietu:
install (instalacja)
Pakiet został wybrany do zainstalowania.
 
deinstall (deinstalacja)
Pakiet został wybrany do deinstalowania (to znaczy, że chcemy skasować wszystkie pliki pakietu oprócz plików konfiguracyjnych).
 
purge (wyczyszczenie)
Pakiet został wybrany do wyczyszczenia (to znaczy, że chcemy skasować wszystko, włącznie z plikami konfiguracyjnymi).
Znaczniki (flagi) pakietu:
hold (wstrzymanie)
Pakiet oznaczony jako wstrzymany; nie jest obsługiwany przez dpkg, chyba że użyje się opcji --force-hold.
 
reinst-required (konieczna reinstalacja)
Pakiet oznaczony w ten sposób jest uszkodzony i wymaga ponownego zainstalowania. Taki pakiet nie może zostać usunięty przez dpkg, chyba że użyje się opcji --force-reinstreq.

Config-Version
Pole pojawia się w pliku stanu bazy danych systemu pakietów status i jeżeli nie jest zainstalowany lub skonfigurowany, zawiera numer wersji pakietu, której pozostały pliki konfiguracyjne.

Conffiles
Pole pojawia się wyłącznie w pliku stanu bazy danych systemu pakietów status, gdy pakiet zawiera listę plików konfiguracyjnych. Pozycja na tej liście składa się z nazwy pliku konfiguracyjnego i sumy kontrolnej MD5 oryginalnego pliku. Dzięki tej informacji system pakietów wie, czy administrator zmodyfikował oryginalny plik konfiguracyjny.

Pole definiowane przez użytkownika
Pola, które nie zostały wymienione powyżej uznawane są za pola definiowane przez użytkownika i ignorowane przez system pakietów Debiana. Te pola, jeżeli pojawią się w pliku control pakietu źródłowego, nie zostaną przepisane do pliku kontrolnego pakietu binarnego czy źródłowego.

Jeżeli istnieje taka potrzeba, można wykorzystać specjalne pole rozpoczynające się od znaku X, z następującymi po nim opcjonalnymi znakami B, C lub S, po których następuje minus - oraz właściwa nazwa pola. Jeżeli znakiem specjalnym jest B, pole to znajdzie się w pliku control pakietu binarnego; jeżeli znakiem specjalnym jest S, pole pojawi się w pliku *.dsc pakietu źródłowego; jeśli tym znakiem jest C, dotyczy to pliku *.changes pakietu dystrybucyjnego.

Można użyć kilku znaków specjalnych, na przykład:

XBS-Comment: komentarz z pliku debian/control pakietu źródłowego

W podanym przykładzie pole Comment: To jest komentarz... pojawi się w opisie pakietu źródłowego i binarnego.

Wycofane pola pliku kontrolnego
Poniższe pola zostały wycofane i mogą pojawiać się najwyżej w starych pakietach Debiana.

Revision, Package-Revision, Package_Revision
Numer wersji pakietu Debiana; obecnie jest częścią pola Version.

Recommended
Obecnie pole ma nazwę Recommends.

Optional
Obecnie pole ma nazwę Suggests.

Class
Obecnie pole ma nazwę Priority.

Plik historii pakietu (changelog)

Plik historii pakietu jest wymagany przez pakiet źródłowy i pojawia się w nim jako plik debian/changelog. Ten plik powinien być umieszczony w pakiecie binarnym, jako /usr/share/doc/<nazwa-pakietu*>/changelog.gz, jeżeli oryginalny pakiet źródłowy jest źródłowym pakietem Debiana lub /usr/share/doc/<nazwa-pakietu*>/changelog.Debian.gz, jeśli oryginalny pakiet źródłowy został ,,zdebianizowany''.

Plik historii pakietu - oprócz dostarczenia informacji czytelnej dla użytkownika o dokonanych zmianach w pakiecie - ma specjalne znaczenie.

Plik ten jest analizowany przez program dpkg-parsechangelog, który na podstawie zawartości pliku generuje odpowiedni plik kontrolny, wykorzystywany później do zbudowania plików kontrolnych dla pakietów binarnych, źródłowego i dystrybucyjnego.

Domyślny format pliku jest następujący:

<pakiet> (<wersja>) <dystrybucja>; urgency=<ważność>

* <opis zmian, które dotyczą pakietu>
<dalsza część opisu, jeżeli nie zmieściła się powyżej>
* <następny punkt opisu zmian>

-- <opiekun> <data>

Część tych informacji jest wykorzystana przy tworzeniu plików kontrolnych:

pakiet
Nazwa pakietu, taka sama jak w polu Package pliku control pakietu źródłowego.
 
wersja
Numer wersji pakietu, który powinien być identyczny z numerem w nazwie katalogu zawierającego źródła pakietu. Numer ten pojawi się w pliku kontrolnym pakietu binarnego, w polu Version.
 
dystrybucja
Informacja jest kopiowana do pola Distribution pliku kontrolnego *.changes.
 
ważność
Informacja jest kopiowana do pola Urgency pliku kontrolnego *.changes. W polu nie można wykorzystać znaku przecinka, gdyż przecinki rozdzielają listę zawierającą pary <pole>=<wartość>.
 
opiekun
Opiekun tej wersji pakietu. Jeżeli wartość tego pola pokrywa się z polem Maintainer pliku kontrolnego, autorem tej wersji pakietu jest pierwotny opiekun. Można umieścić w tym polu dane innej osoby, co znaczy że ta wersja pakietu została utworzona przez kogoś innego, niż pierwotny opiekun pakietu.
 
data
Data utworzenia danej wersji pakietu, podana w formacie RFC822 i wygenerowana przez program 822-date.
 
opis zmian
Dotyczy przede wszystkim zmian w pakiecie Debiana (tzn. katalogu debian/ pakietu źródłowego), szczególnie gdy opis zmian w oryginalnym źródle jest zawarty w innym pliku. Jeżeli pakiet jest specyficznym pakietem dystrybucji Debiana, w opisie mogą się znaleźć informacje o zmianach w całym źródle.
 
Jeżeli pakiet jest częścią systemu śledzenia błędów, takiego jak np. http://www.debian.org/Bugs, a w opisie zmian pojawia się tekst Closes: #12345, podany numer jest dołączany do listy zamkniętych błędów pola Closes pliku *.changes.
 
W opisie zmian często pojawiają się charakterystyczne informacje. Initial release to często pierwszy wpis do historii zmian. New upstream release oznacza zmianę w oryginalnym źródle i ponowną jego debianizację. NMU lub Non-maintainer release to informacja o tym, że dana wersja pakietu została utworzona przez osobę, która nie jest oficjalnym opiekunem tego pakietu.
Format pliku historii zmian można zastąpić innym, pod warunkiem że w ostatnich 40 wierszach pliku pojawi się ciąg znaków rozpoznawany przez wyrażenie regularne Perla \schangelog-format:\s+([0-9a-z]+)\W oraz istnieje odpowiedni program analizujący ten format, dostępny w systemie jako /usr/lib/dpkg/parsechangelog/<format-name> lub /usr/local/lib/dpkg/parsechangelog/<format-name>. Program analizujący format musi wygenerować dane, takie same jak w przypadku domyślnych ustawień programu dpkg-parsechangelog dla domyślnego formatu pliku historii.

Program obsługi pakietu źródłowego (rules)

Charakterystyczne dla systemu pakietów Debiana jest to, że proces przygotowywania plików z których zostanie utworzony pakiet binarny jest niezależny od wykorzystywanych w tym celu narzędzi. W skrajnym przypadku pliki takie można przygotować ręcznie, co może przydać się przy tworzeniu ,,pustych'' pakietów jedynie z informacjami dla systemu pakietów. Ale pliki robocze do budowy pakietu binarnego można wygenerować także za pomocą specjalnego narzędzia - np. yada.

Aby zbudować pakiet binarny ze standardowego pakietu źródłowego Debiana, wywołuje się odpowiedni program (debian/rules) znajdujący się w tym pakiecie źródłowym.

W zależności od argumentów przekazanych temu programowi, wykonywane są odpowiednie czynności. Ponieważ tradycyjnie ten program jest skryptem Makefile, argument jest celem (ang. target) dla programu make.

build
Ten cel powoduje skompilowanie źródeł bez ingerencji użytkownika. Jeżeli oryginalne źródło wymusza interakcję z użytkownikiem, zdebianizowany pakiet źródłowy musi być tak zmodyfikowany, aby wstępna konfiguracja nie była już potrzebna. Wszelkie operacje wykonywane w ten sposób nie mogą wymagać uprawnień użytkownika root.

Jeżeli z tego samego źródła powstaje kilka pakietów binarnych, dla których sposób kompilacji jest inny, ten cel przestaje mieć sens, a proces kompilacji wywołujemy poprzez cel binary.

W pewnych przypadkach, szczególnie gdy proces kompilowania pakietu jest długi, można zapobiec ponownemu kompilowaniu źródeł przy następnym uruchomieniu debian/rules build.

binary, binary-arch, binary-indep
Wywołanie tego celu powoduje zbudowanie pakietu binarnego ze skompilowanych źródeł. Proces jest ten rozdzielony na kolejne cele binary-arch i binary-indep, w zależności od tego, czy pakiet binarny jest przeznaczony dla tylko jednej architektury, czy dla wszystkich.

Sam cel binary powinien wywołać odpowiednie cele zależne od wyboru architektury, a także cel build, jeżeli ten nie został jeszcze wywołany. Cele binary-* powinny przygotować odpowiedni katalog roboczy, wygenerować plik kontrolny poprzez wywołanie programu dpkg-gencontrol, a następnie zbudować pakiet binarny w katalogu nadrzędnym do bieżącego na podstawie zawartości katalogu roboczego, poprzez wywołanie programu dpkg-deb.

Gdy któryś z celów binary-* nie wykonuje żadnych czynności, powinien po prostu zakończyć swoje działanie bez zgłaszania błędu.

Cel binary i odpowiednie cele zależne od architektury muszą być wywołane z prawami użytkownika root.

clean
Wywołanie tego celu powinno spowodować anulowanie wszelkich zmian dokonanych przez cele binary oraz build, oprócz zmian w katalogu nadrzędnym.

Ten cel musi być wykonany z prawami użytkownika root, jeżeli wcześniej wykonano cel binary.

Przykładowe pliki

Literatura

The Debian Packaging Manual
The Debian GNU/Linux FAQ
man 5 deb
man 5 deb-control
man 8 dpkg