Author: qwiat
Date: Mon Jan 16 02:12:47 2006
New Revision: 6816
Modified:
PLD-doc/book/pl_book__pakiety/pl_pakiety__cechy.sec
PLD-doc/book/pl_book__pakiety/wprowadzenie.sec
Log:
- duze porzadki
Modified: PLD-doc/book/pl_book__pakiety/pl_pakiety__cechy.sec
==============================================================================
--- PLD-doc/book/pl_book__pakiety/pl_pakiety__cechy.sec (original)
+++ PLD-doc/book/pl_book__pakiety/pl_pakiety__cechy.sec Mon Jan 16 02:12:47 2006
@@ -5,17 +5,43 @@
<section id="pakiety_cechy_zaleznosci">
<title>Zależności między pakietami</title>
<para>
- Istotną cechą pakietów RPM są tzw.
<emphasis>zależności</emphasis>,
+ Istotną cechą pakietów RPM jest mechanizm tzw.
+ <emphasis>zależności</emphasis>,
dzięki nim w trakcie instalacji pakietu instalowane są
- automatycznie dodatkowe wymagane pakiety (o ile są
dostępne).
- Istnieją też zależności wymagające wzajemnego
wykluczania się
+ automatycznie dodatkowe wymagane pakiety.
+ Niekiedy w ramach zależności wymagana jest
funkcjonalność
+ dostarczana przez więcej niż jeden pakiet. W takim
wypadku
+ zostaniemy zapytani o to który pakiet ma być
zainstalowany.
+ Wynika to z filozofii PLD, która dopuszcza bogaty wybór
+ oprogramowania spełniającego tą samą rolę.
+ </para>
+ <para>
+ Istnieją zależności wymagające wzajemnego wykluczania
się
pakietów, tak aby w systemie była zainstalowany był
tylko
- jeden program z pośród kilku dostępnych (np. serwery
usług).
+ jeden program z pośród kilku dostępnych. Jako przykład
+ można wskazać serwery usług tego samego rodzaju
+ lub pakiety zawierające w nazwie słowa "inetd" oraz
+ "standalone".
</para>
<para>
- Menadżery pakietów pozwalają na ignorowanie zależności,
jest
- to jednak operacja niezalecana, gdyż powoduje później
trudny
- do ogarnięcia bałagan.
+ Dodatkowo system pakietów pilnuje, aby nie można było
mieć
+ zainstalowanych dwóch wersji tego samego pakietu.
+ Próba instalacji pakietu starszego niż ten, który mamy
+ w systemie zakończy się niepowodzeniem, zaś przy
+ instalacji nowszego nastąpi jego aktualizacja.
+ </para>
+ <para>
+ Menadżery pakietów pozwalają na ignorowanie powyższych
+ zależności, jest to jednak operacja niezalecana, gdyż
+ powoduje później trudny do ogarnięcia bałagan.
+ Wyjątki od tej zasady powinny być
+ robione jedynie w razie uzasadnionej konieczności,
+ takim wyjątkiem jest np. wymuszenie instalacji innej
wersji
+ jądra zamiast aktualizacji. Co więcej jest to nawet
+ zalecane działanie, ze względu na kluczowe znaczenie
+ jądra. W przypadku aktualizacji nie mieli byśmy
możliwości
+ łatwego powrotu do starej wersji gdyby z nowym, były
+ jakieś problemy.
</para>
<para>
Dawniej zależności były budowane na podstawie nazw
pakietów,
@@ -26,9 +52,46 @@
odczujemy większych różnic i nie musimy się tym martwić.
</para>
</section>
-
-
-
+
+ <section id="pakiety_cechy_zawartosc">
+ <title>Zawartość pakietów</title>
+ <para>
+ Pakiety mogą zawierać wiele małych programów
+ i/lub bibliotek albo jeden duży program może być
podzielony na
+ kilka pakietów. W PLD najczęściej stosowane jest to
drugie
+ rozwiązanie: osobno przechowywane są pliki
uruchomieniowe,
+ osobno biblioteki, a jeszcze osobno moduły, wtyczki i
dodatki.
+ Ponadto jeśli tylko można to są umieszczane w
pojedynczych
+ pakietach, dzięki temu unikamy dużych, zbiorczych
paczek.
+ Pozwala to instalować tylko to co jest nam potrzebne.
+ Przykładowo jeśli program <emphasis>ABC</emphasis>
wymaga
+ bibliotek programu <emphasis>XYZ</emphasis>
+ to instalujemy tylko pakiet z bibliotekami tego
drugiego.
+ Skraca to czas instalacji (zwłaszcza przy pobieraniu
plików
+ z Internetu) i pozwala oszczędzać miejsce na dysku.
+ </para>
+ <para>
+ Nierzadko do osobnych pakietów trafiają elementy
aplikacji,
+ które zostały przewidziane przez jej twórców
+ jako kompletna instalacja. Nie należy się tego obawiać,
gdyż
+ mechanizm zależności wymusi instalację wszystkich
wymaganych
+ dodatkowo pakietów.
+ </para>
+ <para>
+ Tak silne rozdrobnienie powoduje czasami, że do przy
+ instalacji mechanizm zależności zaznacza sporą ilość
+ dodatkowych pakietów. Potrafi to wprowadzić w
konsternację,
+ jednak nie należy się tego obawiać, gdyż są to zazwyczaj
+ małe pakiety i po zainstalowaniu zajmują tyle samo lub
mniej
+ niż domyślna instalacja.
+ </para>
+ <para>
+ Aby ułatwić poruszanie się w tym gąszczu pakietów
poniżej
+ zamieszczono tabelę dzięki której określimy zawartość
+ pakietu na podstawie jego nazwy.
+ </para>
+ </section>
+
<section id="pakiety_cechy_nazwy_pakietow">
<title>Konwencja nazw pakietów w PLD</title>
@@ -148,7 +211,8 @@
trybu pracy niektórych usług. Należy
wybrać jeden
z nich: uruchamianie przez
<productname>Inetd</productname> lub
praca w tle
- (standalone)
+ (standalone). Pakiety te wzajemnie się
wykluczają
+ na poziomie mechanizmu zależności.
</entry>
</row>
<row>
@@ -164,8 +228,13 @@
<section id="pakiety_cechy_system">
<title>Wpływ pakietów na pracę systemu</title>
<para>
- Ze względu na dopracowaną automatykę dostarczaną z
pakietami,
- zarządzanie nimi to czysta przyjemność.
+ Pakiety, oprócz plików programu, zawierają dokumentację,
+ przykładowe pliki konfiguracji, strony podręcznika
+ systemowego (man, info) oraz automatykę. Owa automatyka
+ jest uruchamiana w trakcie instalowania bądź
odinstalowania
+ pakietu i wykonuje konieczne prace w systemie. Dzięki
temu
+ zmniejsza się nakład pracy administratora do absolutnego
+ minimum.
Jest tak skonstruowana, aby nie zaskakiwać
administratora w
najmniej oczekiwanych momentach oraz zapewnić
nieprzerwanie
działanie systemu.
Modified: PLD-doc/book/pl_book__pakiety/wprowadzenie.sec
==============================================================================
--- PLD-doc/book/pl_book__pakiety/wprowadzenie.sec (original)
+++ PLD-doc/book/pl_book__pakiety/wprowadzenie.sec Mon Jan 16 02:12:47 2006
@@ -16,59 +16,51 @@
dodatkowych programów i/lub bibliotek. Pominięcie tych
zależności
spowoduje problemy z działaniem programu lub całkowity
jego brak.
Śledzenie tych zależności może przyprawić o ból głowy
większość
- administratorów. Na szczęście istnieją narzędzia, które
nie tylko
- pomagają zautomatyzować ten proces, ale też wspomagają
instalację,
- deinstalację i aktualizację oprogramowania.
+ administratorów. Na szczęście istnieją mechanizmy i
narzędzia,
+ które pomagają znacznie zautomatyzować ten proces.
</para>
</section>
<section id="pakiety_wprowadzenie_pakiety">
- <title>Pakiety</title>
+ <title>Pakiety w PLD</title>
<para>
Elementy systemu operacyjnego dostępne są w tzw.
<emphasis>pakietach</emphasis>
- (pot. "paczkach"). Pakiety mogą zawierać wiele małych
programów
- i/lub bibliotek albo jeden duży program może być
podzielony na
- kilka pakietów. W PLD najczęściej stosowane jest to
drugie
- rozwiązanie: osobno przechowywane są pliki
uruchomieniowe,
- osobno biblioteki, a jeszcze osobno moduły, wtyczki i
dodatki.
- Pozwala to instalować tylko to co jest nam potrzebne.
- Przykładowo jeśli program <emphasis>ABC</emphasis>
wymaga
- bibliotek programu <emphasis>XYZ</emphasis>
- to instalujemy tylko pakiet z bibliotekami tego
drugiego.
- Skraca to czas instalacji (zwłaszcza przy pobieraniu
plików
- z Internetu) i pozwala oszczędzać miejsce na dysku.
Jest to
- dość złożone zagadnienie, nie musimy się tym jednak
- przejmować, gdyż wszystko za nas wykona opisany w
- <xref linkend="pakiety_cechy" /> mechanizm tzw.
- <emphasis>zależności</emphasis>.
- </para>
- <para>
+ (pot. "paczkach").
W PLD zastosowano system pakietów
<productname>RPM</productname>
- (<productname>RPM Packet Manager</productname>).
- Jest to system stworzony przez twórców dystrybucji
- <productname>Red Hat Linux</productname>, który zyskał
na
- świecie dużą popularność i obecnie jest najbardziej
popularnym
- (i najpotężniejszym) dostępnym systemem zarządzania
pakietami.
+ (<productname>RPM Packet Manager</productname>), który
+ został stworzony przez twórców dystrybucji
+ <productname>Red Hat Linux</productname>.
Istnieje możliwość instalacji pakietów RPM
przygotowanych dla innych
dystrybucji, jednak nie skorzystamy wtedy z
dobrodziejstwa zależności
dotyczących danego pakietu. Wymagane dodatkowe pakiety
należy wtedy
zainstalować samodzielnie.
</para>
+ </section>
+
+ <section id="pakiety_wprowadzenie_pobieranie">
+ <title>Pobieranie pakietów</title>
<para>
Jedną z najczęściej używanych form instalacji jest
instalacja z sieci, dlatego jeśli nie zostanie podane
inaczej to właśnie taka instalacja jest traktowana
- jako domyślna.
- Stąd aby pobrać właściwe pakiety musimy określić
- trzy parametry: adres serwera, wersję systemu, źródło
- pakietów, oraz ich architekturę.
- Listę dostępnych serwerów odnajdziemy
- <xref linkend="linki_zrodla_pakietow" />, źródła zostały
- opisane w <xref linkend="pakiety_cechy_zrodla" />, zaś
- architektury w <xref linkend="pakiety_cechy_arch" />.
+ jako domyślna. Używamy tej metody nawet jeśli system był
+ instalowany z lokalnego źródła (np. z płyt optycznych),
+ choćby w celu aktualizacji systemu.
+ </para>
+ <para>
+ Do instalowania pakietów trzeba wskazać kilka
parametrów,
+ w celu określenia <emphasis>wersji systemu</emphasis>,
+ <emphasis>architektury sprzętowej</emphasis>, czy też
+ <emphasis>źródła</emphasis>. W większości wypadków
będziemy
+ mieli te parametry prawidłowo ustawione w konfiguracji
+ <productname>Poldka</productname>. Jeśli jednak musimy
+ je zmodyfikować bądź pobrać pakiet w inny sposób to
+ musimy poprawnie podać ścieżkę do zasobu wg. schematu
+ opisanego w
+ <xref linkend="linki_zrodla_pakietow" />.
</para>
</section>
_______________________________________________
pld-cvs-commit mailing list
[email protected]
http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit
