PLD-doc/queue/zarzadzanie_pakietami_wstep.txt

[qwiat]

Author: qwiat
Date: Thu Oct  7 19:47:39 2004
New Revision: 4721

Modified:
   PLD-doc/queue/zarzadzanie_pakietami_wstep.txt
Log:
-dopiesczanie


Modified: PLD-doc/queue/zarzadzanie_pakietami_wstep.txt
==============================================================================
--- PLD-doc/queue/zarzadzanie_pakietami_wstep.txt	(original)
+++ PLD-doc/queue/zarzadzanie_pakietami_wstep.txt	Thu Oct  7 19:47:39 2004
@@ -16,15 +16,15 @@
 W świecie Otwartego Oprogramowania pomiędzy programami istnieją liczne
 powiązania, które w efekcie wymuszają konieczność instalacji dodatkowych
 programów i/lub bibliotek. Pominięcie tych zależności spowoduje
-problemy z działaniem programu lub całkowity brak działania. Śledzenie tych
+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.
 
 Elementy systemu operacyjnego dostępne są w tzw. pakietach (pot. "paczkach").
-Pakiety mogą zawierać wiele małych programów i/lub bibliotek, ale też jeden
+Pakiety mogą zawierać wiele małych programów i/lub bibliotek, lub jeden
 duży program może być podzielony na kilka pakietów. W większości wypadków
-stosowane jest to drugie rozwiązanie: osobno przechowywane są pliki
+stosowane jest to drugie rozwiązanie - osobno przechowywane są pliki
 uruchomieniowe, osobno biblioteki, a jeszcze osobno dodatkowe moduły, wtyczki
 i inne dodatki. Pozwala to instalować tylko to co jest nam potrzebne. Przykładowo
 jeśli jakiś program wymaga bibliotek innego programu to instalujemy tylko
@@ -40,8 +40,8 @@
 dostępnym systemem zarządzania pakietami.
 
 Używając PLD mamy do wyboru dwa menadżery pakietów. Stworzony na potrzeby PLD
-program poldek, oraz klasyczny program rpm. Pierwszy jest narzędziem o ogromnych
-możliwościach, pozwalającym na znaczną automatyzację procesu zarządzania
+program poldek, oraz klasyczny program rpm. Pierwszy z nich jest narzędziem o
+ogromnych możliwościach, pozwalającym na znaczną automatyzację procesu zarządzania
 dużymi ilościami pakietów. Jest "wołem roboczym" odciążającym administratora w
 tym żmudnym zajęciu, dzięki czemu świetnie nadaje się do codziennego użytkowania.
 
@@ -55,7 +55,7 @@
 ------------------------------
 program.arch.rpm, program-core.arch.rpm - głowny pakiet programu
 program-libs.arch.rpm - zestaw biblioteki stworzonych na potrzeby danego programu
-program-mod.arch.rpm, program-plugin.arch.rpm - różnej maści "wtyczki"
+program-mod.arch.rpm, program-plugin.arch.rpm, program-applets.arch.rpm - różnej maści "wtyczki", applety i dodatki
 program-skin(s).arch.rpm - "skórki" zmiany wyglądu
 program-theme(s).arch.rpm - "tematy" zmiany wyglądu
 program-driver.arch.rpm - sterowniki
@@ -69,27 +69,38 @@
 
 Architektury
 ------------
-Ciąg znaków "arch" przy rozszerzeniu określa architekturę dla jakiej został
-stworzony. W PLD dostępne są następujące architektury: alpha, amd64, athlon,
-i386, i586, i686, ppc, sparc. Można się spotkać także z oznaczenie noarch,
-które oznacza tyle że jest to pakiet uniwersalny i można go stosować dla każdej
+W powyższej liście ciąg znaków "arch" znajdujący się tuż przy rozszerzeniu pliku
+określa architekturę dla jakiej pakiet został przygotowany.
+W PLD programy są kompilowane dla różnych architektur sprzętowych, pozwala to
+na używanie systemu na bardziej różnorodnym sprzęcie, oraz na lepsze dopasowanie
+do używanej architektury. Wybór konkretnej architektury dokonuje się poprzez
+wybór odpowiedniego katalogu na serwerze ftp: 
+ftp.pld-linux.org/dists/{WERSJA}/PLD/{ARCHITEKTURA}.
+Przykładowo adres: ftp://ftp.pld-linux.org/dists/2.0/PLD/i686/ dotyczy systemu
+w wersji 2.0 (Ac) z wybraną architekturą "i686". Oto lista wszystkich dostępnych
+architektur dla PLD 2.0: alpha, amd64, athlon, i386, i586, i686, ppc, sparc.
+Aby pobierać pakiety z właściwej architektury programem poldek trzeba aby ustawić
+odpowiedni adres w pliku konfiguracji programu poldek.
+
+W przypadku niektórych pakietów można się spotkać z oznaczeniem "noarch",
+oznacza ono tyle że jest to pakiet uniwersalny i można go stosować dla każdej
 architektury. Należy pamiętać by instalować pakiety wyłącznie przeznaczone dla
 używanej architektury. Nieco inaczej jest w przypadku architektur przeznaczonych
 dla procesorów firmy Intel i zgodnych: i386, i586, oraz i686. Pakiety dla
 "starszych" wersji procesorów mogą działać na maszynach z nowszymi procesorami,
 ale na odwrót już nie. Przykładowo na maszynie z procesorem Pentium III (i686)
