PLD-doc/book/pl_book__pakiety: pl_pakiety__cechy.sec wprowadzenie.sec
qwiat
cvs w pld-linux.org
Pon, 16 Sty 2006, 02:12:50 CET
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>
Więcej informacji o liście dyskusyjnej pld-doc