| 1 |
rane 08/06/29 10:46:01 |
| 2 |
|
| 3 |
Modified: kde-split-ebuilds.xml |
| 4 |
Log: |
| 5 |
-> 1.16 |
| 6 |
|
| 7 |
Revision Changes Path |
| 8 |
1.21 xml/htdocs/doc/pl/kde-split-ebuilds.xml |
| 9 |
|
| 10 |
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/pl/kde-split-ebuilds.xml?rev=1.21&view=markup |
| 11 |
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/pl/kde-split-ebuilds.xml?rev=1.21&content-type=text/plain |
| 12 |
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/pl/kde-split-ebuilds.xml?r1=1.20&r2=1.21 |
| 13 |
|
| 14 |
Index: kde-split-ebuilds.xml |
| 15 |
=================================================================== |
| 16 |
RCS file: /var/cvsroot/gentoo/xml/htdocs/doc/pl/kde-split-ebuilds.xml,v |
| 17 |
retrieving revision 1.20 |
| 18 |
retrieving revision 1.21 |
| 19 |
diff -u -r1.20 -r1.21 |
| 20 |
--- kde-split-ebuilds.xml 17 Jan 2008 19:02:45 -0000 1.20 |
| 21 |
+++ kde-split-ebuilds.xml 29 Jun 2008 10:46:00 -0000 1.21 |
| 22 |
@@ -1,8 +1,8 @@ |
| 23 |
<?xml version='1.0' encoding='UTF-8'?> |
| 24 |
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/pl/kde-split-ebuilds.xml,v 1.20 2008/01/17 19:02:45 rane Exp $ --> |
| 25 |
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/pl/kde-split-ebuilds.xml,v 1.21 2008/06/29 10:46:00 rane Exp $ --> |
| 26 |
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> |
| 27 |
|
| 28 |
-<guide link="/doc/pl/kde-split-ebuilds.xml" lang="pl"> |
| 29 |
+<guide link="/doc/pl/kde-split-ebuilds.xml" lang="pl" redirect="/proj/pl/desktop/kde/kde-split-ebuilds.xml"> |
| 30 |
|
| 31 |
<title>Rozdzielone ebuildy KDE</title> |
| 32 |
|
| 33 |
@@ -28,455 +28,17 @@ |
| 34 |
<!-- See http://creativecommons.org/licenses/by-sa/2.5 --> |
| 35 |
<license/> |
| 36 |
|
| 37 |
-<version>1.11</version> |
| 38 |
-<date>2008-01-16</date> |
| 39 |
+<version>2</version> |
| 40 |
+<date>2008-04-26</date> |
| 41 |
|
| 42 |
<chapter> |
| 43 |
-<title>Rozdzielone ebuildy KDE.</title> |
| 44 |
+<title>Przeniesiono</title> |
| 45 |
<section> |
| 46 |
-<title>Czym one są?</title> |
| 47 |
<body> |
| 48 |
|
| 49 |
<p> |
| 50 |
-Do stycznia 2005 roku wszystkie te ebuildy w Portage były monolityczne. Było |
| 51 |
-ich tylko 15 (<c>kdabase</c>, <c>kdenetwork</c>, ...) i każdy instalował wiele |
| 52 |
-aplikacji, które w zasadzie nie były zależne od siebie. Nie była to do końca |
| 53 |
-optymalna sytuacja i z pewnością niezbyt zgodna z założeniami Gentoo, jednak |
| 54 |
-była tolerowana przez długi okres czasu. |
| 55 |
-</p> |
| 56 |
- |
| 57 |
-<p> |
| 58 |
-Nowe rozdzielone pakiety(dla <c>konquerora</c>, <c>kmaila</c>, ...) poprawiły |
| 59 |
-tą sytuację dostarczając odseparowane ebuildy dla każdej poszczególnej |
| 60 |
-aplikacji KDE. To dało nam całkowitą liczbę 330 nowych ebuildów w kategorii |
| 61 |
-kde-base. |
| 62 |
-</p> |
| 63 |
- |
| 64 |
-<p> |
| 65 |
-Ciągle udostępniamy monolityczne ebuildy dla KDE 3.5. Jednak to te rozdzielone |
| 66 |
-są nowym standardem i nie przewiduje się tworzenia tych monolitycznych dla KDE |
| 67 |
-od wersji 4.0. |
| 68 |
-</p> |
| 69 |
- |
| 70 |
-<p> |
| 71 |
-Wreszcie, należało by wspomnieć, że istnieją także rozdzielone ebuildy dla |
| 72 |
-Koffice. Instalują one osobno takie programy jak <c>kword</c>, <c>kugar</c> |
| 73 |
-itp. |
| 74 |
-</p> |
| 75 |
- |
| 76 |
-</body> |
| 77 |
-</section> |
| 78 |
-<section> |
| 79 |
-<title>Jak instalować rozdzielone ebuildy</title> |
| 80 |
-<body> |
| 81 |
- |
| 82 |
-<p> |
| 83 |
-W momencie pisania tego tekstu ostatnim stabilnym wydaniem KDE było 3.5.7, |
| 84 |
-natomiast ostatnim niestabilnym (~arch) wydanie 3.5.8. Rozdzielone i |
| 85 |
-monolityczne ebuildy są dostępne w drzewie Portage. Wydanie 4.0 wkrótce znajdzie |
| 86 |
-się w drzewie Portage. Będzie jednak zamaskowane w package.mask z powodu |
| 87 |
-licznych problemów. |
| 88 |
-</p> |
| 89 |
- |
| 90 |
-<ul> |
| 91 |
- <li> |
| 92 |
- Aby zainstalować poszczególne pakiety, takie jak np. kmail, po prostu |
| 93 |
- wykonujemy <c>emerge kmail</c> |
| 94 |
- </li> |
| 95 |
- <li> |
| 96 |
- Aby zainstalować podstawowe środowisko kde, umożliwiające zalogowanie się do |
| 97 |
- minimalnej sesji KDE, wpisujemy <c>emerge kdebase-startkde</c> |
| 98 |
- </li> |
| 99 |
- <li> |
| 100 |
- Aby uzyskać dokładny odpowiednik jednego z monolitycznych pakietów - na |
| 101 |
- przykład, aby zainstalować wszystkie aplikacje znajdujące się w |
| 102 |
- <c>kdebase</c> za pomocą podzielonych ebuildów - można wykonać <c>emerge |
| 103 |
- kdebase-meta</c> (lub <c>kdepim-meta</c> dla kdepim, itd.) Aby zainstalować |
| 104 |
- absolutnie wszystkie rozdzielone ebuildy KDE używamy <c>emerge kde-meta</c>. |
| 105 |
- </li> |
| 106 |
-</ul> |
| 107 |
- |
| 108 |
-</body> |
| 109 |
-</section> |
| 110 |
-<section> |
| 111 |
-<title>Jak przejść z monolitycznego KDE na rozdzielone ebuildy?</title> |
| 112 |
-<body> |
| 113 |
- |
| 114 |
-<p> |
| 115 |
-Kiedy jest zainstalowane KDE 3.3.x, można po prostu wpisać polecenie <c>emerge |
| 116 |
-kde-meta</c>, aby zainstalować rozdzielone KDE 3.5.x bez naruszania obecnej |
| 117 |
-instalacji. |
| 118 |
-</p> |
| 119 |
- |
| 120 |
-<p> |
| 121 |
-Jeśli zainstalowane jest monolityczne KDE 3.4.x lub 3.5.x, trzeba najpierw je |
| 122 |
-usunąć, a dopiero potem przystąpić do instalacji wersji podzielonej. Można tego |
| 123 |
-dokonywać tylko na wybranych pakietach, nie trzeba od razu usuwać całości. |
| 124 |
-</p> |
| 125 |
- |
| 126 |
-<p> |
| 127 |
-Nie należy obawiać się, że przejście na rozdzielone ebuildy może cokolwiek |
| 128 |
-zepsuć. Portage posiada system blokad, które zapewniają, że jeśli coś da się |
| 129 |
-bezpośrednio zainstalować, to będzie to działało prawidłowo. |
| 130 |
-</p> |
| 131 |
- |
| 132 |
-</body> |
| 133 |
-</section> |
| 134 |
-<section> |
| 135 |
-<title>Zalety rozdzielonych ebuildów</title> |
| 136 |
-<body> |
| 137 |
- |
| 138 |
-<p> |
| 139 |
-Oto krótka lista korzyści z przejścia na rozdzielone ebuildy: |
| 140 |
-</p> |
| 141 |
- |
| 142 |
-<ul> |
| 143 |
- <li> |
| 144 |
- Większość programów KDE nie zmienia się pomiędzy drugorzędnymi wydaniami |
| 145 |
- KDE. Na przykład, aktualizacja KDE z wersji 3.3.1 na 3.3.2 zmienia mniej niż |
| 146 |
- 100 aplikacji z 320. Podzielone paczki, umożliwiają tworzenie nowych |
| 147 |
- ebuildów tylko dla paczek, które zostały zmienione, oszczędzając (w tym |
| 148 |
- przykładzie) więcej niż dwie trzecie czasu kompilacji na aktualizację. |
| 149 |
- </li> |
| 150 |
- <li> |
| 151 |
- Poprawki zazwyczaj dotyczą konkretnych aplikacji. Dzięki nowej filozofii |
| 152 |
- mogą być testowane, zatwierdzane i oddawane szybciej, a więc deweloperzy |
| 153 |
- będą mieli mniej do zrobienia. Poza tym, jak już wyżej napisałem, zwykły |
| 154 |
- użytkownik będzie zużywał znacznie mniej czasu na aktualizację, co jest to |
| 155 |
- szczególnie ważne przy aktualizacjach związanych z bezpieczeństwem. |
| 156 |
- </li> |
| 157 |
- <li> |
| 158 |
- Użytkownicy innych środowisk graficznych i lżejszych menadżerów okien mogą |
| 159 |
- zainstalować kilka aplikacji KDE, jeśli zechcą, bez ogromnych zależności, |
| 160 |
- które powodowały stare ebuildy takie jak <c>kdebase</c> czy <c>kdepim</c>. |
| 161 |
- </li> |
| 162 |
- <li> |
| 163 |
- Użytkownicy mogą wybrać teraz aplikacje jakie mają zainstalowane. Powody |
| 164 |
- mogą być różne: |
| 165 |
- |
| 166 |
- <ul> |
| 167 |
- <li> |
| 168 |
- Zależy im na czasie kompilacji. <c>emerge kdebase kdepim kdenetwork</c> |
| 169 |
- trwa strasznie długo, a tak naprawdę potrzebne im są jedynie |
| 170 |
- <c>konqueror</c>, <c>kmail</c> i <c>kopete</c>. |
| 171 |
- </li> |
| 172 |
- <li> |
| 173 |
- Zależy im na niezaśmiecaniu dysku. Każda nieużywana aplikacja sprawia, że |
| 174 |
- cenne megabajty się marnują. Dysk z większą ilością wolnego miejsca też wtedy |
| 175 |
- oddycha swobodniej; jest szybszym i szczęśliwszym dyskiem. |
| 176 |
- </li> |
| 177 |
- <li> |
| 178 |
- Troszczą się o bezpieczeństwo systemu. Każde zainstalowane oprogramowanie |
| 179 |
- jest potencjalnym celem ataku i dlatego nie należy instalować niczego co nie |
| 180 |
- jest potrzebne. |
| 181 |
- </li> |
| 182 |
- <li> |
| 183 |
- Dokładnie poznali <uri link="/main/pl/philosophy.xml"> filozofię Gentoo</uri> |
| 184 |
- i nie mogą znieść tak wielu programów ściśniętych w jeden pakiet? My też nie |
| 185 |
- możemy. |
| 186 |
- </li> |
| 187 |
- </ul> |
| 188 |
- </li> |
| 189 |
- <li> |
| 190 |
- Ostatecznie, należy zaznaczyć, że rozdzielone ebuildy zapewniają znacznie |
| 191 |
- większą elastyczność w definiowaniu dla nich flag USE. |
| 192 |
- </li> |
| 193 |
-</ul> |
| 194 |
- |
| 195 |
-</body> |
| 196 |
-</section> |
| 197 |
-<section> |
| 198 |
-<title>Współpraca rozdzielonych i monolitycznych ebuildów.</title> |
| 199 |
-<body> |
| 200 |
- |
| 201 |
-<p> |
| 202 |
-Rozdzielone i monolityczne ebuildy mogą swobodnie razem współpracować. Jedynym |
| 203 |
-ograniczeniem jest to, że ebuild monolityczny nie może być jednocześnie |
| 204 |
-zainstalowany razem z rozdzielonym pochodzącym od niego. W ebuildach KDE |
| 205 |
-istnieją mechanizmy blokowania nie zezwalające na to, zatem można robić |
| 206 |
-wszystko na co tylko emerge pozwoli. |
| 207 |
-</p> |
| 208 |
- |
| 209 |
-<p> |
| 210 |
-Jednak zwykle nie ma powodu, aby używać takich mieszanych konfiguracji. W |
| 211 |
-rzeczywistości, za wyjątkiem specjalnych przypadków jak na przykład bardzo wolne |
| 212 |
-komputery (mips), należy używać rozdzielonych ebuildów do wszystkich swoich |
| 213 |
-potrzeb. |
| 214 |
-</p> |
| 215 |
- |
| 216 |
-<p> |
| 217 |
-Rozdzielone ebuildy są także tymi domyślnymi. Oznacza to, że kiedy jakieś inne |
| 218 |
-ebuildy zależą od aplikacji KDE to bedą chciały instalować właśnie te |
| 219 |
-rozdzielone ebuildy. Jednakże monolityczne ebuildy także spełnią te zależności, |
| 220 |
-więc można zainstalować monolityczny ebuild ręcznie i wtedy dopiero ebuild który |
| 221 |
-od niego zależał. |
| 222 |
-</p> |
| 223 |
- |
| 224 |
-</body> |
| 225 |
-</section> |
| 226 |
-</chapter> |
| 227 |
- |
| 228 |
-<chapter> |
| 229 |
-<title>Problemy z wydajnością.</title> |
| 230 |
-<section> |
| 231 |
-<title>Dlaczego rozdzielone ebuildy są takie powolne?</title> |
| 232 |
-<body> |
| 233 |
- |
| 234 |
-<p> |
| 235 |
-Mówiliśmy już <uri |
| 236 |
-link="http://bugs.gentoo.org/show_bug.cgi?id=11123">dawno</uri>, że rozdzielone |
| 237 |
-ebuildy instalują się dłużej niż te monolityczne, ponieważ dodatkowo dla każdej |
| 238 |
-aplikacji musi zostać uruchomione rozpakowywanie i uruchamianie skryptu |
| 239 |
-konfiguracyjnego. Kompletne <c>emerge kde-meta</c> może zabrać około 20-30% |
| 240 |
-więcej czasu niż klasyczne <c>emerge kde</c>, które i tak zajmowało go już |
| 241 |
-mnóstwo. |
| 242 |
-</p> |
| 243 |
- |
| 244 |
-<p> |
| 245 |
-Co więcej, teraz każdy z rozdzielonych ebuildów uruchamia <c>make -f |
| 246 |
-admin/Makefile.cvs</c> (to oznacza uruchomienie autoconf, automake, itd. oraz |
| 247 |
-kilka powiązanych specyficznych dla KDE skryptów). To powoduje dodatkowe |
| 248 |
-narzuty czasowe w przybliżeniu równe tym spowodowanym przez skrypt configure. |
| 249 |
-</p> |
| 250 |
- |
| 251 |
-<p> |
| 252 |
-Ostatecznie, rozdzielone ebuildy potrzebują wypakować specyficzne pliki z |
| 253 |
-dużych archiwów. Jest to rozwiązanie wolniejsze od rozpakowywania małych |
| 254 |
-dedykowanych archiwów. Jednak tworzenie takich małych archiwów dla systemów, na |
| 255 |
-kórych KDE 3.x jest budowane przy pomocy autotools jest trudnym zadaniem. |
| 256 |
-</p> |
| 257 |
- |
| 258 |
-<p> |
| 259 |
-Warto jeszcze raz podkreślić, że z rozdzielonymi ebuildami czas kompilacji przy |
| 260 |
-aktualizowaniu KDE może zostać znacząco skrócony poprzez aktualizacje tylko |
| 261 |
-tych aplikacji KDE, które naprawdę się zmieniły. Korzyści jakie dają takie |
| 262 |
-pojedyńcze aktualizacje aplikacji zwykle wynagradzają z nawiązką czas stracony |
| 263 |
-podczas pierwszej instalacji KDE z nowych ebuildów. |
| 264 |
-</p> |
| 265 |
- |
| 266 |
-<p> |
| 267 |
-W końcu instalacja całego KDE ma sens tylko jeżeli chcemy zobaczyć jakie |
| 268 |
-aplikacje zawiera KDE lub jeśli tworzymy środowisko dla wielu użytkowników. |
| 269 |
-Jednak większość ludzi używa tylko części z ponad 300 dostępnych aplikacji |
| 270 |
-KDE. Każdy kto naprawdę troszczy się o czas kompilacji, np. właściciele |
| 271 |
-starszych komputerów, mogą zyskać więcej czasu poprzez selektywną instalację |
| 272 |
-programów, niż straciliby w związku z dodatkowymi nakładami czasowymi o których |
| 273 |
-była mowa powyżej. |
| 274 |
-</p> |
| 275 |
- |
| 276 |
-</body> |
| 277 |
-</section> |
| 278 |
-<section> |
| 279 |
-<title>W jaki sposób rozdzielone ebuildy mogą być szybsze?</title> |
| 280 |
-<body> |
| 281 |
- |
| 282 |
-<p> |
| 283 |
-Większość lub nawet wszystkie problemy z wydajnością rozdzielnych ebuildów |
| 284 |
-sprowadzają się do autotoolsów - autoconf, automake i innych narzędzi, które |
| 285 |
-zarządzają procesem budowania <c>./configure;make;make install</c> KDE 3.x. |
| 286 |
-</p> |
| 287 |
- |
| 288 |
-<p> |
| 289 |
-W KDE 4 (o ile nasze informację są prawdziwe) zostanie zaadaptowany kompletnie |
| 290 |
-nowy system kompilacji, który pośród wszystkich innych rzeczy, zdecydowanie |
| 291 |
-zredukuje czas, w którym odpowiednik |
| 292 |
-<c>make -f admin/Makefile.common; ./configure</c> zostanie wykonany. Mamy |
| 293 |
-również nadzieję, że przyczyni się to do znacznie łatwiejszego tworzenia małych |
| 294 |
-archiwów dla każdego rozdzielnego ebuildu poprzez obniżenie czasu generowania |
| 295 |
-odpowiednika skryptów konfiguracyjnych (jeśli takie będą). |
| 296 |
-</p> |
| 297 |
- |
| 298 |
-</body> |
| 299 |
-</section> |
| 300 |
-</chapter> |
| 301 |
- |
| 302 |
-<chapter> |
| 303 |
-<title>Rozdzielne ebuildy - często zadawane pytania</title> |
| 304 |
-<section> |
| 305 |
-<title> |
| 306 |
-Dlaczego niektóre rozdzielne pakiety nie posiadają nowszych wersji ebuildów? |
| 307 |
-</title> |
| 308 |
-<body> |
| 309 |
- |
| 310 |
-<p> |
| 311 |
-Jak wyjaśniliśmy wcześniej nie wszystkie aplikacje są aktualizowane pomiędzy |
| 312 |
-ważnymi wydaniami KDE, zatem nie wszystkie aplikacje otrzymują nowe wersje |
| 313 |
-ebuildów. Dla przykładu, libkdenetwork nie został zaktualizowany w wersji |
| 314 |
-3.5.0_beta2, dlatego ostatnim ebuildem dostępnym z tym wydaniem był 3.5_beta1. |
| 315 |
-</p> |
| 316 |
- |
| 317 |
-<p> |
| 318 |
-Jest to spowodowane wyłącznie chęcią redukcji czasu potrebnego na kompilację |
| 319 |
-podczas aktualizacji. Jeśli stworzylibyśmy ebuilda libkdenetwork-3.5.0_beta2, |
| 320 |
-zainstalowałby on dokładnie te same pliki jak ebuild 3.5_beta1. Dodtkowo |
| 321 |
-aktualizowanych jest wiele zależności tak, aby wszystko działało poprawnie (np. |
| 322 |
-aby żaden z ebuildów nie posiadał w zależnościach libkdenetwork-3.5.0_beta2). |
| 323 |
-</p> |
| 324 |
- |
| 325 |
-</body> |
| 326 |
-</section> |
| 327 |
-<section> |
| 328 |
-<title>Czy nie możemy zrobić teraz tego samego z wykorzystaniem DO_NOT_COMPILE?</title> |
| 329 |
-<body> |
| 330 |
- |
| 331 |
-<p> |
| 332 |
-DO_NOT_COMPILE jest zmienną środowiskową wewnętrznego systemu budowania KDE. |
| 333 |
-Umożliwia selektywne wyłączanie podkatalogów z kompilacji. Niektórzy ludzie |
| 334 |
-używali jej do kompilacji tylko części monolitycznego ebuildu KDE. Na przykład, |
| 335 |
-uruchomienie polecenia <c>DO_NOT_COMPILE=konqueror emerge kdebase</c> |
| 336 |
-zainstalowałoby kdebase bez <c>konquerora</c>. |
| 337 |
-</p> |
| 338 |
- |
| 339 |
-<p> |
| 340 |
-Jednak DO_NOT_COMPILE nigdy nie było w założeniach narzędziem mającym ingerować |
| 341 |
-w operacje menadżera automatycznego budowania pakietów. To po prostu nie działa, |
| 342 |
-może nawet zepsuć system, a poza tym nie było nigdy wspierane. Namawiamy |
| 343 |
-wszystkich, żeby wystrzegali się używania tego narzędzia. |
| 344 |
-</p> |
| 345 |
- |
| 346 |
-<p> |
| 347 |
-A oto kawałek z listy problemów związanych z DO_NOT_COMPILE: |
| 348 |
-</p> |
| 349 |
- |
| 350 |
-<ul> |
| 351 |
- <li> |
| 352 |
- Kompletnie psuje system śledzenia zależności zaimplementowany w Portage. |
| 353 |
- Portage nie wie nic o DO_NOT_COMPILE i myśli że cały monolityczny pakiet |
| 354 |
- został skompilowany i zainstalowany, więc uważa, że dana zależność musi |
| 355 |
- być spełniona. Może to spowodować, że inne programy nie będą się chciały |
| 356 |
- zbudować albo po prostu się nie uruchomią. |
| 357 |
- </li> |
| 358 |
- <li> |
| 359 |
- Wymusza na użytkowniku konieczność znajomości nazw i znaczenia wszystkich |
| 360 |
- istniejących podkatalogów z modułów KDE. Bardzo niewielu użytkowników poza |
| 361 |
- deweloperami KDE, posiada o tym wiedzę, a więc mało kto jest w stanie |
| 362 |
- odpowiednio używać DO_NOT_COMPILE. |
| 363 |
- </li> |
| 364 |
- <li> |
| 365 |
- Poszczególne moduły w podkatalogach KDE mogą być powiązane między sobą |
| 366 |
- zależnościami, mogą wymagać określonego porządku budowania lub obecności |
| 367 |
- innego katalogu nawet jeżeli nie ma być on instalowany. Włożyliśmy dużo |
| 368 |
- pracy w rozdzielone ebuildy tak, aby działały poprawnie pod |
| 369 |
- tym względem. DO_NOT_COMPILE nie jest nawet w części tak dobrym narzędziem, |
| 370 |
- żeby potrafiło uzyskać takie rezultaty, nawet z odpowiednią wiedzą ze strony |
| 371 |
- użytkownika. Jedyną rzeczą jaką można z nim zrobić jest wyłączenie kilku |
| 372 |
- aplikacji z kompilacji. Jest praktycznie niemożliwym, aby z pomocą tego |
| 373 |
- narzędzia zainstalować tylko kilka aplikacji z modułu takiego jak |
| 374 |
- <c>kdebase</c> czy <c>kdepim</c>. |
| 375 |
- </li> |
| 376 |
- <li> |
| 377 |
- Jeśli zainstalowałem powiedzmy kmail wczoraj i dzisiaj chciałbym |
| 378 |
- zainstalować korn używając DO_NOT_COMPILE, pociągnie to za sobą ponowną |
| 379 |
- rekompilację kmail. Oznacza to, że DO_NOT_COMPILE jest zawsze dużo |
| 380 |
- wolniejsze od rozdzielonych ebuildów. |
| 381 |
- </li> |
| 382 |
- <li> |
| 383 |
- DO_NOT_COMPILE nie może zostać użyte do budowanie prekompilowanych paczek |
| 384 |
- (takich jak GRP) zawierających pojedyńcze aplikacje KDE. |
| 385 |
- </li> |
| 386 |
-</ul> |
| 387 |
- |
| 388 |
-</body> |
| 389 |
-</section> |
| 390 |
-<section> |
| 391 |
-<title>Czy nie powoduje to zbyt wielkiego obciążenia opiekunów KDE w Gentoo?</title> |
| 392 |
-<body> |
| 393 |
- |
| 394 |
-<p> |
| 395 |
-Co ciekawe, to pytanie było zadawane bardzo często. Jest mi bardzo miło, że |
| 396 |
-użytkownicy tak dbają o nas, opiekunów ebuildów. Korzystając ze sposobności chcę |
| 397 |
-zapewnić, że zajęliśmy się rozdzielonymi ebuildami KDE z własnej, |
| 398 |
-nieprzymuszonej woli i że nie ma szans żeby ktoś nas od tego odwiódł. :-) |
| 399 |
-</p> |
| 400 |
- |
| 401 |
-<p> |
| 402 |
-Powinienem jeszcze wspomnieć, że opiekunowie innych architektur rzeczywiście |
| 403 |
-narzekali, że będą musieli włożyć więcej wysiłku w testowanie i oznaczanie |
| 404 |
-statusu mnóstwa ebuildów. Pracujemy nad rozwiązaniem tego problemu i właśnie to |
| 405 |
-jest głównym powodem dla którego monolityczne ebuildy są jeszcze dostępne |
| 406 |
-dla KDE 3.5. |
| 407 |
-</p> |
| 408 |
- |
| 409 |
-</body> |
| 410 |
-</section> |
| 411 |
-<section> |
| 412 |
-<title>Czy zamierzacie całkowicie usunąć stare (monolityczne) ebuildy?</title> |
| 413 |
-<body> |
| 414 |
- |
| 415 |
-<p> |
| 416 |
-Ostatecznie taki jest plan. Jednak, dla wszystkich wydań KDE 3.4 będą dostępne |
| 417 |
-zarówno stare, jak i nowe wersje ebuildów. |
| 418 |
-</p> |
| 419 |
- |
| 420 |
-<p> |
| 421 |
-Jeśli ktoś preferuje monolityczne ebuildy zamiast tych rozdzielonych, niech <uri |
| 422 |
-link="http://bugs.gentoo.org">poda</uri> nam swoje powody. |
| 423 |
-</p> |
| 424 |
- |
| 425 |
-</body> |
| 426 |
-</section> |
| 427 |
-<section> |
| 428 |
-<title>Teraz jest tyle ebuildów! Jak mam odnaleźć ten, którego właśnie potrzebuję?</title> |
| 429 |
-<body> |
| 430 |
- |
| 431 |
-<p> |
| 432 |
-Więc, po pierwsze, jeśli wiesz, że pakiet jakiego szukasz był w kdebase, możesz |
| 433 |
-ją otrzymać poprzez <c>emerge kdebase-meta</c> co da taki sam rezultat jak |
| 434 |
-zainstalowanie monolitycznego <c>kdebase</c>. A więc nie ma tu żadnych |
| 435 |
-niedogodności w związku z nowymi ebuildami. |
| 436 |
-</p> |
| 437 |
- |
| 438 |
-<p> |
| 439 |
-Oczywiście wszystkie standardowe metody wyszukiwania paczek także działają. To |
| 440 |
-tak samo jak szukanie aplikacji Gnome... Wystarczy znajomość nazwy aplikacji, |
| 441 |
-której się szuka. |
| 442 |
-</p> |
| 443 |
- |
| 444 |
-<p> |
| 445 |
-Sytuacja mogłaby prawdopodobnie się poprawić dzięki wprowadzenie większej ilości |
| 446 |
--meta ebuildów. Są one tylko listami zależności, a więc nie kosztują wiele |
| 447 |
-pracy. Jednak nie zdecydowaliśmy się jeszcze na to. Byłoby jednak miło gdyby |
| 448 |
-Portage zyskało odpowiednią funkcjonalność zanim zajmiemy się tym szerzej. |
| 449 |
-</p> |
| 450 |
- |
| 451 |
-</body> |
| 452 |
-</section> |
| 453 |
-<section> |
| 454 |
-<title>Jak wylistować/odmergować wszystkie rozdzielone ebuildy pochodzące z danej paczki?</title> |
| 455 |
-<body> |
| 456 |
- |
| 457 |
-<p> |
| 458 |
-Można to przetłumaczyć na wylistowanie wszystkich rozdzielonych ebuildów KDE |
| 459 |
-pochodzących z, powiedzmy, monolitycznego ebuilda KDE. Jeszcze raz, odpowiednia |
| 460 |
-implementacja (taka jak <uri link="/proj/en/glep/glep-0021.html">GLEP 21</uri>) |
| 461 |
-sprawi, że będzie to trywialne. Jednak dzisiaj, musimy się zapoznać w pewnym |
| 462 |
-stopniu z implementacją eclass KDE. |
| 463 |
-</p> |
| 464 |
- |
| 465 |
-<p> |
| 466 |
-kde-functions.eclass definiuje funkcje zwane get-parent-package() oraz |
| 467 |
-get-child-packages() które przeprowadzają tłumaczenie za użytkownika. Te dwie |
| 468 |
-funkcje są poprawnym rozwiązaniem dla postawionego problemu i mogą zostać |
| 469 |
-wykonane z jakiegoś ebuilda albo zewnętrznego skryptu bash. Na przykład: |
| 470 |
-</p> |
| 471 |
- |
| 472 |
-<pre caption="Implementacja eclass KDE"> |
| 473 |
-$ <i>function die() { echo $@; }</i> <comment># pokazuj błędy</comment> |
| 474 |
-$ <i>source /usr/portage/eclass/kde-functions.eclass</i> |
| 475 |
-$ <i>get-parent-package konqueror</i> <comment># nie zadziała, potrzebna jest pełna nazwa</comment> |
| 476 |
-Package konqueror not found in KDE_DERIVATION_MAP, please report bug <comment># zwrócenie błędu</comment> |
| 477 |
-$ <i>get-parent-package kde-base/konqueror</i> <comment># pełnowartościowa nazwa pakietu</comment> |
| 478 |
-kde-base/kdebase <comment># zwrócony wynik</comment> |
| 479 |
-$ <i>get-child-packages kde-base/kdebase</i> |
| 480 |
-<comment>(długa lista pakietów)</comment> |
| 481 |
-</pre> |
| 482 |
- |
| 483 |
-<p> |
| 484 |
-Jeśli skrypt nie został napisany w bashu należy przegrepować |
| 485 |
-kde-functions.eclass w celu wyodrębnienia definicji zmiennej KDE_DERIVATION_MAP, |
| 486 |
-której używają wyżej wymienione funkcje. Zmienna ta zawiera oddzieloną białymi |
| 487 |
-znakami listę słów, każde dwa kolejne słowa przyporządkowują paczkę rodzica |
| 488 |
-do rozdzielonego pliku ebuild - dziecka. |
| 489 |
+Ten dokument został przeniesiony pod adres |
| 490 |
+<uri>/proj/pl/desktop/kde/kde-split-ebuilds.xml</uri>. |
| 491 |
</p> |
| 492 |
|
| 493 |
</body> |
| 494 |
|
| 495 |
|
| 496 |
|
| 497 |
-- |
| 498 |
gentoo-commits@l.g.o mailing list |
Archives