[ powrót ] [ Spis treści ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ A ] [ dalej ]

Debian Reference
Część 2 - Debian – Podstawy

Ten rozdział dostarcza podstawowych informacji o systemie Debian dla osób nie będących deweloperami. Sprawdzone i oficjalne wiadomości należy czerpać z:

wymienionych w Zasoby, Rozdział 15.1.

Jeżeli szukasz mniej szczegółowych „jak-to-zrobić” („how-to”), przejdź bezpośrednio do Zarządzanie pakietami Debiana, Część 6 lub innych zasobów.

Niniejszy rozdział zawiera dokumenty wzięte z „Debian FAQ”, poddane gruntownej reorganizacji dla ułatwienia startu początkującemu administratorowi systemu Debian.

2.1 Archiwa Debiana

2.1.1 Struktura katalogów

Pakiety z oprogramowaniem systemu Debian dostępne są poprzez FTP lub HTTP z katalogów znajdujących się na serwerze lustrzanym Debiana.

Na każdym z takich serwerów w katalogu debian można znaleźć następujące podkatalogi:

dists/:

Ten katalog zawiera „dystrybucje”, a niegdyś był to kanoniczny sposób uzyskiwania dostępu do aktualnych pakietów w stabilnych i niestabilnych wydaniach Debiana. Wciąż można tam znaleźć trochę starych pakietów, pliki Contents-*.gz, i pliki Packages.gz.

pool/:

Nowe miejsce umieszczenia pakietów należących do wszystkich końcowych i testowych wydań Debiana.

tools/:

DOSowe programy użytkowe, umożliwiające tworzenie dyskietek startowych, partycjonowanie dysków, kompresję i dekompresję plików oraz uruchomienie Linuksa.

doc/:

Podstawowa dokumentacja Debiana, np. FAQ, instrukcje dotyczące zgłaszania błędów, itp.

indices/:

Pliki Maintainers i override.

project/:

przeważnie materiały dla deweloperów takie, jak:

project/experimental/:

Pakiety i narzędzia, które jeszcze nie zostały ukończone i znajdują się w fazie alfa. Nie należy ich używać ponieważ mogą się okazać niebezpieczne i szkodliwe nawet dla najbardziej doświadczonych.

project/orphaned/:

Pakiety osierocone przez dotychczasowych opiekunów i wykreślone z dystrybucji.

2.1.2 Dystrybucje Debiana

W katalogu dists normalnie znajdują się informacje o trzech dystrybucjach Debiana. Katalogi z nimi (i same dystrybucje) noszą nazwy stable (dystrybucja stabilna), testing (dystrybucja testowa) i unstable (dystrybucja niestabilna). Czasami też występuje tam dystrybucja frozen („zamrożona”). Katalog każdej dystrybucji stanowi symboliczne dowiązanie do rzeczywistego katalogu o odpowiednim kryptonimie w katalogu dists.

2.1.3 Dystrybucja stabilna

Dane pakietów należących do dystrybucji stabilnej, Debian Sarge (3.1r0), są zapisywane do katalogu stable (dowiązanie symboliczne do Sarge/):

Wyżej wymienione katalogi zawierają informacje o pakietach. Same pakiety zaś mieszczą się w katalogu pool (Katalog pool, Rozdział 2.1.10).

Aktualny stan błędów w dystrybucji stabilnej podaje strona WWW Problemy ze stabilną dystrybucją (po angielsku) .

2.1.4 Dystrybucja testowa

Informacja o pakietach zawartych w dystrybucji testowej, czyli Debian Etch, jest zapisywana w katalogu testing (dowiązanie symboliczne do Etch/) po tym, jak przejdą testowanie wstępne w dystrybucji niestabilnej. Pakiety, których dotyczą informacje zapisane w katalogu testing, są umieszczane w katalogu pool (Katalog pool, Rozdział 2.1.10). Oczywiście, w katalogu testing istnieją również podkatalogi main, contrib oraz non-free, pełniące takie same funkcje, jak ich odpowiedniki w stable.

Pakiety w dystrybucji testowej muszą działać na wszystkich architekturach, na których zostaną zbudowane i nie mogą posiadać zależności uniemożliwiających instalację; muszą mieć również mniej błędów o priorytecie release-critical (o znaczeniu krytycznym dla wydania), niż wersje znajdujące się w unstable. W ten sposób można mieć nadzieję, że dystrybucja testowa zawsze jest dystrybucją bliską wydania. Więcej informacji o mechanizmach testowania znajduje się na http://www.debian.org/devel/testing (po angielsku).

Najświeższe informacje o stanie dystrybucji testowej zawierają następujące strony WWW:

2.1.5 Dystrybucja niestabilna

Informacje o pakietach wchodzących w skład dystrybucji niestabilnej, zawsze nazywanej „Sid”, są zapisywane do katalogu unstable (dowiązanie symboliczne do sid/) po umieszczeniu tych pakietów w archiwum Debiana i pozostają tu, aż zostaną przeniesione do testing/. Odpowiadające wpisom pakiety umieszcza się w katalogu pool (Katalog pool, Rozdział 2.1.10). Również istnieją tu podkatalogi main, contrib i non-free, spełniające te same zadania, co w katalogu stable/.

Dystrybucja niestabilna jest obrazem systemu w najnowszym stadium jego rozwoju. Nic nie stoi na przeszkodzie w używaniu i testowaniu tych pakietów, trzeba jednak uważać, bo mogą być jeszcze nie w pełni dopracowane. Zaletą korzystania z dystrybucji niestabilnej jest to, że jest się zawsze „na czasie” ze wszystkimi nowinkami w projekcie Debian, ale jeżeli coś nawali, to licz na siebie, a nie na pomoc.

Na stronie WWW Problemy z dystrybucją niestabilną (po angielsku) można się zapoznać z aktualnym stanem błędów w dystrybucji niestabilnej.

2.1.6 Dystrybucja frozen (zamrożona)

