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