#use wml::debian::template title="System pakietów Debiana" NOHEADER="yes"
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.
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:
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 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:
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.
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.
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:
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:
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.
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:
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.
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:
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 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:
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.
Source: fonty
Maintainer: Piotr Roszatycki <dexter@debian.org>
Section: utils
Priority: extra
Standards-Version: 3.0.1
Package: fonty
Architecture: all
Section: utils
Depends: console-tools (>= 1:0.2.3-1), console-data
Description: Fonts on Linux console.
Fonty package brings a set of iso-8859-n fonts with VT100 graphics: single
frames, a few symbols.
Package: dynafont
Architecture: any
Section: utils
Depends: ${shlibs:Depends}, konwert
Recommends: console-tools (>= 1998.06.03)
Description: Module for konwert package which loads UTF-8 fonts dynamically.
This is a tool which allows displaying texts containing thousands of different
characters. It switches console to UTF8 mode and loads required fonts
dynamically. It is recommended to use this tool with filterm(1) tool,
i.e. by executing 'filterm - dynafont' command.
.
The tool works with UTF8-compatible applications, i.e. lynx(1).
There are problems with 8-bit only applications like mc(1).
Package: fonty-dev
Architecture: all
Section: devel
Depends: ${perl:Depends}
Suggests: fonty
Description: Tools for developing fonts on Linux console.
This package contains Tools for developing console fonts:
* psf2sbf - converts .psf font binary file to text file
* sbf2psf - converts .sbf font source to binary file
Source: fonty
Version: 1.0-6
Binary: fonty, dynafont, fonty-dev
Maintainer: Piotr Roszatycki <dexter@debian.org>
Architecture: any
Standards-Version: 3.0.1
Files:
7b15b582e990656f0b6865eb27e9b094 153294 fonty_1.0.orig.tar.gz
9f579b77c1e1ad516bf1273a847989d3 48607 fonty_1.0-6.diff.gz
Package: dynafont
Version: 1.0-6
Section: utils
Priority: extra
Architecture: i386
Depends: libc6 (>= 2.1), libstdc++2.10, konwert
Recommends: console-tools (>= 1998.06.03)
Installed-Size: 141
Maintainer: Piotr Roszatycki <dexter@debian.org>
Description: Module for konwert package which loads UTF-8 fonts dynamically.
This is a tool which allows displaying texts containing thousands of different
characters. It switches console to UTF8 mode and loads required fonts
dynamically. It is recommended to use this tool with filterm(1) tool,
i.e. by executing 'filterm - dynafont' command.
.
The tool works with UTF8-compatible applications, i.e. lynx(1).
There are problems with 8-bit only applications like mc(1).
Source: fonty
Format: 1.6
Date: Sun, 28 Nov 1999 13:26:56 +0100
Source: fonty
Binary: fonty dynafont fonty-dev
Architecture: source all i386
Version: 1.0-6
Distribution: unstable
Urgency: low
Maintainer: Piotr Roszatycki <dexter@debian.org>
Description:
dynafont - Module for konwert package which loads UTF-8 fonts dynamically.
fonty - Fonts on Linux console.
fonty-dev - Tools for developing fonts on Linux console.
Changes:
fonty (1.0-6) unstable; urgency=low
.
* Removed /etc/init.d/fonty script as far as console-tools do
initialization.
* Some minor modification with debian/*.dpatch files.
* fontyconfig(8) replaced by debconf.
* yada 0.8
Files:
1a688b878b3bffa72760f9c0706b62fb 629 utils extra fonty_1.0-6.dsc
9f579b77c1e1ad516bf1273a847989d3 48607 utils extra fonty_1.0-6.diff.gz
31750fc2be75bbbb4f83a900a1468feb 109816 utils extra dynafont_1.0-6_i386.deb
4a988eba220df2599a9a29f747483183 75440 utils extra fonty_1.0-6_all.deb
835fb15f0d6b56f4ba8dc9fd382d2055 113692 devel extra fonty-dev_1.0-6_all.deb