PLD-doc/book: pl_book__master.docb pl_book__pakiety/pl_pakiety.chp pl_book__pakiety/pl_pakiety__cech...
qwiat
cvs w pld-linux.org
Czw, 29 Gru 2005, 23:42:00 CET
Author: qwiat
Date: Thu Dec 29 23:41:55 2005
New Revision: 6717
Added:
PLD-doc/book/pl_book__pakiety/pl_pakiety__cechy.sec
Modified:
PLD-doc/book/pl_book__master.docb
PLD-doc/book/pl_book__pakiety/pl_pakiety.chp
PLD-doc/book/pl_book__pakiety/wprowadzenie.sec
Log:
- podzial Wstepu na dwa mniejsze rozdzily: "Wstep" i "Cechy pakietow w PLD"
Modified: PLD-doc/book/pl_book__master.docb
==============================================================================
--- PLD-doc/book/pl_book__master.docb (original)
+++ PLD-doc/book/pl_book__master.docb Thu Dec 29 23:41:55 2005
@@ -28,6 +28,7 @@
<!ENTITY podstawy__narzedzia_sieciowe SYSTEM "pl_book__podstawy/pl_podstawy__narzedzia_sieciowe.sec">
<!ENTITY pakiety SYSTEM "pl_book__pakiety/pl_pakiety.chp">
<!ENTITY pakiety__wprowadzenie SYSTEM "pl_book__pakiety/wprowadzenie.sec">
+<!ENTITY pakiety__cechy SYSTEM "pl_book__pakiety/pl_pakiety__cechy.sec">
<!ENTITY pakiety__poldek SYSTEM "pl_book__pakiety/poldek.sec">
<!ENTITY pakiety__rpm SYSTEM "pl_book__pakiety/rpm.sec">
<!ENTITY konfiguracja SYSTEM "pl_book__konfiguracja/pl_konfiguracja.chp">
Modified: PLD-doc/book/pl_book__pakiety/pl_pakiety.chp
==============================================================================
--- PLD-doc/book/pl_book__pakiety/pl_pakiety.chp (original)
+++ PLD-doc/book/pl_book__pakiety/pl_pakiety.chp Thu Dec 29 23:41:55 2005
@@ -4,6 +4,7 @@
<title>Zarządzanie pakietami</title>
<para>Ten rozdział opisuje metody zarządzania pakietami w systemie PLD.</para>
&pakiety__wprowadzenie;
+&pakiety__cechy;
&pakiety__poldek;
&pakiety__rpm;
</chapter>
Added: PLD-doc/book/pl_book__pakiety/pl_pakiety__cechy.sec
==============================================================================
--- (empty file)
+++ PLD-doc/book/pl_book__pakiety/pl_pakiety__cechy.sec Thu Dec 29 23:41:55 2005
@@ -0,0 +1,359 @@
+<?xml version="1.0" encoding="iso-8859-2"?>
+<section id="pakiety_cechy">
+<title>Cechy pakietów w PLD</title>
+
+ <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>,
+ 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ę
+ pakietów, tak aby w systemie była zainstalowany był tylko
+ jeden program z pośród kilku dostępnych (np. serwery usług).
+ </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.
+ </para>
+ <para>
+ Dawniej zależności były budowane na podstawie nazw pakietów,
+ w tej chwili stopniowo wprowadzane są zależności na podstawie
+ plików (programów, bibliotek itd.). Zyskujemy w ten sposób
+ elastyczność kosztem wygody w niektórych, rzadko spotykanych
+ sytuacjach. W przypadku codziennej pracy z pakietami, nie
+ odczujemy większych różnic i nie musimy się tym martwić.
+ </para>
+ </section>
+
+
+
+ <section id="pakiety_cechy_nazwy_pakietow">
+ <title>Konwencja nazw pakietów w PLD</title>
+
+ <para>
+ Nazwy pakietów mają następującą budowę:
+ <literal>{$nazwa}-{$wersja}.{$arch}.rpm</literal>
+ np.: <filename>0verkill-0.16-3.i686.rpm</filename>.
+ Tak wyglądają nazwy pakietów w systemie plików lub
+ na serwerze FTP. W menedżerach pakietów posługujemy się jedynie
+ nazwą lub nazwą i wersją (nie licząc instalacji za pomocą rpm-a).
+ </para>
+ <table frame='all'>
+ <title>Opis zawartości pakietów w zależności od ich nazwy</title>
+ <tgroup cols='2' align='center' colsep='1' rowsep='1'>
+ <thead>
+ <row>
+ <entry>Nazwa pakietu</entry>
+ <entry>Zawartość</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry><emphasis>program</emphasis>,
+ <emphasis>program-core</emphasis></entry>
+ <entry>główny pakiet programu, zawiera pliki wykonywalne,
+ dokumentację, skrypty startowe w przypadku usług, niekiedy
+ biblioteki</entry>
+ </row>
+ <row>
+ <entry>program-<emphasis>common</emphasis></entry>
+ <entry>podstawowe, wspólne pliki; zwykle
+ samodzielny taki pakiet jest bezużyteczny i
+ wymaga zainstalowania dodatkowych pakietów
+ </entry>
+ </row>
+ <row>
+ <entry>program-<emphasis>libs</emphasis></entry>
+ <entry>zestaw bibliotek stworzonych na potrzeby danego
+ programu, są niekiedy wymagane przez inne programy
+ </entry>
+ </row>
+ <row>
+ <entry>
+ program-<emphasis>tools</emphasis>,
+ program-<emphasis>utils</emphasis>,
+ program-<emphasis>progs</emphasis>
+ </entry>
+ <entry>
+ dodatkowe narzędzia, zwykle nie są
+ konieczne do podstawowej pracy programu
+ </entry>
+ </row>
+ <row>
+ <entry>
+ program-<emphasis>extras</emphasis>
+ </entry>
+ <entry>
+ dodatkowe, rzadziej używane elementy
+ </entry>
+ </row>
+ <row>
+ <entry>program-<emphasis>mod</emphasis>,
+ program-<emphasis>plugin</emphasis>,
+ program-<emphasis>applets</emphasis>,
+ program-<emphasis>addon</emphasis>
+ </entry>
+ <entry>różnej maści moduły, "wtyczki", applety i dodatki
+ przeważnie nie są konieczne do podstawowej pracy programu</entry>
+ </row>
+ <row>
+ <entry>program-<emphasis>skin(s)</emphasis>,
+ program-<emphasis>theme(s)</emphasis>
+ </entry>
+ <entry>"skórki" i "tematy" modyfikujące wygląd programu</entry>
+ </row>
+ <row>
+ <entry>program-<emphasis>driver</emphasis></entry>
+ <entry>sterowniki</entry>
+ </row>
+ <row>
+ <entry>program-<emphasis>backend</emphasis></entry>
+ <entry>
+ specjalne interfejsy służące do rozszerzania
+ możliwości programu, łączenia z innymi
+ programami, sprzętem itp.
+ </entry>
+ </row>
+ <row>
+ <entry>program-<emphasis>i18n</emphasis></entry>
+ <entry>dodatkowe wersje językowe</entry>
+ </row>
+ <row>
+ <entry>program-<emphasis>devel</emphasis></entry>
+ <entry>pakiety potrzebne dla programistów oraz osób,
+ które zajmują się własnoręczną kompilacją programów
+ </entry>
+ </row>
+ <row>
+ <entry>program-<emphasis>doc</emphasis></entry>
+ <entry>dokumentacja programu</entry>
+ </row>
+ <row>
+ <entry>program-<emphasis>static</emphasis></entry>
+ <entry>program skompilowany statycznie - nie wymaga
+ bibliotek</entry>
+ </row>
+ <row>
+ <entry><emphasis>lib_nazwa_biblioteki</emphasis></entry>
+ <entry>zestaw uniwersalnych bibliotek, nie związanych z
+ żadnym konkretnym programem.</entry>
+ </row>
+ <row>
+ <entry>usługa-<emphasis>inetd</emphasis>,
+ usługa-<emphasis>standalone</emphasis>
+ </entry>
+ <entry>alternatywne pakiety służące do wyboru
+ trybu pracy niektórych usług. Należy wybrać jeden
+ z nich: uruchamianie przez
+ <productname>Inetd</productname> lub praca w tle
+ (standalone)
+ </entry>
+ </row>
+ <row>
+ <entry>usługa-<emphasis>init</emphasis></entry>
+ <entry>skrypty startowe programu</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+ </section>
+
+
+ <section id="pakiety_cechy_arch">
+ <title>Architektury pakietów</title>
+ <para>
+ W nazwie pakietu, tuż przy rozszerzeniu pliku występuje
+ oznaczenie architektury, powyżej przedstawiono ją jako ciąg
+ znaków <literal>{$arch}</literal>. Oznaczenie to określa
+ architekturę sprzętową dla jakiej pakiet został przygotowany.
+ W PLD programy są kompilowane dla wielu architektur
+ sprzętowych, pozwala to na używanie systemu na bardziej
+ różnorodnym sprzęcie oraz na lepsze dopasowanie do
+ używanego procesora.
+ </para>
+ <para>
+ Wybór architektury dokonuje się poprzez wskazanie
+ odpowiedniego katalogu na serwerze przed instalacją pakietów.
+ Ścieżka do katalogu zawierającego pakiety ma
+ następującą konstrukcję:
+ <filename>/dists/{$wersja}/PLD/{$arch}</filename>.
+ ($wersja określa interesującą nas wersję systemu,
+ $arch to jedna z dostępnych architektur).
+ Przykładowo adres
+ <filename>ftp://ftp.pld-linux.org/dists/2.0/PLD/i686/</filename>
+ dotyczy systemu w wersji <productname>2.0 (Ac)</productname> z
+ wybraną architekturą "<literal>i686</literal>".
+ </para>
+
+ <table frame='all'>
+ <title>Lista nazw kodowych architektur i odpowiadających im rodzin procesorów:</title>
+ <tgroup cols='2' align='center' colsep='1' rowsep='1'>
+ <thead>
+ <row>
+ <entry>Nazwa architektury</entry>
+ <entry>Obsługiwana platforma</entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry>alpha</entry>
+ <entry>Compaq Alpha AXP</entry>
+ </row>
+
+ <row>
+ <entry>amd64</entry>
+ <entry>AMD K8 (Opetron, Athlon 64), Intel Xeon EM64T</entry>
+ </row>
+ <row>
+ <entry>athlon</entry>
+ <entry>AMD K7 (Athlon, Duron)</entry>
+ </row>
+ <row>
+ <entry>i386</entry>
+ <entry>wszystkie procesory zgodne z x86 firmy Intel</entry>
+ </row>
+ <row>
+ <entry>i586</entry>
+ <entry>procesory x86 nowsze niż 386, 486, AMD K5 (wersje Socket 3)</entry>
+ </row>
+ <row>
+ <entry>i686</entry>
+ <entry>procesory x86 nowsze niż Pentium, Cyrix 5x86,
+ AMD K5 (wersje Socket7) i AMD K6</entry>
+ </row>
+ <row>
+ <entry>ppc</entry>
+ <entry>PowerPC</entry>
+ </row>
+ <row>
+ <entry>sparc</entry>
+ <entry>Sun SPARC, Sun UltraSPARC</entry>
+ </row>
+ <row>
+ <entry>noarch</entry>
+ <entry>dowolna</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+
+ <para>
+ Należy pamiętać by instalować pakiety wyłącznie
+ przeznaczone dla używanej architektury. Wyjątkiem są
+ pakiety z oznaczeniem <literal>noarch</literal> oraz
+ pakiety przeznaczone dla procesorów Intel x86 i
+ zgodnych: <literal>i386</literal>,
+ <literal>i586</literal>, oraz <literal>i686</literal>.
+ </para>
+ <para>
+ Architektury z rodziny x86 są bardziej lub mniej
+ wyspecjalizowanymi grupami, najbardziej ogólna jest
+ <literal>386</literal>, zaś każda następna w kolejności
+ jest bardziej wyspecjalizowana.
+ Im węższa specjalizacja grupy tym mniej modeli procesorów
+ obsługuje. Przykładowo na maszynie z procesorem
+ <productname>Pentium III</productname>
+ (<literal>i686</literal>) możemy zainstalować system w
+ wersji <literal>i386</literal>, ale na procesorze
+ <productname>386</productname> wersja <literal>i686</literal>
+ nie będzie działać. Jeśli mamy nowszy procesor, to
+ będziemy mogli użyć bardziej wyspecjalizowanej
+ architektury, a co za tym idzie lepiej wykorzystać jego
+ potencjał.
+ </para>
+ <para>
+ Aby sprawdzić architekturę komputera używamy polecenia
+ <command>arch</command> lub <command>uname -m</command>.
+ </para>
+ </section>
+
+
+ <section id="wprowadzenie_pakiety_a_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ść.
+ Jest tak skonstruowana, aby nie zaskakiwać administratora w
+ najmniej oczekiwanych momentach oraz zapewnić nieprzerwanie
+ działanie systemu.
+ </para>
+ <para>
+ Zarządzanie pakietami czasami powoduje modyfikację plików
+ konfiguracyjnych, zwykle jest to dodawanie, bądź usuwanie
+ użytkowników/grup, modyfikację systemu rc-skryptów, itp.
+ Część z tych operacji jest sygnalizowana komunikatami
+ wyświetlanymi po zakończeniu operacji, dla przykładu poniżej
+ przedstawiono komunikaty wyświetlane po instalacji
+ <productname>Exim-a</productname>:
+<screen>Adding group exim GID=79.
+Adding user exim UID=79.
+Run "/etc/rc.d/init.d/exim start" to start exim daemon.</screen>
+ Pojawiają się także polecenie wykonania jakiejś operacji,
+ zainstalowania dodatkowych pakietów itp. Są to dosyć ważne
+ instrukcje, dlatego warto je obserwować.
+ </para>
+ <para>
+ Jeśli instalujemy w systemie jakąś usługę to zostanie
+ zapisana odpowiednia informacja do skryptów startowych i
+ nowe oprogramowanie uruchomi się przy najbliższej
+ zmianie trybu pracy lub restarcie systemu. Jeżeli jakaś
+ usługa jest wyłączona z działania i nastąpi jej
+ aktualizacja, to w dalszym ciągu nie będzie uruchamiana.
+ Jeśli aktualizujemy usługę, która obecnie działa, to zostanie
+ ona automatycznie zrestartowana lub taka operacja zostanie
+ zasugerowana przez pakiet. Będzie to zależało od ustawienia
+ opcji <literal>RPM_SKIP_AUTO_RESTART</literal> w pliku
+ <filename>/etc/sysconfig/rpm</filename>.
+ </para>
+ </section>
+
+ <section id="wprowadzenie_pakiety_a_pliki_konfiguracji">
+ <title>Wpływ pakietów na pliki konfiguracji</title>
+ <para>
+ Po aktualizacji pakietu nie są naruszanie istniejące pliki
+ konfiguracji, nowe wersje tych plików są zapisywane z
+ rozszerzeniem "<literal>.rpmnew</literal>". Przykładowo
+ po zaktualizowaniu pakietu <productname>sudo</productname>
+ obok pliku <filename>/etc/sudoers</filename> pojawi się
+ nowy plik o nazwie <filename>/etc/sudoers.rpmnew</filename>,
+ 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ć
+ plik 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 razie problemów z działaniem
+ programu po aktualizacji.
+ </para>
+ <para>
+ Kiedy odnajdziemy plik *rpmnew to możemy łatwo sprawdzić
+ czym różni się jego zawartość w stosunku do obecnie używanego
+ pliku konfiguracji. Posłużymy się w tym celu programem
+ <command>diff</command> np.:
+<screen># diff jakis_plik.conf jakis_plik.conf.rpmnew</screen>
+ </para>
+ <para>
+ W przypadku niektórych programów, po odinstalowaniu
+ pakietu, pozostawiane są jego pliki konfiguracji, posiadają
+ one rozszerzenie "<literal>.rpmsave</literal>", możemy je
+ zachować lub skasować jeśli uznamy że są nam zbędne.
+ </para>
+ <para>
+ Osoby chcące trzymać porządek w systemie powinny zajmować się
+ plikami <literal>.rpmnew</literal> i <literal>.rpmsave</literal>
+ od razu po pracy z menadżerem pakietów. Pliki łatwo
+ odnajdziemy gdyż występują jedynie w katalogu
+ <filename>/etc</filename>, odszukamy je następująco:
+<screen>$ find /etc -name "*rpmnew"
+$ find /etc -name "*rpmsave"</screen>
+
+ </para>
+ </section>
+</section>
+
+
+
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 Thu Dec 29 23:41:55 2005
@@ -61,31 +61,6 @@
<xref linkend="linki_zrodla_pakietow" />.
</para>
</section>
-
- <section id="pakiety_wprowadzenie_zaleznosci">
- <title>Zależności między pakietami</title>
- <para>
- Istotną cechą pakietów RPM są 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ę
- pakietów, tak aby w systemie była zainstalowany był tylko
- jeden program z pośród kilku dostępnych (np. serwery usług).
- </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.
- </para>
- <para>
- Dawniej zależności były budowane na podstawie nazw pakietów,
- w tej chwili stopniowo wprowadzane są zależności na podstawie
- plików (programów, bibliotek itd.). Zyskujemy w ten sposób
- elastyczność kosztem wygody w niektórych, rzadko spotykanych
- sytuacjach. W przypadku codziennej pracy z pakietami, nie
- odczujemy większych różnic i nie musimy się tym martwić.
- </para>
- </section>
<section id="pakiety_wprowadzenie_menadzery_pakietow">
<title>Menadżery pakietów</title>
@@ -128,333 +103,6 @@
</listitem>
</itemizedlist>
</section>
-
-
-
- <section id="pakiety_wprowadzenie_nazwy_pakietow">
- <title>Konwencja nazw pakietów w PLD</title>
-
- <para>
- Nazwy pakietów mają następującą budowę:
- <literal>{$nazwa}-{$wersja}.{$arch}.rpm</literal>
- np.: <filename>0verkill-0.16-3.i686.rpm</filename>.
- Tak wyglądają nazwy pakietów w systemie plików lub
- na serwerze FTP. W menedżerach pakietów posługujemy się jedynie
- nazwą lub nazwą i wersją (nie licząc instalacji za pomocą rpm-a).
- </para>
- <table frame='all'>
- <title>Opis zawartości pakietów w zależności od ich nazwy</title>
- <tgroup cols='2' align='center' colsep='1' rowsep='1'>
- <thead>
- <row>
- <entry>Nazwa pakietu</entry>
- <entry>Zawartość</entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry><emphasis>program</emphasis>,
- <emphasis>program-core</emphasis></entry>
- <entry>główny pakiet programu, zawiera pliki wykonywalne,
- dokumentację, skrypty startowe w przypadku usług, niekiedy
- biblioteki</entry>
- </row>
- <row>
- <entry>program-<emphasis>common</emphasis></entry>
- <entry>podstawowe, wspólne pliki; zwykle
- samodzielny taki pakiet jest bezużyteczny i
- wymaga zainstalowania dodatkowych pakietów
- </entry>
- </row>
- <row>
- <entry>program-<emphasis>libs</emphasis></entry>
- <entry>zestaw bibliotek stworzonych na potrzeby danego
- programu, są niekiedy wymagane przez inne programy
- </entry>
- </row>
- <row>
- <entry>
- program-<emphasis>tools</emphasis>,
- program-<emphasis>utils</emphasis>,
- program-<emphasis>progs</emphasis>
- </entry>
- <entry>
- dodatkowe narzędzia, zwykle nie są
- konieczne do podstawowej pracy programu
- </entry>
- </row>
- <row>
- <entry>
- program-<emphasis>extras</emphasis>
- </entry>
- <entry>
- dodatkowe, rzadziej używane elementy
- </entry>
- </row>
- <row>
- <entry>program-<emphasis>mod</emphasis>,
- program-<emphasis>plugin</emphasis>,
- program-<emphasis>applets</emphasis>,
- program-<emphasis>addon</emphasis>
- </entry>
- <entry>różnej maści moduły, "wtyczki", applety i dodatki
- przeważnie nie są konieczne do podstawowej pracy programu</entry>
- </row>
- <row>
- <entry>program-<emphasis>skin(s)</emphasis>,
- program-<emphasis>theme(s)</emphasis>
- </entry>
- <entry>"skórki" i "tematy" modyfikujące wygląd programu</entry>
- </row>
- <row>
- <entry>program-<emphasis>driver</emphasis></entry>
- <entry>sterowniki</entry>
- </row>
- <row>
- <entry>program-<emphasis>backend</emphasis></entry>
- <entry>
- specjalne interfejsy służące do rozszerzania
- możliwości programu, łączenia z innymi
- programami, sprzętem itp.
- </entry>
- </row>
- <row>
- <entry>program-<emphasis>i18n</emphasis></entry>
- <entry>dodatkowe wersje językowe</entry>
- </row>
- <row>
- <entry>program-<emphasis>devel</emphasis></entry>
- <entry>pakiety potrzebne dla programistów oraz osób,
- które zajmują się własnoręczną kompilacją programów
- </entry>
- </row>
- <row>
- <entry>program-<emphasis>doc</emphasis></entry>
- <entry>dokumentacja programu</entry>
- </row>
- <row>
- <entry>program-<emphasis>static</emphasis></entry>
- <entry>program skompilowany statycznie - nie wymaga
- bibliotek</entry>
- </row>
- <row>
- <entry><emphasis>lib_nazwa_biblioteki</emphasis></entry>
- <entry>zestaw uniwersalnych bibliotek, nie związanych z
- żadnym konkretnym programem.</entry>
- </row>
- <row>
- <entry>usługa-<emphasis>inetd</emphasis>,
- usługa-<emphasis>standalone</emphasis>
- </entry>
- <entry>alternatywne pakiety służące do wyboru
- trybu pracy niektórych usług. Należy wybrać jeden
- z nich: uruchamianie przez
- <productname>Inetd</productname> lub praca w tle
- (standalone)
- </entry>
- </row>
- <row>
- <entry>usługa-<emphasis>init</emphasis></entry>
- <entry>skrypty startowe programu</entry>
- </row>
- </tbody>
- </tgroup>
- </table>
- </section>
-
-
- <section id="pakiety_wprowadzenie_arch">
- <title>Architektury pakietów</title>
- <para>
- W nazwie pakietu, tuż przy rozszerzeniu pliku występuje
- oznaczenie architektury, powyżej przedstawiono ją jako ciąg
- znaków <literal>{$arch}</literal>. Oznaczenie to określa
- architekturę sprzętową dla jakiej pakiet został przygotowany.
- W PLD programy są kompilowane dla wielu architektur
- sprzętowych, pozwala to na używanie systemu na bardziej
- różnorodnym sprzęcie oraz na lepsze dopasowanie do
- używanego procesora.
- </para>
- <para>
- Wybór architektury dokonuje się poprzez wskazanie
- odpowiedniego katalogu na serwerze przed instalacją pakietów.
- Ścieżka do katalogu zawierającego pakiety ma
- następującą konstrukcję:
- <filename>/dists/{$wersja}/PLD/{$arch}</filename>.
- ($wersja określa interesującą nas wersję systemu,
- $arch to jedna z dostępnych architektur).
- Przykładowo adres
- <filename>ftp://ftp.pld-linux.org/dists/2.0/PLD/i686/</filename>
- dotyczy systemu w wersji <productname>2.0 (Ac)</productname> z
- wybraną architekturą "<literal>i686</literal>".
- </para>
-
- <table frame='all'>
- <title>Lista nazw kodowych architektur i odpowiadających im rodzin procesorów:</title>
- <tgroup cols='2' align='center' colsep='1' rowsep='1'>
- <thead>
- <row>
- <entry>Nazwa architektury</entry>
- <entry>Obsługiwana platforma</entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry>alpha</entry>
- <entry>Compaq Alpha AXP</entry>
- </row>
-
- <row>
- <entry>amd64</entry>
- <entry>AMD K8 (Opetron, Athlon 64), Intel Xeon EM64T</entry>
- </row>
- <row>
- <entry>athlon</entry>
- <entry>AMD K7 (Athlon, Duron)</entry>
- </row>
- <row>
- <entry>i386</entry>
- <entry>wszystkie procesory zgodne z x86 firmy Intel</entry>
- </row>
- <row>
- <entry>i586</entry>
- <entry>procesory x86 nowsze niż 386, 486, AMD K5 (wersje Socket 3)</entry>
- </row>
- <row>
- <entry>i686</entry>
- <entry>procesory x86 nowsze niż Pentium, Cyrix 5x86,
- AMD K5 (wersje Socket7) i AMD K6</entry>
- </row>
- <row>
- <entry>ppc</entry>
- <entry>PowerPC</entry>
- </row>
- <row>
- <entry>sparc</entry>
- <entry>Sun SPARC, Sun UltraSPARC</entry>
- </row>
- <row>
- <entry>noarch</entry>
- <entry>dowolna</entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
-
- <para>
- Należy pamiętać by instalować pakiety wyłącznie
- przeznaczone dla używanej architektury. Wyjątkiem są
- pakiety z oznaczeniem <literal>noarch</literal> oraz
- pakiety przeznaczone dla procesorów Intel x86 i
- zgodnych: <literal>i386</literal>,
- <literal>i586</literal>, oraz <literal>i686</literal>.
- </para>
- <para>
- Architektury z rodziny x86 są bardziej lub mniej
- wyspecjalizowanymi grupami, najbardziej ogólna jest
- <literal>386</literal>, zaś każda następna w kolejności
- jest bardziej wyspecjalizowana.
- Im węższa specjalizacja grupy tym mniej modeli procesorów
- obsługuje. Przykładowo na maszynie z procesorem
- <productname>Pentium III</productname>
- (<literal>i686</literal>) możemy zainstalować system w
- wersji <literal>i386</literal>, ale na procesorze
- <productname>386</productname> wersja <literal>i686</literal>
- nie będzie działać. Jeśli mamy nowszy procesor, to
- będziemy mogli użyć bardziej wyspecjalizowanej
- architektury, a co za tym idzie lepiej wykorzystać jego
- potencjał.
- </para>
- <para>
- Aby sprawdzić architekturę komputera używamy polecenia
- <command>arch</command> lub <command>uname -m</command>.
- </para>
- </section>
-
-
- <section id="wprowadzenie_pakiety_a_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ść.
- Jest tak skonstruowana, aby nie zaskakiwać administratora w
- najmniej oczekiwanych momentach oraz zapewnić nieprzerwanie
- działanie systemu.
- </para>
- <para>
- Zarządzanie pakietami czasami powoduje modyfikację plików
- konfiguracyjnych, zwykle jest to dodawanie, bądź usuwanie
- użytkowników/grup, modyfikację systemu rc-skryptów, itp.
- Część z tych operacji jest sygnalizowana komunikatami
- wyświetlanymi po zakończeniu operacji, dla przykładu poniżej
- przedstawiono komunikaty wyświetlane po instalacji
- <productname>Exim-a</productname>:
-<screen>Adding group exim GID=79.
-Adding user exim UID=79.
-Run "/etc/rc.d/init.d/exim start" to start exim daemon.</screen>
- Pojawiają się także polecenie wykonania jakiejś operacji,
- zainstalowania dodatkowych pakietów itp. Są to dosyć ważne
- instrukcje, dlatego warto je obserwować.
- </para>
- <para>
- Jeśli instalujemy w systemie jakąś usługę to zostanie
- zapisana odpowiednia informacja do skryptów startowych i
- nowe oprogramowanie uruchomi się przy najbliższej
- zmianie trybu pracy lub restarcie systemu. Jeżeli jakaś
- usługa jest wyłączona z działania i nastąpi jej
- aktualizacja, to w dalszym ciągu nie będzie uruchamiana.
- Jeśli aktualizujemy usługę, która obecnie działa, to zostanie
- ona automatycznie zrestartowana lub taka operacja zostanie
- zasugerowana przez pakiet. Będzie to zależało od ustawienia
- opcji <literal>RPM_SKIP_AUTO_RESTART</literal> w pliku
- <filename>/etc/sysconfig/rpm</filename>.
- </para>
- </section>
-
- <section id="wprowadzenie_pakiety_a_pliki_konfiguracji">
- <title>Wpływ pakietów na pliki konfiguracji</title>
- <para>
- Po aktualizacji pakietu nie są naruszanie istniejące pliki
- konfiguracji, nowe wersje tych plików są zapisywane z
- rozszerzeniem "<literal>.rpmnew</literal>". Przykładowo
- po zaktualizowaniu pakietu <productname>sudo</productname>
- obok pliku <filename>/etc/sudoers</filename> pojawi się
- nowy plik o nazwie <filename>/etc/sudoers.rpmnew</filename>,
- 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ć
- plik 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 razie problemów z działaniem
- programu po aktualizacji.
- </para>
- <para>
- Kiedy odnajdziemy plik *rpmnew to możemy łatwo sprawdzić
- czym różni się jego zawartość w stosunku do obecnie używanego
- pliku konfiguracji. Posłużymy się w tym celu programem
- <command>diff</command> np.:
-<screen># diff jakis_plik.conf jakis_plik.conf.rpmnew</screen>
- </para>
- <para>
- W przypadku niektórych programów, po odinstalowaniu
- pakietu, pozostawiane są jego pliki konfiguracji, posiadają
- one rozszerzenie "<literal>.rpmsave</literal>", możemy je
- zachować lub skasować jeśli uznamy że są nam zbędne.
- </para>
- <para>
- Osoby chcące trzymać porządek w systemie powinny zajmować się
- plikami <literal>.rpmnew</literal> i <literal>.rpmsave</literal>
- od razu po pracy z menadżerem pakietów. Pliki łatwo
- odnajdziemy gdyż występują jedynie w katalogu
- <filename>/etc</filename>, odszukamy je następująco:
-<screen>$ find /etc -name "*rpmnew"
-$ find /etc -name "*rpmsave"</screen>
-
- </para>
- </section>
</section>
Więcej informacji o liście dyskusyjnej pld-doc