| 1 |
rane 08/02/23 12:26:20 |
| 2 |
|
| 3 |
Modified: faq.xml |
| 4 |
Log: |
| 5 |
-> 1.6, by akroplas |
| 6 |
|
| 7 |
Revision Changes Path |
| 8 |
1.3 xml/htdocs/proj/pl/releng/catalyst/faq.xml |
| 9 |
|
| 10 |
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/pl/releng/catalyst/faq.xml?rev=1.3&view=markup |
| 11 |
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/pl/releng/catalyst/faq.xml?rev=1.3&content-type=text/plain |
| 12 |
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/pl/releng/catalyst/faq.xml?r1=1.2&r2=1.3 |
| 13 |
|
| 14 |
Index: faq.xml |
| 15 |
=================================================================== |
| 16 |
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/pl/releng/catalyst/faq.xml,v |
| 17 |
retrieving revision 1.2 |
| 18 |
retrieving revision 1.3 |
| 19 |
diff -u -r1.2 -r1.3 |
| 20 |
--- faq.xml 17 Jul 2006 21:57:22 -0000 1.2 |
| 21 |
+++ faq.xml 23 Feb 2008 12:26:19 -0000 1.3 |
| 22 |
@@ -1,6 +1,6 @@ |
| 23 |
<?xml version="1.0" encoding="UTF-8"?> |
| 24 |
<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?> |
| 25 |
-<!-- $Header --> |
| 26 |
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/pl/releng/catalyst/faq.xml,v 1.3 2008/02/23 12:26:19 rane Exp $ --> |
| 27 |
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> |
| 28 |
<guide link="/proj/pl/releng/catalyst/faq.xml" lang="pl"> |
| 29 |
|
| 30 |
@@ -18,31 +18,26 @@ |
| 31 |
Najczęściej zadawane pytania związane z programem Catalyst. |
| 32 |
</abstract> |
| 33 |
|
| 34 |
-<version>1.0</version> |
| 35 |
-<date>2005-12-01</date> |
| 36 |
+<version>1.1</version> |
| 37 |
+<date>2008-02-05</date> |
| 38 |
|
| 39 |
<chapter> |
| 40 |
<title>Najczęściej zadawane pytania</title> |
| 41 |
<section> |
| 42 |
- |
| 43 |
+<title>Jak utworzyć tarballe stage2 i stage3 dla nietypowych procesorów, takich |
| 44 |
+jak pentium4?</title> |
| 45 |
<body> |
| 46 |
|
| 47 |
<p> |
| 48 |
-<b>P: Jak utworzyć tarballe stage2 i stage3 dla nietypowych procesorów, takich |
| 49 |
-jak <c>pentium4</c> czy <c>g4</c>?</b> |
| 50 |
-</p> |
| 51 |
- |
| 52 |
-<p> |
| 53 |
-O: Po pierwsze, należy się upewnić, czy sprzęt na którym pracujemy odpowiada |
| 54 |
+Po pierwsze, należy się upewnić, czy sprzęt na którym pracujemy odpowiada |
| 55 |
konfiguracji, na którą przygotowujemy stage. Tworzenie stage dla |
| 56 |
-<c>pentium4</c> musi zostać wykonane na systemie opartym o Pentium 4 lub |
| 57 |
-AMD64/Opteron. Nie jest możliwe utworzenie stage dla <c>pentium4</c> na |
| 58 |
-systemie opartym o Athlon XP, jako że procesory Athlon XP nie wspierają |
| 59 |
-instrukcji SSE2, dostępnych w stage dla <c>pentium4</c>. Podobnie rzecz ma się |
| 60 |
-w przypadku, gdy chcemy budować system dla <c>g4</c>. Można tego dokonać |
| 61 |
-jedynie na systemach wspierających PowerPC G4 lub G5. |
| 62 |
+<c>pentium4</c> musi zostać wykonane na systemie opartym o Pentium 4 |
| 63 |
+lubAMD64/Opteron (lub lepszym). Nie jest możliwe utworzenie stage dla |
| 64 |
+<c>pentium4</c> na systemie opartym o Athlon XP, jako że procesory Athlon XP nie |
| 65 |
+wspierają instrukcji SSE2, dostępnych w stage dla <c>pentium4</c>. Podobnie |
| 66 |
+rzecz ma się w przypadku, gdy chcemy budować system dla <c>g4</c>. Można tego |
| 67 |
+dokonać jedynie na systemach wspierających PowerPC G4 lub G5. |
| 68 |
</p> |
| 69 |
- |
| 70 |
<p> |
| 71 |
Gdy mamy pewność, że budujemy system na właściwym sprzęcie, można rozpocząć |
| 72 |
instalację, jednakże by zbudować system od stage2, należy wybrać stage z opcją |
| 73 |
@@ -53,69 +48,80 @@ |
| 74 |
opcją stage2. |
| 75 |
</p> |
| 76 |
|
| 77 |
-<p> |
| 78 |
-<b>P: Jak zbudować system z wieloma stage'ami wpierającymi różnorodne |
| 79 |
-procesory?</b> |
| 80 |
-</p> |
| 81 |
+</body> |
| 82 |
+</section> |
| 83 |
+ |
| 84 |
+<section> |
| 85 |
+<title>Jak zbudować system z wieloma stage'ami wpierającymi różnorodne |
| 86 |
+procesory?</title> |
| 87 |
+<body> |
| 88 |
|
| 89 |
<p> |
| 90 |
-O: Na początku należy zbudować ogólny stage1. Następnie używamy utworzone |
| 91 |
+Na początku należy zbudować ogólny stage1. Następnie używamy utworzone |
| 92 |
stage1 do zbudowania konkretnych wersji stage2 i stage3. Używamy stage1 |
| 93 |
ponownie by utworzyć kolejne wyspecjalizowane wersje stage2 i stage3. Stage1 |
| 94 |
nie musi być tworzone od nowa -- wszystkie zbudowane stage2 i stage3 mogą |
| 95 |
używać tego samego stage1 jako źródła. |
| 96 |
</p> |
| 97 |
|
| 98 |
-<p> |
| 99 |
-<b>P: Czy można zbudować stage1 dla nietypowej wersji procesora?</b> |
| 100 |
-</p> |
| 101 |
+</body> |
| 102 |
+</section> |
| 103 |
+ |
| 104 |
+<section> |
| 105 |
+<title>Czy można zbudować stage1 dla nietypowej wersji procesora?</title> |
| 106 |
+<body> |
| 107 |
|
| 108 |
<p> |
| 109 |
-O: Nie jest to najlepszy pomysł, jako że stage1 uznaje się za wersję pracującą |
| 110 |
+Nie jest to najlepszy pomysł, jako że stage1 uznaje się za wersję pracującą |
| 111 |
z każdym typem procesorów. Dzięki temu, można go uruchamiać na każdym |
| 112 |
sprzęcie. Musimy uważać, by nie "zanieczyścić" naszego stage1 specyficznym |
| 113 |
kodem nietypowych procesorów. Do tworzenia nowej wersji stage1 używamy |
| 114 |
-"ogólnych" wersji stage2 i stage3. |
| 115 |
+"ogólnych" wersji stage3. |
| 116 |
</p> |
| 117 |
|
| 118 |
-<p> |
| 119 |
-<b>P: Czy catalyst może budować każdy stage od początku? Jeżeli catalyst |
| 120 |
+</body> |
| 121 |
+</section> |
| 122 |
+ |
| 123 |
+<section> |
| 124 |
+<title>Czy catalyst może budować każdy stage od początku? Jeżeli catalyst |
| 125 |
posiada taką możliwość, dlaczego za każdym razem potrzebna jest wersja stage na |
| 126 |
-której budujemy inne?</b> |
| 127 |
-</p> |
| 128 |
+której budujemy inne?</title> |
| 129 |
+<body> |
| 130 |
|
| 131 |
<p> |
| 132 |
-O: Dobre pytanie. Jak wiadomo, stage2 i stage3 są zależne od poprzednich stage |
| 133 |
-przy budowaniu, o czym świadczą ich nazwy (np. "stage2" sugeruje istnienie |
| 134 |
-"stage1".) Mimo to, catalyst potrzebuje podstawowego stage by utworzyć stage1, |
| 135 |
-tak więc mając na celu zbudowanie stage1, warto wiedzieć dlaczego jest to tak |
| 136 |
-ważne. Budując stage1, catalyst korzysta ze źródłowego stage (stage2 lub |
| 137 |
-stage3) by utworzyć środowisko chroot. Wewnątrz środowiska chroot, nowe stage1 |
| 138 |
-jest tworzone poprzez ustawienie zmiennej środowiska <c>ROOT</c> na |
| 139 |
-<path>/tmp/stage1root</path>. Zmienna ta instruuje Portage by pominęło obecny |
| 140 |
-system plików i łączyło wszystkie nowe pakiety z systemem umiejscowionym w |
| 141 |
-<path>/tmp/stage1root</path>. <path>/tmp/stage1root</path> jest wtedy pakowane |
| 142 |
-i staje się docelowym stage1. Oznacza to, że gdy catalyst tworzy stage1, samo |
| 143 |
-stage1 nie dziedziczy żadnych binariów ani bibliotek ze źródłowego stage, które |
| 144 |
-jest używane podczas tworzenia. Jednakże używane stage <e>wpływa</e> w pewnym |
| 145 |
-stopniu na docelowe stage1 -- Pliki nagłówkowe Linux (Linux headers) w używanym |
| 146 |
-stage są użyte do budowania glibc w stage1, tak więc kompilatory w stage użytym |
| 147 |
-do budowy stage1 są używane do kompilacji wszystkich programów w stage1. |
| 148 |
-Źródłowe stage jest używane do odizolowania procesu budowy stage1 od lokalnego |
| 149 |
-systemu, oraz umożliwienia budowania stage1 w wersji x86 na systemach amd64, |
| 150 |
-dla przykładu. |
| 151 |
+Dobre pytanie. Jak wiadomo, stage2 i stage3 są zależne od poprzednich stage przy |
| 152 |
+budowaniu, o czym świadczą ich nazwy (np. "stage2" sugeruje istnienie "stage1".) |
| 153 |
+Mimo to, catalyst potrzebuje podstawowego stage by utworzyć stage1, tak więc |
| 154 |
+mając na celu zbudowanie stage1, warto wiedzieć dlaczego jest to tak ważne. |
| 155 |
+Budując stage1, catalyst korzysta ze źródłowego stage3 by utworzyć środowisko |
| 156 |
+chroot. Wewnątrz środowiska chroot, nowe stage1 jest tworzone poprzez |
| 157 |
+ustawienie zmiennej środowiska <c>ROOT</c> na <path>/tmp/stage1root</path>. |
| 158 |
+Zmienna ta instruuje menadżer pakietów by pominął obecny system plików i łączył |
| 159 |
+wszystkie nowe pakiety z systemem umiejscowionym w <path>/tmp/stage1root</path>. |
| 160 |
+Catalyst pakuje wtedy <path>/tmp/stage1root</path>, które zostaje docelowym |
| 161 |
+stage1. Oznacza to, że gdy catalyst tworzy stage1, samo stage1 nie dziedziczy |
| 162 |
+żadnych binariów ani bibliotek ze źródłowego stage, które jest używane podczas |
| 163 |
+tworzenia. Jednakże używane stage <e>wpływa</e> w pewnym stopniu na docelowe |
| 164 |
+stage1 -- Pliki nagłówkowe Linux (Linux headers) w używanym stage są użyte do |
| 165 |
+budowania glibc w stage1, tak więc kompilatory w stage użytym do budowy stage1 |
| 166 |
+są używane do kompilacji wszystkich programów w stage1. Źródłowe stage jest |
| 167 |
+używane do odizolowania procesu budowy stage1 od lokalnego systemu, oraz |
| 168 |
+umożliwienia budowania stage1 w wersji x86 na systemach amd64, dla przykładu. |
| 169 |
</p> |
| 170 |
|
| 171 |
-<p> |
| 172 |
-<b>P: Czy istnieje oficjalne HOWTO dla Catalyst?</b> |
| 173 |
-</p> |
| 174 |
+</body> |
| 175 |
+</section> |
| 176 |
+ |
| 177 |
+<section> |
| 178 |
+<title>Czy istnieje oficjalne HOWTO dla Catalyst?</title> |
| 179 |
+<body> |
| 180 |
|
| 181 |
<p> |
| 182 |
-O: Obecnie nie. Wszyscy zainteresowani napisaniem takiego przewodnika mogą |
| 183 |
-wysłać swe prace tak jak w przypadku raportowania błędów. Brak oficjalnego |
| 184 |
-HOWTO, nie oznacza że Catalyst nie posiada żadnej dokumentacji. Jeżeli |
| 185 |
-zaemergujemy Catalyst z flagą USE <c>doc</c>, przykładowe pliki z instrukcjami |
| 186 |
-zostaną zainstalowane w <path>/usr/share/doc/catalyst-$version/examples</path>. |
| 187 |
+Obecnie nie. Wszyscy zainteresowani napisaniem takiego przewodnika mogą wysłać |
| 188 |
+swe prace tak jak w przypadku raportowania błędów. Brak oficjalnego HOWTO, nie |
| 189 |
+oznacza że Catalyst nie posiada żadnej dokumentacji. Po zainstalowaniu Catalyst, |
| 190 |
+przykładowe pliki z instrukcjami zostaną zainstalowane w |
| 191 |
+<path>/usr/share/doc/catalyst-$version/examples</path>. |
| 192 |
</p> |
| 193 |
|
| 194 |
<p> |
| 195 |
@@ -123,53 +129,67 @@ |
| 196 |
zapisanie do listy mailowej gentoo-catalyst. |
| 197 |
</p> |
| 198 |
|
| 199 |
-<p> |
| 200 |
-<b>P: Gdzie należy umieszczać flagi USE dla poszczególnych pakietów, ustawienia |
| 201 |
-maskowania, itp?</b> |
| 202 |
-</p> |
| 203 |
+</body> |
| 204 |
+</section> |
| 205 |
+ |
| 206 |
+<section> |
| 207 |
+<title>Gdzie należy umieszczać flagi USE dla poszczególnych pakietów, ustawienia |
| 208 |
+maskowania, itp?</title> |
| 209 |
+<body> |
| 210 |
|
| 211 |
<p> |
| 212 |
-O: Catalast wspiera pliki konfiguracyjne znajdujące się w |
| 213 |
+Catalast wspiera pliki konfiguracyjne znajdujące się w |
| 214 |
<path>/etc/portage</path>. Wystarczy dodać wybrane flagi w pliku specyfikacji, |
| 215 |
i upewnić się czy źródłowe stage używają tej samej opcji <c>portage_confdir</c> |
| 216 |
co system lokalny: |
| 217 |
</p> |
| 218 |
- |
| 219 |
<p> |
| 220 |
portage_confdir: /ścieżka/do/etc/portage |
| 221 |
</p> |
| 222 |
|
| 223 |
-<p> |
| 224 |
-<b>P: Budować własne stage1, czy użyć wersji dostępnej w Gentoo mirror?</b> |
| 225 |
-</p> |
| 226 |
+</body> |
| 227 |
+</section> |
| 228 |
|
| 229 |
-<p> |
| 230 |
-O: Stage pochodzące z najnowszych wersji Gentoo mogą zostać użyte, chyba że |
| 231 |
-mamy zamiar budować wersję "hardened", lub chcemy mieć możliwość zmiany |
| 232 |
-ustawień profilu (np. flagi USE, CFLAGS, itp). |
| 233 |
-</p> |
| 234 |
+<section> |
| 235 |
+<title>Budować własne stage1, czy użyć wersji dostępnej w Gentoo mirror?</title> |
| 236 |
+<body> |
| 237 |
|
| 238 |
<p> |
| 239 |
-<b>P: W jaki sposób utrzymywać pakiety GRP/stages/LiveCD zawsze w najnowszej |
| 240 |
-wersji?</b> |
| 241 |
+Najlepiej <b>zawsze</b> budować własne stage, jeżeli nie zostanie do tego celu |
| 242 |
+użyty ten sam snapshot, który został użyty do zbudowania ostatniego wydania. |
| 243 |
+Drzewo często zmienia swoją zawartość. Jeżeli mielibyśmy użyć stage1 starszego |
| 244 |
+niż 3 miesiące, spowodowałoby to prawdopodobnie problemy z blokującymi się |
| 245 |
+pakietami i kompatybilnością, które wpłynęły by na proces budowania stage. |
| 246 |
</p> |
| 247 |
|
| 248 |
-<p> |
| 249 |
-O: Catalyst używa Portage podczas pracy, tak więc wystarczy regenerować |
| 250 |
-snapshot Portage i przebudowywać GRP/stage/LiveCD. Portage przeprowadzi |
| 251 |
-aktualizację pakietów tak jak to ma miejsce w zwykłym systemie. |
| 252 |
-</p> |
| 253 |
+</body> |
| 254 |
+</section> |
| 255 |
+ |
| 256 |
+<section> |
| 257 |
+<title>W jaki sposób utrzymywać pakiety GRP/stages/LiveCD zawsze w najnowszej |
| 258 |
+wersji?</title> |
| 259 |
+<body> |
| 260 |
|
| 261 |
<p> |
| 262 |
-<b>P: Czy Catalyst używa specjalnej składni dla flag USE?</b> |
| 263 |
+Catalyst używa Portage podczas pracy, tak więc wystarczy regenerować snapshot |
| 264 |
+Portage i przebudowywać GRP/stage/LiveCD. Portage przeprowadzi aktualizację |
| 265 |
+pakietów tak jak to ma miejsce w zwykłym systemie. |
| 266 |
</p> |
| 267 |
|
| 268 |
+</body> |
| 269 |
+</section> |
| 270 |
+ |
| 271 |
+<section> |
| 272 |
+<title>Czy Catalyst używa specjalnej składni dla flag USE?</title> |
| 273 |
+<body> |
| 274 |
+ |
| 275 |
<p> |
| 276 |
-O: Nie, flagi USE w Catalyst są identyczne jak w Portage. |
| 277 |
+Nie, flagi USE w Catalyst są identyczne jak w Portage. |
| 278 |
</p> |
| 279 |
|
| 280 |
</body> |
| 281 |
</section> |
| 282 |
+ |
| 283 |
</chapter> |
| 284 |
|
| 285 |
</guide> |
| 286 |
|
| 287 |
|
| 288 |
|
| 289 |
-- |
| 290 |
gentoo-commits@l.g.o mailing list |
Archives