Do stycznia 2005 roku wszystkie te ebuildy w Portage były monolityczne. Było ich tylko 15 (kdabase, kdenetwork, ...) i każdy instalował wiele aplikacji, które w zasadzie nie były zależne od siebie. Nie była to do końca optymalna sytuacja i z pewnością niezbyt zgodna z założeniami Gentoo, jednak była tolerowana przez długi okres czasu.
Nowe rozdzielone pakiety(dla konquerora, kmaila, ...) poprawiły tą sytuację dostarczając odseparowane ebuildy dla każdej poszczególnej aplikacji KDE. To dało nam całkowitą liczbę 330 nowych ebuildów w kategorii kde-base.
Ciągle udostępniamy monolityczne ebuildy dla KDE 3.5. Jednak to te rozdzielone są nowym standardem i nie przewiduje się tworzenia tych monolitycznych dla KDE od wersji 4.0.
Wreszcie, należało by wspomnieć, że istnieją także rozdzielone ebuildy dla Koffice. Instalują one osobno takie programy jak kword, kugar itp.
Jak instalować rozdzielone ebuildy
W momencie pisania tego tekstu ostatnim stabilnym wydaniem KDE było 3.5.8, natomiast ostatnim niestabilnym (~arch) wydanie 3.5.9. Rozdzielone i monolityczne ebuildy są dostępne w drzewie Portage. Wydanie 4.0.x wkrótce znajduje się w drzewie Portage, ale jest zamaskowane.
Jak przejść z monolitycznego KDE na rozdzielone ebuildy?
Kiedy jest zainstalowane KDE 3.3.x, można po prostu wpisać polecenie emerge kde-meta, aby zainstalować rozdzielone KDE 3.5.x bez naruszania obecnej instalacji.
Jeśli zainstalowane jest monolityczne KDE 3.4.x lub 3.5.x, trzeba najpierw je usunąć, a dopiero potem przystąpić do instalacji wersji podzielonej. Można tego dokonywać tylko na wybranych pakietach, nie trzeba od razu usuwać całości.
Nie należy obawiać się, że przejście na rozdzielone ebuildy może cokolwiek zepsuć. Portage posiada system blokad, które zapewniają, że jeśli coś da się bezpośrednio zainstalować, to będzie to działało prawidłowo.
Oto krótka lista korzyści z przejścia na rozdzielone ebuildy:
Współpraca rozdzielonych i monolitycznych ebuildów.
Rozdzielone i monolityczne ebuildy mogą swobodnie razem współpracować. Jedynym ograniczeniem jest to, że ebuild monolityczny nie może być jednocześnie zainstalowany razem z rozdzielonym pochodzącym od niego. W ebuildach KDE istnieją mechanizmy blokowania nie zezwalające na to, zatem można robić wszystko na co tylko emerge pozwoli.
Jednak zwykle nie ma powodu, aby używać takich mieszanych konfiguracji. W rzeczywistości, za wyjątkiem specjalnych przypadków jak na przykład bardzo wolne komputery (mips), należy używać rozdzielonych ebuildów do wszystkich swoich potrzeb.
Rozdzielone ebuildy są także tymi domyślnymi. Oznacza to, że kiedy jakieś inne ebuildy zależą od aplikacji KDE to bedą chciały instalować właśnie te rozdzielone ebuildy. Jednakże monolityczne ebuildy także spełnią te zależności, więc można zainstalować monolityczny ebuild ręcznie i wtedy dopiero ebuild który od niego zależał.
Dlaczego rozdzielone ebuildy są takie powolne?
Mówiliśmy już dawno, że rozdzielone ebuildy instalują się dłużej niż te monolityczne, ponieważ dodatkowo dla każdej aplikacji musi zostać uruchomione rozpakowywanie i uruchamianie skryptu konfiguracyjnego. Kompletne emerge kde-meta może zabrać około 20-30% więcej czasu niż klasyczne emerge kde, które i tak zajmowało go już mnóstwo.
Co więcej, teraz każdy z rozdzielonych ebuildów uruchamia make -f admin/Makefile.cvs (to oznacza uruchomienie autoconf, automake, itd. oraz kilka powiązanych specyficznych dla KDE skryptów). To powoduje dodatkowe narzuty czasowe w przybliżeniu równe tym spowodowanym przez skrypt configure.
Ostatecznie, rozdzielone ebuildy potrzebują wypakować specyficzne pliki z dużych archiwów. Jest to rozwiązanie wolniejsze od rozpakowywania małych dedykowanych archiwów. Jednak tworzenie takich małych archiwów dla systemów, na kórych KDE 3.x jest budowane przy pomocy autotools jest trudnym zadaniem.
Warto jeszcze raz podkreślić, że z rozdzielonymi ebuildami czas kompilacji przy aktualizowaniu KDE może zostać znacząco skrócony poprzez aktualizacje tylko tych aplikacji KDE, które naprawdę się zmieniły. Korzyści jakie dają takie pojedyńcze aktualizacje aplikacji zwykle wynagradzają z nawiązką czas stracony podczas pierwszej instalacji KDE z nowych ebuildów.
W końcu instalacja całego KDE ma sens tylko jeżeli chcemy zobaczyć jakie aplikacje zawiera KDE lub jeśli tworzymy środowisko dla wielu użytkowników. Jednak większość ludzi używa tylko części z ponad 300 dostępnych aplikacji KDE. Każdy kto naprawdę troszczy się o czas kompilacji, np. właściciele starszych komputerów, mogą zyskać więcej czasu poprzez selektywną instalację programów, niż straciliby w związku z dodatkowymi nakładami czasowymi o których była mowa powyżej.
W jaki sposób rozdzielone ebuildy mogą być szybsze?
Większość lub nawet wszystkie problemy z wydajnością rozdzielnych ebuildów sprowadzają się do autotoolsów - autoconf, automake i innych narzędzi, które zarządzają procesem budowania ./configure;make;make install KDE 3.x.
KDE 4 zawiera zupełnie nowy system budowania, cmake, którego jedną z głównych zalet jest znacznie krótszy czas wykonywania polecenia make -f admin/Makefile.common; ./configure.
3. Rozdzielne ebuildy - często zadawane pytania
Dlaczego niektóre rozdzielne pakiety nie posiadają nowszych wersji ebuildów?
Jak wyjaśniliśmy wcześniej nie wszystkie aplikacje są aktualizowane pomiędzy ważnymi wydaniami KDE, zatem nie wszystkie aplikacje otrzymują nowe wersje ebuildów. Dla przykładu, libkdenetwork nie został zaktualizowany w wersji 3.5.0_beta2, dlatego ostatnim ebuildem dostępnym z tym wydaniem był 3.5_beta1.
Warto to zapamiętać, ponieważ gdy chce się zaintalować niektóre zamaskowane wersje KDE, może pojawić się konieczność odmaskowania pakietów ze starszych wersji KDE, jeśli również są zamaskowane. Więcej informacji znajduje się w tym raporcie o błędzie.
Jest to spowodowane wyłącznie chęcią redukcji czasu potrebnego na kompilację podczas aktualizacji. Jeśli stworzylibyśmy ebuilda libkdenetwork-3.5.0_beta2, zainstalowałby on dokładnie te same pliki jak ebuild 3.5_beta1. Dodtkowo aktualizowanych jest wiele zależności tak, aby wszystko działało poprawnie (np. aby żaden z ebuildów nie posiadał w zależnościach libkdenetwork-3.5.0_beta2).
Czy nie możemy zrobić teraz tego samego z wykorzystaniem DO_NOT_COMPILE?
DO_NOT_COMPILE jest zmienną środowiskową wewnętrznego systemu budowania KDE. Umożliwia selektywne wyłączanie podkatalogów z kompilacji. Niektórzy ludzie używali jej do kompilacji tylko części monolitycznego ebuildu KDE. Na przykład, uruchomienie polecenia DO_NOT_COMPILE=konqueror emerge kdebase zainstalowałoby kdebase bez konquerora.
Jednak DO_NOT_COMPILE nigdy nie było w założeniach narzędziem mającym ingerować w operacje menadżera automatycznego budowania pakietów. To po prostu nie działa, może nawet zepsuć system, a poza tym nie było nigdy wspierane. Namawiamy wszystkich, żeby wystrzegali się używania tego narzędzia.
A oto kawałek z listy problemów związanych z DO_NOT_COMPILE:
Czy nie powoduje to zbyt wielkiego obciążenia opiekunów KDE w Gentoo?
Co ciekawe, to pytanie było zadawane bardzo często. Jest mi bardzo miło, że użytkownicy tak dbają o nas, opiekunów ebuildów. Korzystając ze sposobności chcę zapewnić, że zajęliśmy się rozdzielonymi ebuildami KDE z własnej, nieprzymuszonej woli i że nie ma szans żeby ktoś nas od tego odwiódł. :-)
Powinienem jeszcze wspomnieć, że opiekunowie innych architektur rzeczywiście narzekali, że będą musieli włożyć więcej wysiłku w testowanie i oznaczanie statusu mnóstwa ebuildów. Pracujemy nad rozwiązaniem tego problemu i właśnie to jest głównym powodem dla którego monolityczne ebuildy są jeszcze dostępne dla KDE 3.5.
Czy zamierzacie całkowicie usunąć stare (monolityczne) ebuildy?
Jest taki plan. Dla wszystkich wydań KDE 3.x będą dostępne zarówno stare, jak i nowe wersje ebuildów. Dla KDE 4.x nie ma i nie będzie monolitycznych ebuildów.
Jeśli ktoś preferuje monolityczne ebuildy zamiast tych rozdzielonych, niech poda nam swoje powody.
Teraz jest tyle ebuildów! Jak mam odnaleźć ten, którego właśnie potrzebuję?
Więc, po pierwsze, jeśli wiesz, że pakiet jakiego szukasz był w kdebase, możesz ją otrzymać poprzez emerge kdebase-meta co da taki sam rezultat jak zainstalowanie monolitycznego kdebase. A więc nie ma tu żadnych niedogodności w związku z nowymi ebuildami.
Oczywiście wszystkie standardowe metody wyszukiwania paczek także działają. To tak samo jak szukanie aplikacji Gnome... Wystarczy znajomość nazwy aplikacji, której się szuka.
Sytuacja mogłaby prawdopodobnie się poprawić dzięki wprowadzenie większej ilości -meta ebuildów. Są one tylko listami zależności, a więc nie kosztują wiele pracy. Jednak nie zdecydowaliśmy się jeszcze na to. Byłoby jednak miło gdyby Portage zyskało odpowiednią funkcjonalność zanim zajmiemy się tym szerzej.
Jak wylistować/odmergować wszystkie rozdzielone ebuildy pochodzące z danej paczki?
Można to przetłumaczyć na wylistowanie wszystkich rozdzielonych ebuildów KDE pochodzących z, powiedzmy, monolitycznego ebuilda KDE. Jeszcze raz, odpowiednia implementacja (taka jak GLEP 21) sprawi, że będzie to trywialne. Jednak dzisiaj, musimy się zapoznać w pewnym stopniu z implementacją eclass KDE.
kde-functions.eclass definiuje funkcje zwane get-parent-package() oraz get-child-packages() które przeprowadzają tłumaczenie za użytkownika. Te dwie funkcje są poprawnym rozwiązaniem dla postawionego problemu i mogą zostać wykonane z jakiegoś ebuilda albo zewnętrznego skryptu bash. Na przykład:
Listing 3.1: Implementacja eclass KDE |
$ function die() { echo $@; } # pokazuj błędy $ source /usr/portage/eclass/kde-functions.eclass $ get-parent-package konqueror # nie zadziała, potrzebna jest pełna nazwa Package konqueror not found in KDE_DERIVATION_MAP, please report bug # zwrócenie błędu $ get-parent-package kde-base/konqueror # pełnowartościowa nazwa pakietu kde-base/kdebase # zwrócony wynik $ get-child-packages kde-base/kdebase (długa lista pakietów) |
Jeśli skrypt nie został napisany w bashu należy przegrepować kde-functions.eclass w celu wyodrębnienia definicji zmiennej KDE_DERIVATION_MAP, której używają wyżej wymienione funkcje. Zmienna ta zawiera oddzieloną białymi znakami listę słów, każde dwa kolejne słowa przyporządkowują paczkę rodzica do rozdzielonego pliku ebuild - dziecka.
Materiał udostępniany na podstawie licencji Creative Commons - Attribution / Share Alike.