Gdy dystrybucja testowa osiągnie wystarczającą dojrzałość, zostaje zamrożona, co oznacza, że nie przyjmuje się do niej już żadnego nowego oprogramowania z wyjątkiem koniecznych poprawek (bugfixes). W katalogu dists/ tworzy się nowy podkatalog dla dystrybucji testing, dowiązany do nowego kryptonimu. Dystrybucja zamrożona przechodzi przez kilkumiesięczny okres próbny składający się na przemian z aktualizacji i z okresów głębokiego zamrożenia nazywanych „cyklami testowymi”.

Utrzymujemy rejestr błędów w dystrybucji zamrożonej, które mogą opóźnić wydanie pakietu lub doprowadzić do wstrzymania wydania całej dystrybucji. Gdy liczba błędów spadnie do maksymalnie akceptowalnej wartości, dystrybucja zamrożona staje się dystrybucją stabilną (stable), zostaje wydana, a dotychczasowe wydanie stabilne staje się przestarzałe (obsolete) i zostaje przeniesione do archiwum.

2.1.7 Kryptonimy dystrybucji Debiana

Nazwy rzeczywistych podkatalogów w katalogu dists, na przykład Sarge i Etch, są tylko „kryptonimami”. Kiedy dystrybucja systemu Debian znajduje się jeszcze w etapie rozwojowym, nie posiada numeru wersji, a zamiast niego kryptonim. Kryptonimy zastosowano w celu ułatwienia tworzenia archiwów lustrzanych (mirroring) dystrybucji systemu Debian (gdyby rzeczywisty katalog taki, jak unstable nagle zmienił swoją nazwę na stable/, niejeden musiałby niepotrzebnie pobierać ponownie masę oprogramowania).

Aktualnie, stable/ jest dowiązaniem symbolicznym do Sarge/, a testing/ dowiązaniem do Etch/. Oznacza to, że Sarge jest aktualną dystrybucją stabilną, a Etch testową.

unstable/ jest już na zawsze dowiązaniem symbolicznym do sid/, ponieważ Sid jest zawsze dystrybucją niestabilną.

2.1.8 Kryptonimy używane w przeszłości

Inne kryptonimy, których już wcześniej używano, to: „Buzz” dla wydania 1.1, „Rex” dla wydania 1.2, „Bo” dla wydania 1.3.x, „Hamm” dla wydania 2.0, „Slink” dla wydania 2.1, „Potato” dla wydania 2.2, „Woody” dla wydania 3.0 oraz „Sarge” dla wydania 3.1.

2.1.9 Źródło kryptonimów

Jak dotychczas wybierano postaci z filmu Toy Story produkcji Pixar.

2.1.10 Katalog pool

Dawniej pakiety przechowywano w podkatalogu katalogu dists, którego nazwa odpowiadała dystrybucji, w skład której wchodziły. Okazało się jednak, że wywoływało to różne problemy, jak np. duże obciążenie serwerów lustrzanych, gdy dokonywano większych zmian.

Obecnie pakiety znajdują się w dużej „puli” („pool”), której struktura jest utworzona na podstawie nazw pakietów źródłowych. Dla ułatwienia zarządzania czymś takim, pula - pool jest podzielona według sekcji (main, contrib i non-free) i według pierwszej litery nazwy pakietu źródłowego. Katalogi te zawierają pewną liczbę plików: pakiety binarne dla każdej architektury (platformy sprzętowej) oraz pakiety źródłowe, z których te pierwsze zostały wygenerowane.

Miejsce, gdzie znajduje się jakiś pakiet, można określić wykonując polecenie apt-cache showsrc nazwa_pakietu i znajdując w jego wyjściu wiersz zaczynający się od „Directory:”. Na przykład pakiety serwera http apache znajdują się w pool/main/a/apache/. Pakietów lib* jest bardzo dużo, więc są traktowane szczególnie: na przykład pakiety libpaper są przechowywane w katalogu pool/main/libp/libpaper/.

Podkatalogi katalogu dists są w dalszym ciągu używane do przechowywania plików indeksowych używanych przez programy w rodzaju apt. Również, w czasie pisania niniejszego dokumentu starsze dystrybucje nie były przestawione na używanie katalogu pool, więc można zobaczyć takie nazwy dystrybucji, jak potato czy woody w wierszach zaczynających się od „Directory:” (przytoczone powyżej polecenie apt-cache).

Nie jest to powód do zmartwień, ponieważ nowy apt i prawdopodobnie również starszy dpkg-ftp (zobacz Sposoby aktualizacji systemu Debian, Rozdział 2.3.1) radzą sobie z taką strukturą bez problemów. Więcej informacji można znaleźć w RFC: implementation of package pools (po angielsku).

2.1.11 Nota historyczna o dystrybucji Sid

Kiedy dzisiejszy Sid jeszcze nie istniał, organizacja sieciowych archiwów Debiana miała jedną dużą wadę: kiedy dokładano nową architekturę do bieżącej dystrybucji unstable, pakiety zrobione dla niej mogły być wydane dopiero wtedy, gdy ta dystrybucja stawała się nową dystrybucją stable. Dla wielu architektur nie dochodziło do tego i trzeba było przenosić odpowiadające im katalogi, gdy dochodziło do wydania dystrybucji. Było to niepraktyczne, ponieważ przenoszenie katalogów silnie obciążało łącza.

Administratorzy archiwów sieciowych przez kilka lat obchodzili ten problem, umieszczając binaria dla architektur jeszcze nie wydanych w specjalnym katalogu o nazwie sid. Dla architektur jeszcze nie wydanych, tworzono w chwili wydania dowiązanie z aktualnego katalogu stable do sid i od tej pory tworzono je w drzewie unstable, jak zwykle. Takie rozwiązanie było trochę mylące dla użytkowników.

Z nadejściem katalogu „pool” (zobacz Katalog pool, Rozdział 2.1.10) w trakcie powstawania dystrybucji Woody, zaczęto zapisywać pakiety binarne w lokalizacji kanonicznej w tymże katalogu, niezależnie od dystrybucji, więc wydanie dystrybucji przestało być związane z poddawaniem serwerów lustrzanych dużym obciążeniom (natomiast mamy do czynienia z dość sporymi, rozłożonymi w czasie obciążeniami w trakcie całego procesu rozwijania dystrybucji).

