# [X11/xorg] Plusy i minusy rozdzielonego xorg.

## arsen

Gentoo po sukcesie jakim jest rozdzielenie plików ebuild dla kde postanowił zabrać się za monolit xorg.

Jak zapewne część z was zauważyła w portage znalazł się ebuild xorg-x11-7.0.0_rc1.

Jest to metapakiet który instaluje wiele innych ebuildów składajacych się na całe xorg.

W obecnej chwili ilość zależności jest bardzo duża. U mnie tyle:

```

[ebuild  N    ] x11-misc/util-macros                                   [0.99.1]

[ebuild  N    ] x11-proto/kbproto                                      [1.0.1]

[ebuild  N    ] x11-proto/xextproto                                    [7.0.1]

[ebuild  N    ] x11-proto/xproto                                       [7.0.1]

[ebuild  N    ] x11-proto/bigreqsproto                                 [1.0.1]

[ebuild  N    ] x11-proto/inputproto                                   [1.3.1]

[ebuild  N    ] x11-libs/libXau                                        [0.99.1]

[ebuild  N    ] x11-libs/libXdmcp                                      [0.99.1]

[ebuild  N    ] x11-proto/xcmiscproto                                  [1.1.1]

[ebuild  N    ] x11-libs/xtrans                                        [0.99.1]

[ebuild  N    ] x11-libs/libX11                                        [0.99.2]

[ebuild  N    ] x11-proto/fixesproto                                   [3.0.1]

[ebuild  N    ] x11-libs/libXfixes                                     [3.0.0]

[ebuild  N    ] x11-proto/damageproto                                  [1.0.1]

[ebuild  N    ] x11-libs/libXdamage                                    [1.0.1]

[ebuild  N    ] x11-libs/libICE                                        [0.99.0]

[ebuild  N    ] x11-libs/libSM                                         [0.99.1-r1]

[ebuild  N    ] x11-libs/libXt                                         [0.99.1]

[ebuild  N    ] x11-libs/libXext                                       [0.99.1]

[ebuild  N    ] x11-libs/libXmu                                        [0.99.1-r1]

[ebuild  N    ] x11-wm/twm                                             [0.99.1]

[ebuild  N    ] x11-libs/libxkbfile                                    [0.99.1]

[ebuild  N    ] x11-proto/renderproto                                  [0.9.1]

[ebuild  N    ] x11-libs/libXrender                                    [0.9.0]

[ebuild  N    ] x11-libs/libXft                                        [2.1.8]

[ebuild  N    ] x11-libs/libXpm                                        [3.5.3]

[ebuild  N    ] sys-apps/ed                                            [0.2-r6]

[ebuild  N    ] x11-libs/libXaw                                        [0.99.1]

[ebuild  N    ] x11-apps/xclock                                        [0.99.1]

[ebuild  N    ] x11-apps/xinit                                         [0.99.2-r1]

[ebuild  N    ] x11-proto/xf86miscproto                                [0.9.1]

[ebuild  N    ] x11-libs/libXxf86misc                                  [0.99.1]

[ebuild  N    ] x11-proto/trapproto                                    [3.4.1]

[ebuild  N    ] x11-proto/compositeproto                               [0.2.1]

[ebuild  N    ] x11-proto/dmxproto                                     [2.2.1]

[ebuild  N    ] x11-proto/xf86dgaproto                                 [2.0.1]

[ebuild  N    ] x11-proto/videoproto                                   [2.2.1]

[ebuild  N    ] x11-proto/recordproto                                  [1.13.1]

[ebuild  N    ] x11-libs/libXtst                                       [0.99.1]

[ebuild  N    ] x11-libs/libdmx                                        [0.99.1]

[ebuild  N    ] x11-apps/rgb                                           [0.99.1]

[ebuild  N    ] x11-apps/iceauth                                       [0.99.1]

[ebuild  N    ] x11-proto/fontsproto                                   [2.0.1]

[ebuild  N    ] x11-proto/xf86rushproto                                [1.1.1]

[ebuild  N    ] x11-libs/libfontenc                                    [0.99.1]

[ebuild  N    ] x11-apps/mkfontscale                                   [0.99.1]

[ebuild  N    ] media-fonts/encodings                                  [0.99.0]

[ebuild  N    ] media-fonts/font-util                                  [0.99.1]

[ebuild  N    ] media-fonts/font-alias                                 [0.99.0]

[ebuild  N    ] x11-proto/fontcacheproto                               [0.1.1]

[ebuild  N    ] x11-libs/libXfont                                      [0.99.1]

[ebuild  N    ] x11-apps/bdftopcf                                      [0.99.1]

[ebuild  N    ] x11-apps/mkfontdir                                     [0.99.1]

[ebuild  N    ] media-fonts/font-misc-misc                             [0.99.0]

[ebuild  N    ] x11-libs/libxkbui                                      [0.99.0]

[ebuild  N    ] media-fonts/font-cursor-misc                           [0.99.0]

[ebuild  N    ] x11-proto/glproto                                      [1.4.1]

[ebuild  N    ] x11-proto/resourceproto                                [1.0.1]

[ebuild  N    ] x11-libs/libXres                                       [0.99.1]

[ebuild  N    ] x11-proto/randrproto                                   [1.1.1]

[ebuild  N    ] x11-misc/makedepend                                    [0.99.1]

[ebuild  N    ] x11-proto/xf86vidmodeproto                             [2.2.1]

[ebuild  N    ] x11-libs/libXxf86vm                                    [0.99.1]

[ebuild  N    ] x11-libs/libXi                                         [0.99.1]

[ebuild  N    ] x11-libs/libdrm                                        [1.0.5]

[ebuild  N    ] media-libs/mesa                                        [6.4]

[ebuild  N    ] x11-proto/xineramaproto                                [1.1.1]

[ebuild  N    ] x11-apps/xauth                                         [0.99.1-r1]

[ebuild  N    ] x11-misc/xbitmaps                                      [0.99.1]

[ebuild  N    ] x11-apps/xkbcomp                                       [0.99.1-r1]

[ebuild  N    ] x11-misc/xkbdata                                       [0.99.1-r1]

[ebuild  N    ] x11-proto/evieext                                      [1.0.1]

[ebuild  N    ] x11-proto/xf86bigfontproto                             [1.1.1]

[ebuild  N    ] x11-proto/scrnsaverproto                               [1.0.1]

[ebuild  N    ] x11-base/xorg-server                                   [0.99.2-r1]

[ebuild  N    ] media-fonts/font-adobe-utopia-type1                    [0.99.0]

[ebuild  N    ] x11-apps/xmodmap                                       [0.99.1]

[ebuild  N    ] x11-libs/libXcomposite                                 [0.2.1]

[ebuild  N    ] x11-libs/libXv                                         [0.99.1]

[ebuild  N    ] x11-libs/libXxf86dga                                   [0.99.1]

[ebuild  N    ] x11-apps/xhost                                         [0.99.1-r1]

[ebuild  N    ] media-fonts/font-bh-ttf                                [0.99.0]

[ebuild  N    ] media-fonts/font-bitstream-type1                       [0.99.0]

[ebuild  N    ] x11-libs/libXcursor                                    [1.1.4]

[ebuild  N    ] x11-libs/libXinerama                                   [0.99.1]

[ebuild  N    ] x11-apps/setxkbmap                                     [0.99.1-r1]

[ebuild     U ] x11-base/xorg-x11                                      [7.0.0_rc1]                 [6.8.99.15-r4]

```

