Rozdzielone ebuildy KDE

1.  Rozdzielone ebuildy KDE.

Czym one są?

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.7, natomiast ostatnim niestabilnym (~arch) wydanie 3.5.8. Rozdzielone i monolityczne ebuildy są dostępne w drzewie Portage. Wydanie 4.0 wkrótce znajdzie się w drzewie Portage. Będzie jednak zamaskowane w package.mask z powodu licznych problemów.

• Aby zainstalować poszczególne pakiety, takie jak np. kmail, po prostu wykonujemy emerge kmail
• Aby zainstalować podstawowe środowisko kde, umożliwiające zalogowanie się do minimalnej sesji KDE, wpisujemy emerge kdebase-startkde
• Aby uzyskać dokładny odpowiednik jednego z monolitycznych pakietów - na przykład, aby zainstalować wszystkie aplikacje znajdujące się w kdebase za pomocą podzielonych ebuildów - można wykonać emerge kdebase-meta (lub kdepim-meta dla kdepim, itd.) Aby zainstalować absolutnie wszystkie rozdzielone ebuildy KDE używamy emerge kde-meta.

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.

Zalety rozdzielonych ebuildów

Oto krótka lista korzyści z przejścia na rozdzielone ebuildy:

• Większość programów KDE nie zmienia się pomiędzy drugorzędnymi wydaniami KDE. Na przykład, aktualizacja KDE z wersji 3.3.1 na 3.3.2 zmienia mniej niż 100 aplikacji z 320. Podzielone paczki, umożliwiają tworzenie nowych ebuildów tylko dla paczek, które zostały zmienione, oszczędzając (w tym przykładzie) więcej niż dwie trzecie czasu kompilacji na aktualizację.
• Poprawki zazwyczaj dotyczą konkretnych aplikacji. Dzięki nowej filozofii mogą być testowane, zatwierdzane i oddawane szybciej, a więc deweloperzy będą mieli mniej do zrobienia. Poza tym, jak już wyżej napisałem, zwykły użytkownik będzie zużywał znacznie mniej czasu na aktualizację, co jest to szczególnie ważne przy aktualizacjach związanych z bezpieczeństwem.
• Użytkownicy innych środowisk graficznych i lżejszych menadżerów okien mogą zainstalować kilka aplikacji KDE, jeśli zechcą, bez ogromnych zależności, które powodowały stare ebuildy takie jak kdebase czy kdepim.
• Użytkownicy mogą wybrać teraz aplikacje jakie mają zainstalowane. Powody mogą być różne:
  • Zależy im na czasie kompilacji. emerge kdebase kdepim kdenetwork trwa strasznie długo, a tak naprawdę potrzebne im są jedynie konqueror, kmail i kopete.
  • Zależy im na niezaśmiecaniu dysku. Każda nieużywana aplikacja sprawia, że cenne megabajty się marnują. Dysk z większą ilością wolnego miejsca też wtedy oddycha swobodniej; jest szybszym i szczęśliwszym dyskiem.
  • Troszczą się o bezpieczeństwo systemu. Każde zainstalowane oprogramowanie jest potencjalnym celem ataku i dlatego nie należy instalować niczego co nie jest potrzebne.
  • Dokładnie poznali filozofię Gentoo i nie mogą znieść tak wielu programów ściśniętych w jeden pakiet? My też nie możemy.
• Ostatecznie, należy zaznaczyć, że rozdzielone ebuildy zapewniają znacznie większą elastyczność w definiowaniu dla nich flag USE.

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ł.

2.  Problemy z wydajnością.

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.

W KDE 4 (o ile nasze informację są prawdziwe) zostanie zaadaptowany kompletnie nowy system kompilacji, który pośród wszystkich innych rzeczy, zdecydowanie zredukuje czas, w którym odpowiednik make -f admin/Makefile.common; ./configure zostanie wykonany. Mamy również nadzieję, że przyczyni się to do znacznie łatwiejszego tworzenia małych archiwów dla każdego rozdzielnego ebuildu poprzez obniżenie czasu generowania odpowiednika skryptów konfiguracyjnych (jeśli takie będą).

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.

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:

• Kompletnie psuje system śledzenia zależności zaimplementowany w Portage. Portage nie wie nic o DO_NOT_COMPILE i myśli że cały monolityczny pakiet został skompilowany i zainstalowany, więc uważa, że dana zależność musi być spełniona. Może to spowodować, że inne programy nie będą się chciały zbudować albo po prostu się nie uruchomią.
• Wymusza na użytkowniku konieczność znajomości nazw i znaczenia wszystkich istniejących podkatalogów z modułów KDE. Bardzo niewielu użytkowników poza deweloperami KDE, posiada o tym wiedzę, a więc mało kto jest w stanie odpowiednio używać DO_NOT_COMPILE.
• Poszczególne moduły w podkatalogach KDE mogą być powiązane między sobą zależnościami, mogą wymagać określonego porządku budowania lub obecności innego katalogu nawet jeżeli nie ma być on instalowany. Włożyliśmy dużo pracy w rozdzielone ebuildy tak, aby działały poprawnie pod tym względem. DO_NOT_COMPILE nie jest nawet w części tak dobrym narzędziem, żeby potrafiło uzyskać takie rezultaty, nawet z odpowiednią wiedzą ze strony użytkownika. Jedyną rzeczą jaką można z nim zrobić jest wyłączenie kilku aplikacji z kompilacji. Jest praktycznie niemożliwym, aby z pomocą tego narzędzia zainstalować tylko kilka aplikacji z modułu takiego jak kdebase czy kdepim.
• Jeśli zainstalowałem powiedzmy kmail wczoraj i dzisiaj chciałbym zainstalować korn używając DO_NOT_COMPILE, pociągnie to za sobą ponowną rekompilację kmail. Oznacza to, że DO_NOT_COMPILE jest zawsze dużo wolniejsze od rozdzielonych ebuildów.
• DO_NOT_COMPILE nie może zostać użyte do budowanie prekompilowanych paczek (takich jak GRP) zawierających pojedyńcze aplikacje KDE.

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?

Ostatecznie taki jest plan. Jednak, dla wszystkich wydań KDE 3.4 będą dostępne zarówno stare, jak i nowe wersje 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:

$ 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.

Zawartość tego dokumentu jest rozpowszechniana na podstawie licencji Creative Commons - Attribution / Share Alike.