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.
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/:pool/:tools/:doc/:indices/:project/:project/experimental/:project/orphaned/:
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.
Dane pakietów należących do dystrybucji stabilnej, Debian Woody
(3.0r0), są zapisywane do katalogu stable (dowiązanie symboliczne
do Woody/):
stable/main/: Ten katalog zawiera pakiety oficjalnie uznawane za
najbardziej aktualne wydanie systemu Debian.
Wszystkie z tych pakietów są zgodne z Wytycznymi Debiana
dotyczącymi Wolnego Oprogramowania (dokument dostępny również jako
/usr/share/doc/debian/social-contract.txt po zainstalowaniu
pakietu debian-doc) i można ich swobodnie używać, a także
rozpowszechniać.
stable/non-free/: Ten katalog zawiera informacje o pakietach,
których rozpowszechnianie zostało ograniczone przez wymagania stawiane
dystrybutorowi, które mówią o zwróceniu szczególnej uwagi, na kwestie praw
autorskich danego programu.
Na przykład, licencje niektórych pakietów zabraniają komercyjnego rozpowszechniania. Inne znowuż mogą być redystrybuowane, ale stanowią shareware, a nie wolne oprogramowanie. Zanim włączy się którykolwiek z tych pakietów do jakiejś redystrybucji (np. na CD-ROMie), należy przestudiować jego licencję i prawdopodobnie przeprowadzić odpowiednie negocjacje.
stable/contrib/: Ten katalog zawiera informacje o pakietach
wolnych w rozumieniu DFSG (Debian Free Software Guidelines) i podlegających
swobodnemu rozpowszechnianiu, ale w jakiś sposób zależnych od
pakietu, który swobodnemu rozpowszechnianiu nie podlega i z
tej przyczyny jest dostępny w sekcji non-free.
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) .
Informacja o pakietach zawartych w dystrybucji testowej, czyli
Debian Sarge, jest zapisywana w katalogu testing (dowiązanie
symboliczne do Sarge/) 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:
update
excuses (wymówki aktualizacyjne)
testing
problems (problemy w dystrybucji testowej)
release-critical bugs
(błędy o znaczeniu krytycznym dla wydania)
base system bugs
(błędy w systemie podstawowym)
bugs in standard
and task packages (błędy w pakietach kategorii standard i task)
other bugs and bug-squashing party
notes (inne błędy i uwagi z sesji tępienia pluskiew)
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.
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”. (Ostatnio proces wydania dystrybucji woody
nie utworzył dowiązania symbolicznego frozen/, więc
frozen nie było dystrybucją, a tylko etapem rozwoju dystrybucji
testowej).
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.
Nazwy rzeczywistych podkatalogów w katalogu dists, na przykład
Woody i Sarge, 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
Woody/, a testing/ dowiązaniem do
Sarge/. Oznacza to, że Woody jest aktualną
dystrybucją stabilną, a Sarge testową.
unstable/ jest już na zawsze dowiązaniem symbolicznym do
sid/, ponieważ Sid jest zawsze dystrybucją niestabilną.
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.
Jak dotychczas wybierano postaci z filmu Toy Story produkcji Pixar.
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).
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).
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.
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/.
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.
binary-all/, dla pakietów niezależnych od architektury (dotyczy to
np. skryptów Perla lub czystej dokumentacji).
binary-platform/, dla pakietów przeznaczonych dla
konkretnej architektury.
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.
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.
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:
dpkg; ze szczegółami
można się zapoznać czytając stronę podręcznika systemowego poświęconą dpkg.
dpkg-source;
szczegóły są dostępne po zapoznaniu się z poświęconą mu stroną podręcznika
systemowego man.
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:
„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(8).
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.
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.
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).
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:
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).
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:
W ich skład wchodzą wszystkie narzędzia konieczne do naprawy uszkodzeń systemu.
Nie wolno ich usuwać, bo system może ulec totalnej zapaści, która uniemożliwi
nawet użycie dpkg do próby jego odtworzenia. Systemy zawierające
wyłacznie pakiety o priorytecie Required najprawdopodobniej nie nadają się do
wielu rzeczy, ale posiadają funkcjonalność wystarczającą do ich uruchomienia i
instalacji dodatkowego oprogramowania.
Inne pakiety, bez których system nie będzie dobrze działał, lub nie będzie użyteczny, będą posiadać również ten priorytet. Nie należą do nich Emacs, X11, TeX czy inne duże aplikacje. Pakiety o priorytecie Important tworzą zaledwie gołą infrastrukturę.
Pakiety o tym priorytecie zainstalują się domyślnie, jeżeli użytkownik nie wybierze nic ponadto. Grupa Standard zawiera niewiele dużych aplikacji, ale zawiera Emacs (jest on bardziej elementem infrastruktury, niż aplikacją) i rozsądny wybór z TeX-a i LaTeX-a (to, czego można używać bez X).
W skład tej grupy wchodzą X11, pełna dystrybucja TeX-a i mnóstwo aplikacji.
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".
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.
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.
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.
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:
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.
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)).
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.
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/.
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.
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.
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
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-deb: Manipulacja plikami .deb.
dpkg-deb(1)
dpkg-ftp: Starszy program do pobierania plików z pakietami.
dpkg-ftp(1)
dpkg-mountable: Starszy program do pobierania plików z pakietami.
dpkg-mountable(1)
dpkg-split: Dzieli duży pakiet na mniejsze pliki.
dpkg-split(1)
dpkg-ftp i dpkg-mountable zostały zastąpione przez
system 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.
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).
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.
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.
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)).
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.
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.
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:
/etc/init.d/.
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.
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ą.
Debian oferuje wiele sposobów spełniania życzeń administratora systemu bez groźby uszkodzenia systemu.
dpkg-divert, zobacz Polecenie dpkg-divert,
Rozdział 6.5.1.
equivs, zobacz Pakiet
equivs, Rozdział 6.5.2.
update-alternatives, zobacz Alternatywne polecenia, Rozdział
6.5.3.
make-kpkg może zadowolić wymagania stawiane przez wiele
bootloaderów. Zobacz make-kpkg(1) i Standardowa metoda Debiana, Rozdział
7.1.1.
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.
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.
Zobacz Jądro systemu Linux w Debianie, Część 7.
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.
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(8) 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.
Aby skorzystać alternatywnych bootloaderów (grub lub
loadlin), należy skopiować skompilowany kernel (plik
bzImage) w inne miejsce, np. do katalogu /boot/grub
lub na partycję MS-DOS.
Wykonywanie własnych dyskietek startowych jest w dużym stopniu ułatwione przez
pakiet boot-floppies. Można go znaleźć w sekcji
admin sieciowych archiwów Debiana. Skrypty zawarte w tym pakiecie
tworzą dyskietki startowe w formacie syslinux. Są to dyskietki
sformatowane w formacie MS-DOS, których główne rekordy ładujące (master boot
records) zmieniono tak, aby bezpośrednio ładowały Linuksa (albo jakikolwiek
inny system operacyjny, który określono w pliku syslinux.cfg na
dyskietce). Inne skrypty z tego pakietu tworzą dyskietki ratunkowe lub nawet
podstawowe dyskietki instalacyjne.
Więcej informacji na ten temat można znaleźć w pliku
/usr/doc/boot-floppies/README po zainstalowaniu pakietu
boot-floppies.
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.
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).
Debian Reference
CVS, poniedziałek, 3 kwiecień 2005, 22:58:23 UTCosamu@debian.orgfenio@o2.pl