Wątek niech wam służy także do wymiany poglądów na temat rozdzielonego xorg.

----------

## pwe

ja właśnie ostatnio w unsuported software zobaczyłem i przeczytałem ze wyszedł ebuild Xorg calościowy z dopieskiem ze to w portage takich nie bedzie   :Rolling Eyes:  musze poczyatć bo "średnio" sie orienyuje o co biega w tym podziale i czemu ma to służyc   :Embarassed:   :Rolling Eyes: 

----------

## n3rd

Myślę, że nie trzeba mówić, że pomysł jest dobry czy zły... Rozdzielenie xorg na moduły to... konieczność. Stare xfree to jeden wielki monolit... większy od jądra Linuksa... a w takim wielkim kodzie bardzo łatwo o błędy. Rozdzielenie xorg na moduły jest pierwszym krokiem do opracowania X-ów pozwalających na lepszą konigurowalność i dostosowanie do własnych potrzeb oraz daje szanse na lepsze odbugowanie kodu. Jestem zdania arsenie, że wymiana poglądów na ten temat będzie trochę przypominała zastanawianie się nad tym.. w czym gentoo jest lepsze od takich całościowo opracowanych Winduksów jak Fedora, Mandriva... Xandros..   :Laughing: 

Az miło patrzeć na zmiany zachodzące w xorg  :Wink: 

Pozdrawiam

daniel cegielka

----------

## arsen

@N3rd: 

Nie sądzę że dyskusja może być w ogóle nie potrzebna, mnie osobiście w tej postaci się to nie podoba, i dla mnie jest nie dopuszczalne by jeden pakiet był rozbity na blisko 90 ebuildów, jest to moim zdaniem drobna przesada, np. x11-proto mogli zrobić w jednej paczce niż to rozbijać. Wątek ten otworzyłem by właśnie to przedystkutować.

----------

## psycepa

z tego co wyczytalem gdzies na stronce do ktorej linka znalazlem zreszta tu na forum, xorg juz dawno przymierzalo sie do rozbicia calego projektu na moduly, miedzy innymi w celu odbugowania, jak to juz ktos tu wspomnial, czy ogolnie w celu latwiejszego utrzymania i zarzadzania projektem, 