2.1.12 Pakiety umieszczone w incoming/

Pakiety umieszczane w archiwum trafiają najpierw do http://incoming.debian.org/, po sprawdzeniu autentyczności pochodzenia od jednego z deweloperów (w wypadku tzw. Non-Maintainer Upload -- NMU -- pakiety trafiają do podkatalogu DELAYED). Raz dziennie pakiety przenosi się z incoming/ do unstable/.

W nagłych wypadkach można instalować pakiety z incoming/, zanim jeszcze trafią do unstable.

2.1.13 Odzyskiwanie starszego pakietu

Podczas gdy najnowsze dystrybucje Debiana trzyma się w podkatalogach katalogu debian, na każdym z serwerów wymienionych na Stronie serwerów lustrzanych Debiana, archiwa starszych dystrybucji (np. Slink) znajdują się na http://archive.debian.org/ lub w podkatalogach katalogu debian-archive na każdym serwerze lustrzanym Debiana.

Starsze pakiety z testing i unstable można znaleźć na http://snapshot.debian.net/.

2.1.14 Podział na architektury

W obrębie każdego z głównych drzew katalogów (dists/stable/main, dists/stable/contrib, dists/stable/non-free, dists/unstable/main/, itd.), informacja o pakietach binarnych znajduje się w podkatalogach o nazwach wskazujących na platformę sprzętową (architekturę), dla jakiej zostały skompilowane.

Warto zauważyć, że pakiety binarne dla dystrybucji testing i unstable nie są już przechowywane w tych katalogach, ale w katalogu pool. Pliki indeksowe (Packages i Packages.gz) jednak, dla zachowania kompatybilności z wcześniejszymi rozwiązaniami, w dalszym ciągu przebywają tam, gdzie były.

Aby poznać faktyczny zestaw wspieranych platform sprzętowych, należy zapoznać się z Informacjami Wydawniczymi dla danej dystrybucji. Można je odnaleźć na stronach zajmujących się Uwagami Wydawniczymi dla stable i testing.

2.1.15 Kod źródłowy

Debian posiada również kod źródłowy każdego ze swoich składników. Co więcej, warunki licencji większości programów w systemie zawierają wymóg dystrybucji kodu źródłowego wraz z programem, lub przynajmniej zadeklarowania gotowości dostarczenia kodu źródłowego wraz z programem.

Normalnie kod źródłowy jest rozpowszechniany za pośrednictwem katalogów source, istniejących równolegle do wszystkich katalogów charakterystycznych dla poszczególnych architektur, a obecnie w katalogu pool directory (zobacz Katalog pool, Rozdział 2.1.10). Aby pobrać z archiwum kod źródłowy bez konieczności zaznajamiania się ze strukturą archiwum Debiana należy wykonać polecenie podobne do tego: apt-get source mojanazwapakietu.

Niektóre pakiety, na przykład pine, są dostępne wyłącznie w postaci źródeł wskutek ograniczeń licencyjnych. (Niedawno pojawił się pakiet pine-tracker ułatwiający instalację Pine). Procedury opisane w Przeniesienie pakietu do systemu stabilnego, Rozdział 6.4.10 i Pakietowanie, Rozdział 13.9 opisują sposoby tworzenia pakietów samemu.

Dla pakietów z katalogów contrib i non-free, które oficjalnie nie stanowią części systemu Debian, kod źródłowy może być niedostępny.

2.2 System zarządzania pakietami w Debianie

2.2.1 Przegląd pakietów Debiana

W ogólności pakiety zawierają wszystkie pliki niezbędne do zaimplementowania zestawu odpowiednich poleceń lub właściwości. Są dwa typy pakietów Debiana:

Instalacja oprogramowania przez system pakietów posługuje się pojęciem „zależności” („dependencies”), troskliwie określonych przez opiekunów poszczególnych pakietów. Te zależności są wyszczególnione w pliku control wchodzącym w skład każdego pakietu. Na przykład, pakiet zawierający kompilator GNU C (gcc) jest zależny od zawierającego konsolidator (linker) i asembler pakietu binutils. Jeżeli użytkownik usiłuje zainstalować gcc nie zainstalowawszy uprzednio binutils, system zarządzania pakietami (dpkg) drukuje komunikat mówiący, że trzeba zainstalować binutils, a następnie zatrzymuje instalację gcc (uparty użytkownik może jednak zmienić to zachowanie; zobacz dpkg(8)). Z dodatkowymi szczegółami można zapoznać się w Zależności między pakietami, Rozdział 2.2.8.

Zawartych w Debianie narzędzi obsługujących pakiety można używać do:

2.2.2 Format pakietów Debiana

„Pakiet” Debiana (zwany też archiwum Debiana - nie mylić z umieszczoną na serwerze całą dystrybucją!) zawiera pliki wykonywalne, biblioteki oraz dokumentację związaną z konkretnym programem lub zestawem w jakiś sposób powiązanych ze sobą programów. Z reguły nazwa pakietu Debiana kończy się sufiksem .deb.

Budowę wewnętrzną pakietów binarnych w tym formacie opisuje podręcznik systemowy deb(5). Z uwagi na możliwość zachodzenia zmian w specyfikacji formatu (z jednego wydania systemu Debian na kolejne jego wydanie), przy manipulacji plikami .deb należy zawsze korzystać z dpkg-deb(1).

Wszystkie pakiety Debiana (Sarge i wcześniejsze dystrybucje), można obrabiać używając standardowych poleceń systemu Unix: ar, i tar, nawet, gdy polecenia dpkg są niedostępne.

2.2.3 Zasady nadawania nazw pakietom Debiana

Nazwy plików zawierających pakiety w Debianie przestrzegają następujących zasad: 

     foo_NumerWersji-NumerRewizjiDebiana.deb

gdzie foo stanowi nazwę pakietu. Dla sprawdzenia: mając dany plik .deb można określić nazwę zawartego w nim pakietu w jeden z następujących sposobów:

