Pomysł ten na pewno nie jest świeży i innowacyjny. Ba, z pewnością nie jest to nawet mój pomysł, ale jako że ostatnio nie czytuję czyichś wypocin i nie śledzę trendu w PLD, postanowiłem przyjrzeć się bliżej takiemu rozwiązaniu, szczególnie że jest wg mnie bardzo ciekawe.
Czym są meta-packages (meta-paczki) ?
Wyobraźmy sobie, że wyjechaliśmy do innego kraju, nie znamy języka, jesteśmy w bardzo dużym mieście, nie mamy pojęcia o gotowaniu i jakie składniki są nam do tego potrzebne, a chcielibyśmy pójść na zakupy. Przydałby się nam asystent, który znałby język i przynajmniej wiedział co kupić by zrobić np. schabowego z ziemniaczkami i surówką z kapusty pekińskiej i majonezem.
Takim jakby asystentem są meta-paczki. A może lepiej asystentem nazwać ‘poldka’ a meta-paczka to taki spis pakietów potrzebnych by otrzymać smacznego schabowego.
Innymi słowy, są to pakiety, które same w sobie nie zawierają nic innego jak suche informacje jakie ‘zwykłe’ paczki dociągnąć by mieć zainstalowane to co opisuje dana meta-paczka. Clear ?
Praktyczne zastosowanie meta-paczek
Nie znam zupełnie stanu naszego instalatora i płytek .iso. Wiem natomiast, że bardzo wielu nowych użytkowników PLD właśnie w taki sposób chce instalować tą dystrybucje. Przeraża ich instalacja ręczna przy pomocy chroot’a i rescue-cd – mnie to nie dziwi. Wiem również, że na dzień dzisiejszy pakiety opisane w instalatorze jako wchodzące w skład tzw. instalacji -base, -basic, -games czy -serwer są wpisane na stałe w źródła instalatora, co jest złym pomysłem. Sam pomysł “podziału systemu” na takie kategorie już zły nie jest – występuje jednak jedynie przy instalacji prowadzonej przez instalator.
Załóżmy teraz, że istnieją już meta-paczki które właśnie tak podzieliły system – tylko teoretycznie, bo faktycznie istnienie takich meta-paczek niczego nie dzieli, a dodaje tylko funkcjonalność. W ten sposób można odciążyć instalator by po prostu tylko daną meta-paczkę instalował, a jej zależności załatwią resztę sprawy.
Jakie korzyści płyną z meta-paczek przy już zainstalowanym systemie ?
To proste. Załóżmy, że zainstalowaliśmy system w wersji base. Są tam naprawde podstawowe programy, brak X-Window, brak nakładek etc. Poldkowi mówimy, że chcielibyśmy zainstalować KDE. W PLD KDE jest podzielone na dziesiątki paczek i tak naprawdę ciężko laikowi połapać się w tym co naprawdę potrzebuje, a co jest opcjonalne. Instalacja meta-paczki dla KDE:
poldek:/all-avail> install metapackage-kde
dociągnęła by wszystkie niezbędne do uruchomienia KDE paczki, w tym pld-basic, pld-xwindow etc. Pomysł o tyle fajny, że zaawansowanemu użytkownikowi w ogóle nie przeszkadza – w końcu nie musi on korzystać z meta-paczek, a struktura paczek w PLD przez to się nie zmienia.
Konkluzja
Zastanowić należałoby się nad tym, jak wiele paczek miałaby w zależnościach meta-paczka od np. KDE. Czy powinna istnieć jedna meta-paczka zawierająca całe KDE, czy powinno być to znowu podzielone na np. kde-base, kde-biuro, kde-gry etc. Przy coraz to większym zróżnicowaniu i rozdrobnieniu meta-paczek cały pomysł traciłby jednak sens, bo tak naprawdę niczego by nie zmieniał i początkujący użytkownik znowu miałby problem co instalować i jak to się w ogóle nazywa…
Meta-paczki to mocne narzędzie i jeżeli zaczynamy w PLD myśleć o ludziach zaczynających dopiero zabawę z Linuksem to na pewno nie ominie nas głębokie przemyślenie tematu meta. Samo PLD w ten sposób jednak niczego nie traci i dla bardziej obytych w ogóle się nie zmieni – co na pewno jest wielkim plusem.
hmm, w takich metapakietch mozna nawet cala instalcke dac jako zaleznosci
Z KDE to może tak jak w gentoo jest? Całe KDE i KDE-base do wyboru. W gentoo nawet można nie instalować całego KDE-base chyba.
Abstrahując od kwestii kto to zrobi i będzie utrzymywał z wersji na wersję, to jedno mnie zastanawia – co się dzieje w przypadku, gdy metapakiet foo wymaga pakietów a i b, po czym jeden z nich odinstalujemy?
Poleci nam też metapakiet przez co utrudnimy sobie sytuację odinstalowania takiego zestawu później (poza install foo; uninstall foo) ?
W Debianie im jakoś to działa. AfAIR jak usuwasz pakiet a, to metapakiet też usuwasz, a pakiet b zostaje i trzeba go potem ręcznie usunąć.
Właśnie to należy jeszcze przemyśleć, czy meta-pakiet też byłby odinstalowywany, czy może nie. A jeśli tak, to czy on nie zaznaczy wszystkiego co zainstalował… Albo po prostu powiemy sobie, meta-pakiety są _for_newbies_only_ i taki newbie raczej nie będzie się bawił w odinstalowywanie pojedynczych pakietów (i tak nie będzie wiedział jak się nazywają), a jeśli jednak się na to zdecyduje to znazy, że już z meta-pakietów (w danym zakresie) nie chce korzystać.
Metapakiety od dawna sprawdzają się w Mandrivie.
smart> ls task-*
task-3ddesktop task-c-devel task-games task-gnome-minimal task-kde-devel task-xfce task-xfce-plugins
task-c++-devel task-drakx-devel task-gnome task-kde task-x11 task-xfce-minimal
Masz na myśli takie coś:
[krystian@laptom SPECS]$ ls metapackage*
metapackage-gnome.spec
metapackage-gnustep.spec
metapackage-xorg.spec
BTW nie lepiej mieć dodawanie komentarzy na samym dole żeby pisząc komentarz mieć przegląd całej sytuacji?
Np. komuś po przeczytaniu nasuwa się pytani i je zadaje, a potem się okazuje, że już jest pięć razy odpowiedź, bo pięciu innych czytelników już też je zadało…
Krystian: Tak, chodzi mi o coś podobnego. Wiem, że używamy w wielu miejscach meta-pakietów, ale nie w takim stopniu o jakim piszę.
P.S.
Może i masz rację. Niech będzie na dole…
Dzięki.
Nie używamy metapakietów bo ktoś musiałby je zrobić… Zresztą sam o tym wiesz.
To akurat najmniejszy problem. Chętni się zawsze znajdą. Czego nam potrzeba, to jasne wskazówki jak pliki SPEC dla takich paczek mają wyglądać – swego rodzaju standaryzacja. Opis w PLD-doc w CVSie i/lub SVNie bardzo mile widziany – chętnie sporządziłbym sam taki opis, ale do tego potrzebuję pomocy ze strony innych deweloperów.