natomiast gentoo... no coz, jesli chodzi o ebuildy, to chyba nie bylo by wiekszego problemu by wilk byl syty i owca cala, gentoo w koncu to wolnosc wyboru, dlaczego wiec nie zrobic jednego ebuilda ktory by mergowal caly xfree ze wszstkimi swoimi zaleznosciami, i dodatkowo ( a moze raczej przede wszystkim) set ebuildow do kazdego modulu z osobna, i w tym momencie kto chce szybko zmergowac cale X bez bawienia sie w wybieranie kawalkow tego tortu, to merguje calosc, kto chce dostosowac pod siebie, merguje po kawalku....

pozdrawiam

----------

## n3rd

 *arsen wrote:*   

> @N3rd: 
> 
> (...)dla mnie jest nie dopuszczalne by jeden pakiet był rozbity na blisko 90 ebuildów, jest to moim zdaniem drobna przesada, np. x11-proto mogli zrobić w jednej paczce niż to rozbijać.

 

Zawsze można patrzeć na ten problem z tej strony, że można było w Portage zrobić jeden "wielki" ebuild instalujący co trzeba i konfigurowany za pomocą flag USE - wtedy normalny user nawet nie wiedziałby o tych czy "innych zależnościach"   :Laughing:  Jednocześnie przy tych 90 ebuildach łatwo naprawić te ebuildy, na których instalacja się wykłada - od razu wiemy, że chodzi o okreslony ebuild (paczkę) i łatwiej jest zlokalizować problem. Co prawda w przypadku jednego ebuildu lokalizacja problemu też nie stanowi wielkiego problemu dla bardziej zaawansowanego usera... ale w przypadku początkującego łatwiej będzie zdiagnozować problem gdy w poście na forum będzie napisane, że "instalacja xorg wykłada się na pakiecie XXX..." a nie gdy byłoby napisane ogólnie... że instalacja xorg się wykłada.

O co więc tak naprawdę chodzi? O to, że xorg jest podzielone na moduły i nie stanowi już jednego wielkiego monolitu, czy o to, że w portage postanowiono zrobić osobne ebuildy dla poszczególnych pakietów zamiast jeden wielki i złożony (czy. podatny na błędy) ebuild  :Wink: 

pozdr

daniel

Update: Widzę, że podczas gdy pisałem swój post, psycepa również opisał to, o co mi chodziło w tym poście.

Update 2: A aktualizacje xorg? W przypadku jednego ebuildu przekompilowana musiałby być całość.. a to raczej trwa trochę czasu  :Wink:  Kiedy xorg jest rozbity na wiele ebuildów, można aktualizowac tylko to, co tego wymaga a nie całość.

----------

## Raku

IMO tu są tylko same pozytywy wynikające z modularyzacji. Dlaczego każda łatka (poprawiająca błędy związane z funkcjonalnością czy bezpieczeństwem) musi powodować rekompilację całego xorga? Zamiast załatać jeden wadliwy moduł (którego kompilacja może zająć kilka minut), musisz kompilować całą kobyłę...

Zresztą, jesli to będzie zrobione na sposób podobny do kde-meta, to nie widze przeszkód - ty emergujesz xorg, a te 90 pakietów same się ściągną i zainstalują, będąc w zależnościach jednego meta-pakietu. Więc w czym problem?

----------

## BeteNoire

Jestem za! 

Popatrzcie jak to jest rozwiązane w Slackware - paczki dla poszczególnych modułów Xorg. W Gentoo też tak powinno być. Po co mi taki naprzykład Xnest skoro go nie używam?

----------

## Xax

Ja jestem za. Kompilowanie calego xorga na moim wysluzonym, ale niezbednym celeronie 466 zdziebko trwa. A ja lubie robic updaty dosyc czesto.

----------

## arsen

heh, nie zrozumieliście mnie do końca, oczywiście nie co podważać faktu że plusem będzie np. łatwość upgradu, i kilku innych czynników, tylko że w obecnej fazie mało z tej modularyzacji wynika, mianowicie chodzi mi że metaebuild i tak instaluje wszystko co się składało na monolityczne xorg, sprawę osobiście by mi uratował metaebuild xorg-minimal czy coś w tym stylu.

----------

## n3rd

Tu arsenie bardzo się z Tobą zgadzam... i jednocześnie rozumiem Twoje rozgoryczenie, jak zobaczyłeś te 90 ebuildów. Myślę, że chodzi tu głównie o... mentalność  :Wink:  Twoje konfigi, które udostępniasz, są bardzo mocno dobracowane.. dokładne itd. Dalej, z tych konfigów (oraz screenów) wynika, że masz system szyty bardzo na miarę.. bez zbędnych dodatków i bajerów. I mam takie uczucie, ze bardzo mocno cenisz sobie organizację swojego systemu, to, że wiesz co w nim jest czym... itd. (to bardzo dobrze o Tobie świadczy  :Wink:  ). I teraz jak się zobaczy 90 ebuildów zamiast jednego, to nie ma się czemu dziwić, że jesteś negatywnie zaskoczony. Co więcej, gdy okazuje się, że te zależności, to nie opcje pozwalające na wybór ale pakiety konieczne do zainstalowania... zaczyna robić się trochę niewesoło.