Składnik VVV jest numerem wersji, nadanym przez programistę zajmującego się danym programem/pakietem poza systemem Debian. Numery wersji nie są ustalane przez żadne normy, dlatego też mogą one mieć najrozmaitsze formaty, jak np. „19990513” czy „1.3.8pre1”.

Składnik RRR jest numerem rewizji w Debianie i jest nadawany przez opiekuna danego pakietu lub przez indywidualnego użytkownika, jeśli ten zechce zbudować pakiet samodzielnie. Numer ten odpowiada poziomowi rewizji pakietu w systemie; z tego względu nowy poziom rewizji zwykle oznacza zmiany w plikach opisujących budowę i instalację pakietu: debian/rules (Debian makefile), debian/control (Debian control file), skrypcie instalacyjnym i deinstalacyjnym debian/p*, lub plikach konfiguracyjnych związanych z pakietem.

2.2.4 Ochrona lokalnych plików konfiguracyjnych

Mechanizm „conffiles” istniejący w Debianie pozwala na otoczenie ochroną plików konfiguracyjnych w systemie. Pliki te, zazwyczaj umieszczone w katalogu /etc, są wymienione w plikach o nazwach kończących się na conffiles wchodzących w skład systemu pakietów. Mechanizm ten gwarantuje, że systemowe pliki konfiguracyjne nie będą nadpisywane podczas instalacji nowej wersji pakietu.

Jeśli możliwa jest konfiguracja systemu bez dokonywania zmian w plikach należących do różnych pakietów, dobrym pomysłem jest powstrzymanie się od ich modyfikacji nawet jeśli są to pliki „conffiles”. Ułatwi to i przyspieszy instalację nowych wersji pakietów.

