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