Myślę jednak, że z czasem ebuildy xorg zostaną tak zoptymalizowane, że wszystkim wyjdzie to na dobre... i nie będzie ich przesadnie wiele, jak i będzie można wybrać to, czego się oczekuje... bez zbędnych zależności  :Wink: 

Nikt nie lubi bałaganu w systemie  :Wink: 

Pozdrawiam

daniel

----------

## Xax

Z cala pewnoscia rozbicie xorga na mniejsze "kawalki" bedzie mialo wiekszy sens wtedy, gdy bedzie mozna decydowac, ktore to "kawalki" chce sie miec zainstalowane, a ktore nie. Choc i sama idea pozniejszego updatu tylko tych elementow, ktore faktycznie zostaly poprawione jest interesujaca, bo jak wiadomo xorgo to najmniejszy nie jest i swoje wymagania czasowe podczas instalacji ma. Poprawia sterwoniki do klawiatury, a instalowac trzeba wszystko.

Jest to swiezy pomysl i kto chce moze go przetestowac i podzielic sie uwagami z developerami, ktorzy dla samej tylko idei rozbicia xorga tego chyba nie zrobili. Zobaczymy jak sie to dalej rozwinie.

Ja mam nadzieje, ze w niedalekiej przyszlosci bedzie mozna sobie nieco xorga odchudzic, a maniacy instalowania tylko tego co ich zdaniem jest im potrzebne beda mieli kawalek swiezego mieska do rozszarpania i zajecie na dlugie, zimowe wieczory.

----------

## Poe

fajny pomysl, ale wykonanie zdeksza, przesadzone.. IMHO za duzo tych buildow jest. z polowe mniej tego powinno byc.. przeciez wielu nawet nie wiem po co to jest  :Very Happy: 

----------

## C1REX

Mi się bardzo podoba pomysł rozbicia na moduły. 

Im większe rozdrobnienie, tym dokładniej można sprawdzić każdy składnik. Ułatwia też odchudzenie xorg do własnych potrzeb.

Powinno jednak powstać coś w rodzaju meta pakietów z kde, gdzie poza całym kde lub małymi cząstkami, można też zassać mały zestaw - np. kdemultimedia.

Tak czy inaczej, to takie rozwiązanie jest lepsze, niż jedno duże xorg.

----------

## arsen

 *n3rd wrote:*   

> Tu arsenie bardzo się z Tobą zgadzam... i jednocześnie rozumiem Twoje rozgoryczenie, jak zobaczyłeś te 90 ebuildów. Myślę, że chodzi tu głównie o... mentalność  Twoje konfigi, które udostępniasz, są bardzo mocno dobracowane.. dokładne itd. Dalej, z tych konfigów (oraz screenów) wynika, że masz system szyty bardzo na miarę.. bez zbędnych dodatków i bajerów. I mam takie uczucie, ze bardzo mocno cenisz sobie organizację swojego systemu, to, że wiesz co w nim jest czym... itd. (to bardzo dobrze o Tobie świadczy  ). I teraz jak się zobaczy 90 ebuildów zamiast jednego, to nie ma się czemu dziwić, że jesteś negatywnie zaskoczony. Co więcej, gdy okazuje się, że te zależności, to nie opcje pozwalające na wybór ale pakiety konieczne do zainstalowania... zaczyna robić się trochę niewesoło.
> 
> Nikt nie lubi bałaganu w systemie 
> 
> Pozdrawiam
> ...

 

cholera, no normalnie mnie przejżałeś heheh.

EDIT:

Jestem po instalacji tego xorg dla próby, i schody, brakowało jednej biblioteki x11-libs/libXvMC

która nie jest ujęta w zależnościach a kupa binarek u mnie była z tym libsem polinkowana, na koniec to nie wszystko, xorg nie udało mi się w ogóle wystartować, w logach tylko informacja że nie mógł załadować brakujących modułów "mouse" "kbd" czyli mysz i klawiatura, po godzinnej walce odpuściłem, usunełem xorg-x11, w tym miejscu zostałem olany nawet przez deep-clean który nie zobaczył ani jednego pakietu do usunięcia i całość musiałem usuwać na podstawie loga emerge.log. No ja poczekam raczej na stable i na jakąś dokumentacje ze strony gentoo.

----------

## n3rd

@arsen

Współczuję... Z tych schodów, które opisałeś wynika, że za stable przyjdzie bardzo długo jeszcze poczekać.

A co do konfigów, to naprawdę są bardzo dopracowane... nawet puste wiersze wszędzie zostawiasz jednakowe  :Laughing: 

pozdr

----------

## arsen