Aby dowiedzieć się, jakie dokładnie pliki zostaną zachowane podczas instalacji nowej wersji (upgrade'u) pakietu, należy uruchomić polecenie: 

     dpkg --status pakiet

i szukać „Conffiles:”.

Szczegółów na temat zawartości plików conffiles dostarcza dokument Debian Policy Manual w rozdziale 11.7 (zobacz Zasoby, Rozdział 15.1).

2.2.5 Skrypty instalacyjne i deinstalacyjne

Są to skrypty automatycznie uruchamiane przed instalacją i po instalacji pakietu. Wraz z plikiem o nazwie control wchodzą w skład sekcji „control” każdego pakietu w Debianie.

Są to:

preinst

Ten skrypt jest wykonywany zanim pakiet zostanie rozpakowany z pliku .deb. Wiele skryptów „preinst” zatrzymuje działanie usług świadczonych przez pakiety, których nową wersję właśnie instalujemy, aż do czasu zakończenia procesu instalacji lub aktualizacji (tzn. do chwili bezbłędnego wykonania skryptu „postinst”).

postinst

Ten skrypt z zasady wykonuje wszelkie operacje konfiguracyjne wymagane do prawidłowej pracy pakietu po jego rozpakowaniu z pliku .deb. Skrypty „postinst” często wymagają wprowadzenia pewnych informacji przez użytkownika i/lub ostrzegają go, że w wypadku akceptacji wartości domyślnych powinien pamiętać o późniejszej rekonfiguracji pakietu w miarę potrzeb. Wiele ze skryptów „postinst” wykonuje następnie wszelkie polecenia konieczne do uruchomienia lub ponownego uruchomienia danej usługi po instalacji lub aktualizacji pakietu.

prerm

Z reguły, skrypt ten zatrzymuje wszystkie demony związane z pakietem, a jest wykonywany przed usunięciem plików, które zawierał ten pakiet.

postrm

Ten skrypt z reguły modyfikuje dowiązania lub inne pliki związane z pakietem i/lub usuwa pliki przezeń utworzone (zobacz również Pakiety wirtualne, Rozdział 2.2.7).

Aktualnie wszystkie pliki sterujące pakietu (te z sekcji „control”) można znaleźć w katalogu /var/lib/dpkg/info. Pliki związane z pakietem foo mają nazwy zaczynające się od „foo” i kończące na „preinst”, „postinst”, itd. Plik foo.list w tym katalogu wymienia wszystkie pliki zainstalowane podczas instalacji pakietu foo. (Położenie tych plików jest wewnętrzną sprawą programu dpkg i może być zmienione).

2.2.6 Priorytety pakietów

Każdemu pakietowi w Debianie opiekunowie dystrybucji przypisali pewien priorytet, mający spełniać pomocnicze funkcje względem systemu zarządzania pakietami. Istnieją następujące rodzaje priorytetów:

Zwróć uwagę na różnice pomiędzy "Priority: required", "Section: base" i "Essential: yes" w opisie pakietu. "Section: base" oznacza, że ten pakiet jest instalowany w nowym systemie przed czymkolwiek innym. Większość pakietów z "Section: base" posiada ""Priority: required" lub przynajmniej "Priority: important" i wiele z nich jest oznaczona jako "Essential: yes". "Essential: yes" oznacza, że aby taki pakiet usunąć należy użyć dodatkowych parametrów do polecenia tak by wymusić to usuwanie korzystając z dpkg. Na przykład libc6, mawk i makedev posiadają w ustawieniach "Priority: required" i "Section: base" ale nie "Essential: yes".

2.2.7 Pakiety wirtualne

Pakiet wirtualny nosi nazwę odnoszącą się do dowolnego z grupy pakietów, posiadających zbliżoną funkcjonalność. Na przykład zarówno tin jak i trn są klientami grup dyskusyjnych i każdy z nich powinien spełniać wymagania innego programu, wymagającego czytnika news do działania. O obu z nich mówi się więc, że dostarczają „wirtualny pakiet” o nazwie news-reader.

Podobnie, exim i sendmail są programami transportującymi pocztę (mail transport agent). Mówi się więc o nich, że dostarczają wirtualny pakiet o nazwie mail-transport-agent. Jeżeli jeden z nich zostanie zainstalowany, każdy program zależący od instalacji mail transport agent zostanie usatysfakcjonowany dzięki istnieniu tego pakietu wirtualnego.

Debian posiada również mechanizm umożliwiający administratorowi wyznaczenie preferowanego pakietu w razie, gdy kilka zainstalowanych pakietów dostarcza ten sam „pakiet wirtualny”. Odpowiednim poleceniem jest update-alternatives, które opisano w Alternatywne polecenia, Rozdział 6.5.3.

2.2.8 Zależności między pakietami

W systemie zarządzania pakietami w Debianie istnieje kategoria „zależności” między pakietami zaprojektowanych tak, aby w prosty sposób, (za pomocą pojedynczej flagi) ukazać poziom niezależności funkcjonowania programu A od istnienia w danym systemie programu B:

Bardziej szczegółowe informacje o wykorzystaniu każdego z powyższych pojęć zawierają dokumenty Packaging Manual i Policy Manual.

Dobrze wiedzieć, że dselect umożliwia bardziej subtelną kontrolę nad pakietami zalecanymi i sugerowanymi, niż apt-get, który po prostu pobiera wszystkie pakiety oznaczone zależy a zostawia w spokoju rekomendowane i sugerowane. W nowoczesnym wydaniu obydwa programy są „nakładką” na APT.

2.2.9 Znaczenie „pre-depends”

Pojęcie „zależność wstępna” („pre-depend”) stanowi szczególny rodzaj zależności. W wypadku zwyczajnego pakietu dpkg rozpakuje plik pakietu (plik .deb) niezależnie od tego, czy pliki, od których dany pakiet zależy, są już w systemie. Samo rozpakowanie polega na tym, że dpkg wyciąga z pliku archiwum pliki przeznaczone do instalacji w systemie użytkownika i umieszcza je we właściwych miejscach w tym systemie. Jeżeli pakiet właśnie instalowany zależy od obecności w systemie użytkownika jakichś innych pakietów, dpkg odmówi dokończenia instalacji (co przejawiłoby się wykonaniem akcji „configure”) aż do czasu zainstalowania tych pakietów.

Istnieje jednak trochę pakietów, których dpkg nie będzie chciał nawet rozpakować, dopóki nie zostaną spełnione pewne zależności. Mówimy, że takie pakiety „pre-depend” (zależą wstępnie) od obecności w systemie jakichś innych pakietów. Mechanizm ten został wprowadzony w projekcie Debian w celu ułatwienia bezpiecznej instalacji nowych wersji pakietów w dobie przejścia z formatu a.out na ELF, gdy nawet kolejność rozpakowywania pakietów była krytyczna. Są też inne sytuacje związane z dużymi aktualizacjami systemu, w których omawiany mechanizm okazuje się użyteczny, np. dla pakietów o priorytecie „Wymagane” zależnych od libc.

Bardziej szczegółowe informacje można znaleźć w dokumencie Packaging Manual.

2.2.10 Status pakietu

Status pakietu może przybierać formę: „nieznany” („unknown”), „zainstalować” („install”), „usunąć częściowo” („remove”), „usunąć całkowicie” („purge”) lub „zatrzymać” („hold”). Te znaczniki pokazują, co użytkownik chciałby uczynić z danym pakietem (przez dokonanie wyboru w sekcji „Select” programu dselect lub przez bezpośrednie wywołanie dpkg).

Ich znaczenie jest następujące:

2.2.11 Zapobieganie instalacji nowych wersji pakietów

Są dwa mechanizmy chroniące pakiety przed instalacją nowej wersji, jeden z nich oparty jest na dpkg, a drugi od dystrybucji Woody, na APT.

Wykorzystując ten pierwszy z nich, należy najpierw wyeksportować listę zawierającą nazwy zainstalowanych pakietów i status każdego z nich: 

     dpkg --get-selections \* > selections.txt

Następnie należy dokonać edycji powstałego pliku selections.txt, zmieniając odpowiednio wiersz zawierający nazwę pakietu, który chcemy chronić (np. libc6), z czegoś takiego: 

     libc6                       install

na coś takiego: 

     libc6                       hold

Plik należy zapisać na dysku i wprowadzić go do bazy danych dpkg wykonując polecenie: 

     dpkg --set-selections < selections.txt

Jeżeli dobrze znamy nazwę pakietu, który chcemy chronić, możemy po prostu wykonać: 

     echo libc6 hold | dpkg --set-selections

Dla każdego potraktowanego w ten sposób pakietu oznacza to, że będzie on chroniony przed zainstalowaniem swojej nowszej wersji.

Taki sam wynik można uzyskać korzystając z programu dselect. Wystarczy w tym wypadku wejść do sekcji [S]elect, odnaleźć pakiet, który chcemy chronić przed zmianą i nacisnąć klawisz „=” lub „H”. Zmiana statusu będzie obowiązywać od chwili opuszczenia sekcji [S]elect.

Wiodący w dystrybucji Woody, system APT posiada nowy, alternatywny mechanizm ochrony pakietów podczas ich pobierania z repozytorium, oparty na Pin-Priority. Więcej szczegółów na ten temat dostarczy apt_preferences(5), wraz z http://www.debian.org/doc/manuals/apt-howto/ lub pakietem apt-howto; Przegląd pliku /etc/apt/preferences, Rozdział 6.2.8 również zawiera krótkie wyjaśnienie.

2.2.12 Pakiety źródłowe

Pakiety źródłowe są przechowywane w katalogu o nazwie source, można je pobierać klasycznymi metodami, można też użyć polecenia 

     apt-get source foo

do ich pobrania (o konfiguracji programu APT do tej operacji szerzej traktuje podręcznik systemowy: apt-get(8)).

2.2.13 Tworzenie pakietów binarnych ze źródłowych

Aby skompilować pliki źródłowe dla pakietu o nazwie foo, będzie trzeba użyć wszystkich, z następujących plików: foo_*.dsc, foo_*.tar.gz oraz foo_*.diff.gz. (ciekawa rzecz: dla rodzimych pakietów Debiana nie ma plików .diff.gz).

Jeśli pobraliśmy już wszystkie potrzebne pliki i mamy zainstalowany pakiet dpkg-dev, polecenie 

     $ dpkg-source -x foo_version-revision.dsc

rozpakuje pakiet do katalogu o nazwie foo-version.

Aby utworzyć pakiet binarny, należy wydać następujące polecenie (tutaj podane w wersji dla zwykłego użytkownika): 

     $ cd foo-version
     $ su -c "apt-get update ; apt-get install fakeroot"
     $ dpkg-buildpackage -rfakeroot -us -uc

Następnie, 

     $ su -c "dpkg -i ../foo_version-revision_arch.deb"

aby zainstalować świeżo utworzony pakiet. Więcej informacji - Przeniesienie pakietu do systemu stabilnego, Rozdział 6.4.10.

2.2.14 Tworzenie nowych pakietów Debiana

Szczegółowych informacji dotyczących tworzenia nowych pakietów dostarczy lektura New Maintainers' Guide, dostępnego jako pakiet maint-guide, lub pod adresem http://www.debian.org/doc/manuals/maint-guide/.

2.3 Aktualizacja systemu Debian

Jednym ze strategicznych celów Debiana jest dostarczenie spójnych metod umożliwiających bezpieczną instalację nowego oprogramowania; dokładamy starań, aby proces instalacji nowego wydania na poprzednim przebiegał jak najbardziej gładko. Pakiety będą informować użytkownika o ważnych zdarzeniach podczas instalacji, a często będą proponować rozwiązanie problemu.

Należy przeczytać Uwagi Wydawnicze (Release Notes), dokument opisujący szczegóły instalacji nowej wersji (upgrade'u) poszczególnych dystrybucji, dostarczany na każdej płytce z systemem Debian i dostępny na stronach WWW pod adresem http://www.debian.org/releases/stable/releasenotes lub http://www.debian.org/releases/testing/releasenotes.

Praktyczny poradnik traktujący o instalacji nowej dystrybucji na poprzednią jest zawarty w Zarządzanie pakietami Debiana, Część 6. Ten rozdział opisuje podstawowe szczegóły.

2.3.1 Sposoby aktualizacji systemu Debian

Zawsze można użyć anonimowego FTP lub programu wget, aby dostać się do sieciowego archiwum Debiana, przeszukać katalogi, znaleźć żądany plik, pobrać go i wreszcie zainstalować przy pomocy dpkg (dpkg instaluje nowe pakiety na właściwym miejscu, również na działającym systemie). Czasami jednak nowa wersja jednego pakietu wymaga instalacji nowej wersji innego pakietu, co może prowadzić do uniemożliwienia instalacji żądanego pakietu do czasu zainstalowania tego drugiego, wymaganego.

Dla wielu osób takie ręczne podejście jest zbyt czasochłonne, ze względu na fakt, że Debian tak szybko ewoluuje - co tydzień dochodzi tuzin lub więcej nowych pakietów. Tuż przed dużymi wydaniami ta liczba jeszcze rośnie. Żeby sobie dać radę z taką lawiną, wiele osób preferuje używanie zautomatyzowanego oprogramowania. Do tego celu powstało kilka wyspecjalizowanych narzędzi do zarządzania pakietami.

2.3.2 Przegląd narzędzi do zarządzania pakietami

System zarządzania pakietami w Debianie posiada dwa cele: manipulacja samymi pakietami oraz pobieranie plików wraz z pakietami z archiwum pakietów. Pierwsze zadanie jest wykonywane przez dpkg, drugie - przez APT i dselect

2.3.3 dpkg

Jest to główny program do manipulacji plikami z pakietami. Pełny opis można znaleźć w dpkg(8).

dpkg występuje w towarzystwie kilku prostych programów pomocniczych:

dpkg-ftp i dpkg-mountable zostały zastąpione przez system APT.

2.3.4 APT

APT (skrót od Advanced Packaging Tool - Zaawansowane Narzędzie Pakietujące) jest zaawansowanym interfejsem do debianowego systemu zarządzania pakietami składającym się z kilku programów, których nazwy z reguły zaczynają się od „apt-”. apt-get, apt-cache i apt-cdrom są działającymi w środowisku znakowym narzędziami do obsługi pakietów. Są również używane jako „back end” (program wykonujący właściwą pracę pod osłoną interfejsu ułatwiającego użytkownikowi obsługę) dla innych narzędzi takich, jak dselect i aptitude.

Więcej informacji można uzyskać, instalując pakiet apt i czytając apt-get(8), apt-cache(8), apt-cdrom(8), apt.conf(5), sources.list(5), apt_preferences(5) (Woody) oraz /usr/share/doc/apt/guide.html/index.html.

Innym źródłem informacji może być również APT HOWTO, dostępny po zainstalowaniu pakietu apt-howto jako /usr/share/doc/Debian/apt-howto/.

apt-get upgrade i apt-get dist-upgrade pobierają tylko pakiety wymienione w polach „Depends:” i ignorują wszystkie pakiety wymienione w polach „Recommends:” i „Suggests:”. Jeżeli się tego nie lubi, używa się dselect.

2.3.5 dselect

dselect jest zaopatrzonym w menu, interfejsem systemu zarządzania pakietami w Debianie. Jest szczególnie użyteczny przy okazji pierwszych instalacji i większych aktualizacji. Zobacz dselect, Rozdział 6.2.3.

Więcej informacji zawiera dokument /usr/share/doc/install-doc/dselect-beginner.en.html z pakietu install-doc lub dselect Documentation for Beginners (Dokumentacja dselect dla początkujących).

2.3.6 Aktualizacja działającego systemu

Kernel i system plików używane w Debianie umożliwiają zastępowanie jednych plików drugimi nawet wtedy, gdy są one właśnie używane.

Dostarczamy również program o nazwie start-stop-daemon, używany do uruchamiania demonów (pracujących w tle programów użytkowych) przy starcie systemu i do ich zatrzymywania podczas zmiany trybu pracy kernela (np. z trybu wieloużytkownikowego na jednoużytkownikowy lub na „halt”). Tego samego programu używają skrypty instalacyjne, gdy instalowany jest nowy pakiet zawierający demony - do ich zatrzymywania i uruchamiania w miarę potrzeb.

Nawiasem mówiąc, Debian nie wymaga, aby system poddawany aktualizacji pracował w trybie jednoużytkownikowym.

2.3.7 Pobrane i chwilowo zapisane na dysku pliki .deb

Jeżeli ręcznie pobrałeś pliki pakietów na dysk (co nie jest absolutnie konieczne, wystarczy zapoznać się z wyżej zamieszczonym opisem dpkg-ftp lub APT), to po ich zainstalowaniu możesz usunąć ze swojego systemu pliki .deb.

W wypadku użycia programu APT, pakiety są zapisywane w katalogu /var/cache/apt/archives/. Można je skasować po zainstalowaniu (apt-get clean) albo skopiować do katalogu /var/cache/apt/archives/ na innej maszynie, aby nie ściągać ich kolejny raz przy powtórnych instalacjach.

2.3.8 Rejestracja zmian w pakietach

dpkg rejestruje pakiety, które rozpakowano, skonfigurowano, usunięto częściowo lub całkowicie, ale (przynajmniej obecnie) nie przechowuje rejestru tego, co się działo na konsoli w czasie poddawania pakietów tym działaniom.

Najprostszym sposobem obejścia tego problemu jest uruchamianie sesji dpkg, dselect, apt-get itd. przy pomocy programu script (script(1)).

2.4 Proces ładowania systemu w Debianie

2.4.1 Program init

Jak wszystkie Uniksy, Debian ładuje się do pamięci wykonując program init. W pliku konfiguracyjnym programu init (/etc/inittab) jest zapisane, że w pierwszej kolejności ma być wykonany skrypt /etc/init.d/rcS. Uruchamia on wszystkie skrypty znajdujące się w katalogu /etc/rcS.d/ poprzez nowe podprocesy lub ich kopie, zależnie od rozszerzenia nazwy pliku, wykonując inicjalizację systemu, w skład której wchodzi sprawdzanie i montowanie systemów plików, ładowanie modułów, uruchamianie usług sieciowych, ustawianie zegara i in. Następnie, dla kompatybilności z innymi systemami, uruchamia skrypty umieszczone w katalogu /etc/rc.boot/ (z wyjątkiem tych, których nazwy zawierają „.”). Skrypty umieszczone w tym katalogu są zwykle zarezerwowane do wyłącznego użytku administratora i używanie ich w pakietach nie jest pochwalane. Więcej informacji można znaleźć w Podręczniku Polityki Debiana w Inicjalizacja systemu, Rozdział 9.1 i System run levels and init.d scripts.

2.4.2 Poziomy startu (Runlevels)

Po załadowaniu systemu, init wykonuje wszystkie skrypty startowe w katalogu określonym przez domyślny poziom startu (default runlevel, wpis id w pliku /etc/inittab). Jak większość Uniksów kompatybilnych z System V, Linux ma 7 poziomów startu:

W Debianie ustawia się id=2, co oznacza, że domyślny poziom startu po wejściu w tryb wieloużytkownikowy wynosi 2, a uruchomieniu podlegają skrypty znajdujące się w katalogu /etc/rc2.d/.

W rzeczywistości skrypty w każdym z katalogów /etc/rcN.d/ są tylko symbolicznymi dowiązaniami (symlinkami) do skryptów w /etc/init.d/. Ich nazwy natomiast dobiera się tak, aby odzwierciedlały sposób, w jaki zostaną uruchomione skrypty znajdujące się w /etc/init.d/. W szczególności, przed wejściem na którykolwiek poziom startu uruchomione zostają wszystkie skrypty o nazwach zaczynających się na „K”; są to skrypty wyłączające usługi. Następnie uruchomione zostają skrypty o nazwach zaczynających się na „S”, które są skryptami uruchamiającymi usługi. Dwucyfrowa liczba występująca po „K” lub „S” określa kolejność, w jakiej skrypty zostaną uruchomione. Skrypty z mniejszymi liczbami są uruchamiane w pierwszej kolejności.

To wszystko działa, ponieważ skrypty w /etc/init.d/ pobierają argument, którego wartością może być „start”, „stop”, „reload”, „restart” lub „force-reload” i wykonują zadanie określone przez ten właśnie argument. Skryptów tych można używać również po załadowaniu systemu, sterując w ten sposób różnymi procesami.

Na przykład, (z argumentem „reload”) polecenie 

     # /etc/init.d/exim4 reload

wysyła demonowi programu exim4 polecenie powtórnego wczytania pliku konfiguracyjnego.

2.4.3 Modyfikacje procesu ładowania

Debian nie korzysta z pochodzącego z BSD katalogu rc.local w celu dostosowywania procesu ładowania do jakichś szczególnych życzeń użytkownika; zamiast tego oferuje następujący mechanizm.

Załóżmy, że system powinien wykonać skrypt foo przy starcie lub podczas wchodzenia na któryś z poziomów startu. Administrator powinien wtedy:

  1. Umieścić skrypt foo w katalogu /etc/init.d/.

  1. Uruchomić występujące w Debianie polecenie update-rc.d z odpowiednimi argumentami, ustawiając w ten sposób dowiązania między wymienionymi w wierszu poleceń plikami w katalogach rc?.d a /etc/init.d/foo, gdzie ? jest liczbą od 0 do 6 odpowiadającą jednemu z poziomów startu (runlevel) Systemu V.

  1. Przeładować system.

Polecenie update-rc.d ustawi dowiązania między plikami w katalogach rc?.d a skryptem w /etc/init.d/. Nazwa każdego z dowiązań będzie się zaczynać od litery „K” lub „S”, po której wystąpi liczba oraz nazwa skryptu. Gdy system osiągnie poziom startu N, skrypty z /etc/init.d/ posiadające w katalogu /etc/rcN.d/ dowiązania o nazwach zaczynających się na „K” są wykonywane z argumentem stop, następnie są wykonywane skrypty, nazwy odniesień do których zaczynają się na „S”, przyjmując za argument start.

Można, na przykład, spowodować uruchomienie skryptu foo w toku sekwencji startowej umieszczając go w /etc/init.d/ i instalując dowiązania poleceniem update-rc.d foo defaults 19. Argument defaults odnosi się do domyślnych poziomów startu (od 2 do 5). Argument 19 gwarantuje, że foo zostanie uruchomiony przed którymkolwiek skryptem zawierającym liczbę 20 lub większą.

2.5 Wsparcie dla różnorodności

Debian oferuje wiele sposobów spełniania życzeń administratora systemu bez groźby uszkodzenia systemu.

Wszystkie pliki w podkatalogach katalogu /usr/local/ należą do administratora systemu i Debian ich nawet nie tknie. Większość (lub wszystkie) plików w podkatalogach /etc to pliki konfiguracyjne i Debian nie nadpisze ich w trakcie instalacji nowszych wersji pakietów, chyba, że administrator wyraźnie sobie tego zażyczy.

2.6 Internacjonalizacja

System Debian jest zinternacjonalizowany: obsługuje wyświetlanie i wprowadzanie znaków w wielu językach, tak na konsoli tekstowej, jak i w Xach. Wiele dokumentów, stron podręcznika systemowego man i komunikatów systemu przetłumaczono i tłumaczy się na coraz większą liczbę języków. W trakcie instalacji, Debian zachęca użytkownika do wybrania języka instalacji (czasem nawet lokalnego dialektu).

Jeżeli zainstalowany przez Ciebie system nie obsługuje wszystkich właściwości językowych, których potrzebujesz, lub jeżeli chcesz zmienić język lub zainstalować inną klawiaturę, która obsługiwałaby Twój język, zapoznaj się z Lokalizacja, Rozdział 9.7.

2.7 Debian i kernel

Zobacz Jądro systemu Linux w Debianie, Część 7.

2.7.1 Kompilacja jądra ze źródeł innych, niż debianowe

Trzeba zrozumieć obowiązujące w Debianie zasady postępowania odnośnie plików nagłówkowych.

Biblioteki C w Debianie buduje się z wykorzystaniem najnowszych stabilnych wydań plików nagłówkowych jądra (kernel) (Na przykład, Debian-1.2 używał plików nagłówkowych jądra w wersji 5.4.13).

Taka praktyka jest w kontraście ze wszystkimi pakietami zawierającymi pliki źródłowe jądra, które wykorzystują również nowsze wersje plików nagłówkowych. Pliki nagłówkowe jądra rozpowszechniane z jego źródłami są umieszczone w katalogu /usr/include/linux/include/.

W razie potrzeby kompilacji programu wymagającego plików nagłówkowych kernela w wersji nowszej, niż zawarte w pakiecie libc6-dev, trzeba do linii poleceń w trakcie kompilacji dodać -I/usr/src/linux/include/. Coś takiego w pewnym momencie przydarzyło się na przykład pakietowi demona automountera (amd). Gdy nowsze jądro zmieniło trochę funkcji obsługujących NFS, amd musiał zostać o tym powiadomiony, co wymagało dołączenia najnowszej wersji plików nagłówkowych jądra.

2.7.2 Narzędzia do tworzenia jądra

Użytkowników, którzy chcą (albo muszą) utworzyć własne pakiety kernela, zachęcamy do instalacji pakietu kernel-package. Zawiera on skrypt umożliwiający zbudowanie pakietu zawierającego jądro, umożliwiając w ten sposób utworzenie Debianowego pakietu zawierającego już skompilowane jądro przez wydanie polecenia 

     # make-kpkg kernel_image

w katalogu /usr/src/linux/. Bardziej szczegółowych informacji udostępnia polecenie 

     # make-kpkg --help

oraz strona podręcznika systemowego make-kpkg(1) i Jądro systemu Linux w Debianie, Część 7.

Użytkownicy chcący skompilować najnowszy kernel (albo po prostu dowolny, wymarzony) muszą samodzielnie pobrać kod źródłowy ze swojego ulubionego archiwum sieciowego, o ile nie jest dostępny pakiet kernel-source-version, gdzie version oznacza wersję kernela. Skrypt startowy initrd wymaga specjalnej łaty na kernel o nazwie initrd; zobacz http://bugs.debian.org/149236.

Szczegółową instrukcję użytkowania pakietu kernel-package można znaleźć w pliku /usr/doc/kernel-package/README.gz.

2.7.3 Specjalne wyposażenie do obsługi modułów jądra

Pakiet modconf zawiera skrypt /usr/sbin/modconf, którego można używać w celu wprowadzania własnych modyfikacji do konfiguracji modułów. Skrypt ten wyświetla menu, wypytując użytkownika o szczegóły dotyczące ładowanych sterowników urządzeń w jego systemie. Na podstawie udzielonych odpowiedzi przeprowadzana jest modyfikacja pliku /etc/modules.conf (wyszczególniającego aliasy i inne argumenty, których należy użyć w połączeniu z różnymi modułami), w powiązaniu z plikami w /etc/modutils/ i plikiem /etc/modules (zawierającym spis modułów, które trzeba załadować przy starcie systemu).

Podobnie jak źródła kernela zostały wyposażone w plik Configure.help, ułatwiający konfigurację kerneli własnej produkcji, tak i pakiet modconf daje do dyspozycji serię plików pomocy (w /usr/share/modconf/), dostarczających szczegółowych informacji na temat odpowiednich argumentów dla każdego modułu. Przykłady można znaleźć w Zmodularyzowane jądro 2.4, Rozdział 7.2.

2.7.4 Usuwanie starego pakietu z jądrem

Skrypt kernel-image-NNN.prerm sprawdza, czy kernel, który jest aktualnie załadowany, nie jest tym samym, który usiłujemy odinstalować. Można więc niechciane pakiety kerneli usuwać używając polecenia 

     # dpkg --purge --force-remove-essential kernel-image-NNN

(Oczywiście, w miejsce NNN trzeba wpisać wersję i podwersję usuwanego kernela).

[ powrót ] [ Spis treści ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ A ] [ dalej ]

Debian Reference

CVS, czwartek, 18 styczeń 2007, 11:53:26 UTC

Osamu Aoki osamu#at#debian.org
Koordynator tłumaczenia: Bartosz Feński aka fEnIo fenio@o2.pl
Autorzy, Rozdział A.1