-możemy zainstalować system w wersji i386, ale na procesorze 486-DX wersja i686
+możemy zainstalować system w wersji i386, ale na procesorze 386 wersja i686
 nie będzie działać.
 
 Lista procesorów i odpowiadających im architektur:
 
 alpha:	?
-amd64:  AMD K8 (Athlon 64)
+amd64:	AMD K8 (Opetron, Athlon 64)
 athlon:	AMD K7 (Athlon, Duron)
-i386:	386-SX/DX, 486-SX/DX, AMD K5 (wersje Socket 3)
-i586:	Pentium, Pentium-MX, Cyrix 5x86, AMD K5 (wersje Socket7) i AMD K6
-i686:	Penium-II/Celeron, Pentium-III/Celeron-II, Pentium 4, AMD K7 (Athlon, Duron)
-ppc:	?
+i386:		386-SX/DX, 486-SX/DX, AMD K5 (wersje Socket 3)
+i586:		Pentium, Pentium-MX, Cyrix 5x86, AMD K5 (wersje Socket7) i AMD K6
+i686:		Penium-II/Celeron, Pentium-III/Celeron-II, Pentium 4, AMD K7 (Athlon, Duron)
+ppc:		?
 sparc:	?
 
 <!-- nie znam innych architektur tak więc może ktoś kto się zna może się
@@ -101,19 +112,19 @@
 Polityka zarządzania plikami przez pakiety
 ------------------------------------------
 Zarządzanie pakietami w PLD to sama przyjemność. Jeśli instalujemy w systemie
-nową usługę/podsystem to zostanie ona włączona do skryptów startowych i
-uruchomi się przy zmianie trybu pracy, restarcie systemu, lub po ręcznym
-uruchomieniu. Jeśli dana usługa lub podsystem są wyłączone z działania
-to po aktualizacji dalej nie będą uruchamiane.
+nową usługę to zostanie zapisana odpowiednia informacja 
+do skryptów startowych i zainstalowane oprogramowanie uruchomi się przy
+zmianie trybu pracy, restarcie systemu. Jeżeli jakaś usługa jest
+wyłączone z działnia i zostanie zaktualizowana to dalej nie będzie uruchamiana.
 
 Podobnie kurtuazyjnie traktuje pliki konfiguracyjne programów, po
 aktualizacji pakietu nie są ruszanie istniejące pliki konfiguracji, nowe
 pliki konfiguracji programu są zapisywane z końcówką ".rpmnew". Przykładowo
 po zaktualizowaniu pakietu sudo obok pliku /etc/sudoers pojawi się
-/etc/sudoers.rpmnew. Tak więc zaktualizowany program będzie działał na
-"starym" pliku konfiguracji. W większości wypadków nie będzie to
-stanowić problemu, jednak dla pewności należy skonfigurować plik z
-rozszerzeniem ".rpmnew" na wzór poprzedniej konfiguracji i zmienić mu
+/etc/sudoers.rpmnew. Tak więc zaktualizowany program będzie używał 
+"starego" pliku konfiguracji. W większości wypadków nie będzie to
+stanowić problemu, jednak dla pewności należy skonfigurować dostarczony z
+nowszym pakietem na wzór poprzedniej konfiguracji i zmienić mu
 nazwę poprzez usunięcie omawianego rozszerzenia. Jest to pierwsza rzecz, którą
 należy sprawdzić w przypadku problemów z działaniem programu po aktualizacji.
 
@@ -122,18 +133,6 @@
 że są nam zbędne, łatwo je odnajdziemy gdyż nadawane im jest rozszerzenie
 ".rpmsave".
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+Jak widać zarządzanie pakietami w PLD jest tak skonstruowane, aby nie zaskakiwać
+administratora w najmniej oczekiwanych momentach, oraz zapewnić nieprzerwanie
+działanie systemu.
\ No newline at end of file