co do tych błędów z brakiem modułów kbd i mouse to podobno wystarczy zainstalować:

```

x11-drivers/xf86-input-mouse

x11-drivers/xf86-input-keyboard

```

przynajmniej tak wyczytałem. Niestety teraz nie kompiluje mi się libX11 mimo że wcześniej się skompilowało, heh.

----------

## Raku

 *arsen wrote:*   

> mianowicie chodzi mi że metaebuild i tak instaluje wszystko co się składało na monolityczne xorg, sprawę osobiście by mi uratował metaebuild xorg-minimal czy coś w tym stylu.

 

ale przecież tak samo jest z KDE!!! kde-meta instaluje wszystko. A ja widzę tu tylko jedno możliwe rozwiązanie: kopiujesz ebuild do lokalnego portage, zmieniasz mu nazwę dla wygody i usuwasz z niego wszystko co nie jest ci potrzebne. I masz meta ebuild uszyty na miarę. I to jest IMO jedyne słuszne rozwiązanie.

Wersja minimal to była by dopiero porażka. Dlaczego z jednej skrajności popadac od razu w drugą? Skoro ktoś nie chce pełego xorg (czy KDE czy Gnome czy czegoś tam innego kobylastego), to dlaczego od razu zakładać, że chce mieć absolutne minimum? Świat nie dzieli się na totalnych geniuszy i zupełnych idiotów. Większość to ludzie przeciętni (a każdy jest inny). I myślę, że to porównanie można odnieść do użytkowników komputerów. Największa część osób korzystających z meta-pakietów chciałaby dopasować go właśnie do swoich potrzeb. Nie minimum czy maksimum, ale coś pośrodku, z tendencją w jedną lub drugą stronę. Więc niech sobie wyedytuje ebuilda i uszyje gosobie na miarę...

----------

## rasheed

Sam pomysł dobry ale wydaje mi się, że za dużo tych ebuildów. Po redukcji do ~30 byłoby o wiele lepiej.

----------

## arsen

 *raku wrote:*   

> 
> 
> ale przecież tak samo jest z KDE!!! kde-meta instaluje wszystko. A ja widzę tu tylko jedno możliwe rozwiązanie: kopiujesz ebuild do lokalnego portage, zmieniasz mu nazwę dla wygody i usuwasz z niego wszystko co nie jest ci potrzebne. I masz meta ebuild uszyty na miarę. I to jest IMO jedyne słuszne rozwiązanie.
> 
> Wersja minimal to była by dopiero porażka. Dlaczego z jednej skrajności popadac od razu w drugą? Skoro ktoś nie chce pełego xorg (czy KDE czy Gnome czy czegoś tam innego kobylastego), to dlaczego od razu zakładać, że chce mieć absolutne minimum? Świat nie dzieli się na totalnych geniuszy i zupełnych idiotów. Większość to ludzie przeciętni (a każdy jest inny). I myślę, że to porównanie można odnieść do użytkowników komputerów. Największa część osób korzystających z meta-pakietów chciałaby dopasować go właśnie do swoich potrzeb. Nie minimum czy maksimum, ale coś pośrodku, z tendencją w jedną lub drugą stronę. Więc niech sobie wyedytuje ebuilda i uszyje gosobie na miarę...

 

twoje myślenie jest błędne, jasne że jest kde-meta, ale jest też kdebase-startkde jakbyś nie zauważył, czyli podstawowa wersja do wystartowania, zadowala to dwie strony, więc nie wiem po co te aluzje z twojej strony, tak się składa że wiele userów gentoo ma ten system bo ma wybór. 

Druga sprawa, jasne że mogę zrobić swój meta-ebuild ale za każdym razem bym musiał o niego dbać, w ogóle w tym przypadku bez bardzo dobrej znajomości xorg by się nie obyło.

----------

## Raku

ok - powinna być wersja maksymalna i minimalna. Tu się zgadzam. Aluzji żadnych nie czyniłem (jeśli chodzi ci o geniuszy i kretynów - tak mi się po prostu skojarzyło, coś jest na maks coś na minimum  :Wink: . Ja po prostu mam takie skojarzenia. Może zbyt dużo czasu przy komputerze spędzam ?  :Embarassed: ).

Zadowala dwie strony, piszesz - czyli minimalistów i maksymalistów. Jeśli znasz krzywą Gaussa, to pewnie wiesz, że takich jest najmniej w całej populacji. Reszta to ci moi średniacy - co chcieli by mieć trochę więcej niż minimum, ale też nie wszystko na raz.

a teraz do sedna: bronię swojego zdania z budową własnych ebuildów. Jeśli chcesz dopasować jakiegoś molocha idealnie do twoich potrzeb, tylko w ten sposób jesteś w stanie to zrobić. Chyba że chcesz ręcznie instalować 35 pakietów (bo minimalna wersja ma ich powiedzmy 5, a maksymalna 120). Jest jasne, że zrobiłbyś to jakimś skryptem (a czym innym jest własny meta-ebuild????) Jeśli chodzi o zarządzanie: raz na wydanie dużej wersji musisz sobie przebudować te skrypty. To nie jest zbyt dużo roboty, zwłaszcza jak przeczytasz poniżej:

Ja do KDE napisałem sobie skrypcik, który kopiuje mi poszczególne meta-ebuildy do lokalnego portage, zmienia ich nazwę na kdecośtam-local-meta, uruchamia w edytorze, w którym mogę wyrzucić to czego nie używam, zapisuje zmiany, uruchamia ebuild digest (i tak automat dla wszystkich). Przygotowanie meta-ebuildów do kde-3.5_beta1 zajęło mi ok. 10 minut (odinstalowywanie mniej więcej tyle samo, ale to już inna historia  :Wink: )

A uaktualnienia: poszczególne ebuildy z kde (np. kdelibs, kicker, itp) mi się uaktualniają po każdej synchronizacji portage. Jedynie przejście na kolejną dużą wersję wymaga przebudowania lokalnych meta-ebuildów. Ale duża wersja wychodzi raz na kilka miesięcy. Skoro mam czas na pisanie na tym forum, to znajdę też czas na stworzenie nowych meta-ebuildów  :Very Happy: 

A co nowego może być w meta pakietach aby wymagały uaktualniania poza wydaniem kolejnej dużej wersji? Nie ma nic.

----------

## argasek

Moje 3 grosze:

- za jeśli chodzi o możliwość szybkiej rekompilacji, łatwość zawężenia problematycznego pakietu itp.

- przeciw, niestety, cała reszta. Za dużo tych zależności, obawiam się poza tym, że zainstalowanie zestawu minimalnego spowoduje, że pewne aplikacje przestaną działać, kończąc wynik jakimś tajemniczym błędem :], a ja będę zastanawiał się 1/2 dnia, co by tu jeszcze doinstalować. W każdym razie problemów tego typu upatruję u posiadaczy ~, tak jak ja.

----------

## psycepa

moim skromnym zdaniem jesli kazdy ebuild bylby dobrze udokumentowany, opisany jak co poco dlaczego i z kim, nie bylo by problemu, powiem wiecej, uwazam ze mogly by powstac rozne wersje takiego powiedzmy "meta-ebuildu", wrzucone np do portage-r czy cos, i albo: 

a) mergujesz Wszystko

b) mergujesz minimal

c) mergujesz te pakiety ktore TY chcesz

d) mergujesz zestaw ktory juz ktos wypracowal i jest on na przyklad uznany i powazany w spolecznosci  :Smile: 

e) dajesz se siana i wracasz na XP   :Twisted Evil:  (dla twardzieli  :Smile:  )

pozdrawiam

----------

## ketjow

 *rasheed wrote:*   

> Sam pomysł dobry ale wydaje mi się, że za dużo tych ebuildów. Po redukcji do ~30 byłoby o wiele lepiej.

 otoz to, popieram. Bez przesady, panowie  :Wink: 

----------

## 13Homer

 *ketjow wrote:*   

>  *rasheed wrote:*   Sam pomysł dobry ale wydaje mi się, że za dużo tych ebuildów. Po redukcji do ~30 byłoby o wiele lepiej. otoz to, popieram. Bez przesady, panowie ;)

 

Ja tutaj nie widzę przesady. Jedyne, co mi przyszło do głowy to to, że wersja minumum powinna być w jednym pakiecie (może tak jest, tylko tego nie "widzę"), a reszta doinstalowywana w razie potrzeby (i może być nawet w 1000 pakietów, bo co za róznica?).

Jakoś nikt nie podnosi argumentu, że w portage jest tego za dużo i może dałoby się to jakoś pogrupować w metapakiety.

 *argasek wrote:*   

> obawiam się poza tym, że zainstalowanie zestawu minimalnego spowoduje, że pewne aplikacje przestaną działać, kończąc wynik jakimś tajemniczym błędem :], a ja będę zastanawiał się 1/2 dnia, co by tu jeszcze doinstalować

 

To tak jakby odinstalować z KDE Arts i później robić wielkie oczy, że nie ma dziwięku. Każdy pakiet ma przecież zbiór zależności, na tym opiera się filozofia drzewa portage. Jeśli coś nie działa, to nie są spełnione zależności: "skopany" ebuild albo odinstalowany wymagany pakiet.

----------

## n3rd

 *13Homer wrote:*   

> 
> 
> To tak jakby odinstalować z KDE Arts i później robić wielkie oczy, że nie ma dziwięku. Każdy pakiet ma przecież zbiór zależności, na tym opiera się filozofia drzewa portage. Jeśli coś nie działa, to nie są spełnione zależności: "skopany" ebuild albo odinstalowany wymagany pakiet.

 

Tak się składa, że po odinstalowaniu KDE Arts cały czas masz dźwięk.. wystarczy tylko poprzestawiać w opcjach programu opcję wyjścia dźwięku..  :Wink:  Wcale nie mam KDE Arts.. ani esound.. Na co dzień nie stosuję tego typu serwerów dźwięku.. bo po co?  :Wink:  Jedyny serwer dźwięku jaki mam w systemie to jack i odpalam go tylko w razie potrzeby.. np. dla ardoura czy jamina.

Wcale więc nie jest powiedziane, że bez tej czy innej paczki zaraz wszystko przestaje działać  :Wink: 

pozdr

daniel

----------

## argasek

 *13Homer wrote:*   

> To tak jakby odinstalować z KDE Arts i później robić wielkie oczy, że nie ma dziwięku. Każdy pakiet ma przecież zbiór zależności, na tym opiera się filozofia drzewa portage. Jeśli coś nie działa, to nie są spełnione zależności: "skopany" ebuild albo odinstalowany wymagany pakiet.

 

Nie bardzo mnie zrozumiałeś. Mam na myśli to, że (nawet w obecnej chwili) istnieją w portage pakiety, których funkcjonalność zależy (może niekoniecznie w sposób krytyczny, ale na pewno w sposób istotny) od zainstalowanych innych pakietów, które bynajmniej nie są ich zależnościami (ani w sensie RDEPEND ani IUSE).

 *13Homer wrote:*   

> (i może być nawet w 1000 pakietów, bo co za róznica?).

 

W długości trwania poleceń emerge sync, emerge -s i esync.

ps. KDE mam bez artsa, dźwięk działa świetnie. :>

----------

## 13Homer

 *argasek wrote:*   

> Nie bardzo mnie zrozumiałeś. Mam na myśli to, że (nawet w obecnej chwili) istnieją w portage pakiety, których funkcjonalność zależy (może niekoniecznie w sposób krytyczny, ale na pewno w sposób istotny) od zainstalowanych innych pakietów, które bynajmniej nie są ich zależnościami (ani w sensie RDEPEND ani IUSE).

 

Nie rozumiem,chodzi o coś takiego jak w Windowsach, że klikasz 2 razy na DOCa i Ci się otwiera Word? :)

Nie spotkałem się z czymś takim, ale pakietów zbyt dużo zainstalowanych nie mam.

 *Quote:*   

> W długości trwania poleceń emerge sync, emerge -s i esync.

 

Mnie się nigdy nie udało zrobić emerge sync, więc się nie wypowiadam (korzystam z emerge-websync czy jakoś tak - nawet nie patrzę co mi autocomlete dopisuje :). Poza tym używam eix, więc wyszukiwanie mam dużo szybsze niż emerge -s. Raz dziennie czy rzadziej synchronizacje dłuższe o pół minuty nie robią mi różnicy (a ostatnio w pakietach, które mam zainstalowane nie zmienia się prawie nic).

 *Quote:*   

> KDE mam bez artsa, dźwięk działa świetnie. :>

 

To była tylko ilustracja (czy też jak widać raczej próba ilustracji). Nie używam KDE, ale sądziłem, że Arts to podstawowy serwer dźwięku i bez tego KDE jest niemy.

----------

## Raku

 *13Homer wrote:*   

>  Nie używam KDE, ale sądziłem, że Arts to podstawowy serwer dźwięku i bez tego KDE jest niemy.

 

bo jest niemy. Wszystkim, którzy zaprotestują od razu tłumaczę: spróbujcie sobie bez arts uruchomić dźwięki systemowe. Temu kto mi pokaże jak to zrobić stawiam flaszkę.

----------

## n3rd

 *raku wrote:*   

>  *13Homer wrote:*    Nie używam KDE, ale sądziłem, że Arts to podstawowy serwer dźwięku i bez tego KDE jest niemy. 
> 
> bo jest niemy. Wszystkim, którzy zaprotestują od razu tłumaczę: spróbujcie sobie bez arts uruchomić dźwięki systemowe. Temu kto mi pokaże jak to zrobić stawiam flaszkę.

 

Podobnie jak 13Homer, też nie stosuję KDE... a co do dźwięków systemowych, to myślę, ze jak ktoś by się uparł, to pozmieniałby co trzeba w kodzie i obszedłby tego artsa   :Cool:  Tylko chyba szkoda zachodu na jedną flaszkę   :Laughing: 

----------

## arsen

tak uogólniając, nie można twierdzić że nawet 1000 pakietów to nie jest złe i twierdzić co to za różnica, robi się wtedy burdel w systemie, jeśli same ebuildy do serwera X zajmą 1/3 rzeczywistch wszystkich ebuildów w systemie to coś jest nie tak, dla mnie to porządek nie jest, patrząć na wyniki naszej ankiety sporo osób myśli podobnie, gentoo powinno dawać jakiś wybór zadowalajając obie strony.

----------

## n3rd

@arsen

Treściwe podsumowanie   :Cool: 

----------

## psycepa

co juz wczesniej zaproponowalem   :Twisted Evil: 

----------

## qermit

mam takie 2 pytania:

ile miejsca zajęły by informacje o zainstalowanych pakietach xorg w /var/db/

ile było by dodatkowo tych plików?

----------

## argasek

 *13Homer wrote:*   

>  *argasek wrote:*   Nie bardzo mnie zrozumiałeś. Mam na myśli to, że (nawet w obecnej chwili) istnieją w portage pakiety, których funkcjonalność zależy (może niekoniecznie w sposób krytyczny, ale na pewno w sposób istotny) od zainstalowanych innych pakietów, które bynajmniej nie są ich zależnościami (ani w sensie RDEPEND ani IUSE). 
> 
> Nie rozumiem,chodzi o coś takiego jak w Windowsach, że klikasz 2 razy na DOCa i Ci się otwiera Word? 
> 
> 

 

Mam prośbę, ale taką szczerą, jak facet do faceta, od serca.

NIE RÓB ZE MNIE NA FORUM PUBLICZNYM _DEBILA_.

(Dziękuję).

A teraz, uspokajając, się, odpowiem: nie, chodzi o bugi typu ten: 106892

----------

## 13Homer

 *arsen wrote:*   

> tak uogólniając, nie można twierdzić że nawet 1000 pakietów to nie jest złe i twierdzić co to za różnica

 

Liczba była "z sufitu" i mi naprawdę nie robi różnicy ile ich będzie. Ważniejsze jest dla mnie to, żebym mógł sobie to elastycznie konfigurować.

Chodzi mi też o to, że nie widzę sensu na siłę minimalizować liczby pakietów (np. poprzez metodę pakowania wszystkich pakietów odpowiedzialnych za jakieśtam abstrakcyjne funkcjonalności wejścia do x11-input [to tylko ilustracja]).

 *Quote:*   

> robi się wtedy burdel w systemie

 

"Ordnung must sein". Z tym się zgadzam. Tylko, że różne osoby różnie oceniają co jest "porządkiem", a co "burdelem".

 *Quote:*   

> jeśli same ebuildy do serwera X zajmą 1/3 rzeczywistch wszystkich ebuildów w systemie to coś jest nie tak

 

A niby dlaczego? Lepszym wyjściem byłoby dodanie 1000 flag, żeby każdy mógł sobie to skonfigurować "aż do ostatniego bitu"? (nie jestem pewien czy włączenie jakiejś flagi może oznaczać niekompilowanie jakiegoś fragmentu źródeł, sądzę, że tak można zrobić).

Popatrz na XMMS: jest program (pakiet) "głowny" i trochę dodatkowych wtyczek. Jeśli tych wtyczek będzie 1000 to powiesz, że coś jest nie tak? Wydaje mi się, że sytuacja z xorg jest analogiczna.

 *Quote:*   

> dla mnie to porządek nie jest, patrząć na wyniki naszej ankiety sporo osób myśli podobnie, gentoo powinno dawać jakiś wybór zadowalajając obie strony.

 

Mówiąc ironicznie: proponuję kompromis: niech będzie 20 pakietów związanych z xorg, pozostałe 980 to będą metapakiety grupujące te 10 w róznych konfiguracjach, żeby użytkownicy mieli wybór.

----------

## 13Homer

 *argasek wrote:*   

> Mam prośbę, ale taką szczerą, jak facet do faceta, od serca.

 

Kiedyś gość (pracownik firmy, dla której coś robiłem) zwrócił się do mnie per "misiu". Popełnił błąd.

 *Quote:*   

> NIE RÓB ZE MNIE NA FORUM PUBLICZNYM _DEBILA_.

 

Dalszy ciąg mojej wypowiedzi: *Quote:*   

> Nie spotkałem się z czymś takim, ale pakietów zbyt dużo zainstalowanych nie mam. 

 

Odnosił się do Twojej wypowiedzi o zależnościach nie w sensie RDEPEND i IUSE, a nie do mojego żartu o Wordzie. Z kontekstu rzeczywiście nie dało sie tego nijak wywnioskować. Mój błąd, przepraszam.

 *Quote:*   

> A teraz, uspokajając, się, odpowiem: nie, chodzi o bugi typu ten: 106892

 

A to już jest przecież oczywisty bug (zmuszanie użytkownika do korzystania z czegoś, czego nie musi chcieć - czy też odwrotnie, wsio radno).

Nie widzę związku z jakimiś "ukrytymi zależnościami".

----------

## ketjow

 *13Homer wrote:*   

>  *argasek wrote:*   Mam prośbę, ale taką szczerą, jak facet do faceta, od serca. 
> 
> Kiedyś gość (pracownik firmy, dla której coś robiłem) zwrócił się do mnie per "misiu". Popełnił błąd.
> 
> 

 

Eh, ależ to melodramatyczne  :Razz: 

 :Twisted Evil: 

----------

