diff Ac Th (Re: SPECS: dbus.spec - next step, relese 4.2, java enabled, rebuild w/...)

[Mariusz Mazur]

On poniedziałek 16 maj 2005 00:34, Jakub Bogusz wrote:
> Dziwi mnie trochę kolejność.
> Czy podbijanie releasów w starych wersjach pakietów jest takim
> pasjonującym zajęciem? Ani to Ac, ani coś nowego - na razie wychodzi
> w większości takie Ac przekompilowane gcc 4.
> A można by przygotować nowe mono, dbus+hal+... itp.

Releasy są podbijane, jak trzeba coś poprawić (th ma tagowanie jak ac). Chyba, 
że adamg się zapędził.

> > Ibooka z pld masz jako desktop. Sparca nie.
>
> Zależy jakiego (jako desktop, nie *book; fakt, że współczesnym x86* nie
> dorównają).
> Maszyna aktualnie znana jako builder ac-alpha swego czasu służyła także
> jako desktop ;) (zanim poszła do szafy).
> Zresztą "serwer" może oznaczać także serwer aplikacji dla X-terminali.

No właśnie. Poszła do szafy. A jak ktoś będzie stawiał serwer aplikacji dla 
xterminali, to na pewno na jakiejś starej alphie, czy sparcu na które pewnie 
nie mamy nawet openoffica.

> > Na ppc masz nptla. Na sparca nie.
>
> Na alphę mam. Na sparca IIRC na HEAD już też (po tym, jak davem chciał
> dodać jakieś poprawki do linuxthreads i usłyszał, że ten kod nie będzie
> miał więcej wydań po 2.3.x).

Sparc miał nie mieć odpowiednich opcodów procesora przecież?
A alpha jest martwa. Kaput.

> Ad ppc: jakieś nadzieje na obsługę altiveca w Th?
> Builder jest ten sam co ac-ppc, dopóki tam jest zwalone jądro, to w obu
> liniach altivec leży i kwiczy.

Nie wiem, gausus zmienił jajko, ale co jest w tym nowym, to nie mam pojęcia 
(wiem, że jakiś oops został poprawiony).

> Zły wniosek.
> Jeśli w ogóle tylko nieliczne rzeczy będą szły na te buildery, to nawet
> nie będzie wiadomo, co sprawia problemy (większość się sprowadza do "we
> type rpmbuild...").
> Utrzymywanie "starych" architektur !x86 zwiększa też trochę przenośność na
> nowsze architektury (część poprawek pod kątem alphy ułatwiła port x86_64
> i, niedoszły niestety, ia64).
>
> Jeśli już koniecznie część architektur traktować inaczej - to budować
> wszystko (w ramach istniejących zależności i EA), jeśli coś się wywali -
> można nie wstrzymywać "normalnych".

Możliwych rozwiązań jest sporo. Osobiście uważam, że jeśli na te dwie 
architektury nie będzie szło wszystko to, co idzie na resztę builderów (w 
ramach numeromanii), to wyjdzie im tylko na zdrowie biorąc pod uwagę 
zdecydowanie słabszy upstreamowy support dla tychże arch. Imho osobne 
zarządzanie powinno działać sprawnie, bo jeśli chodzi o obecne zastosowania 
maszyn sparcowym i alphowych, to tam jest bardzo ograniczona ilość paczek w 
użyciu w porównaniu z resztą. Już nie wspominając o tym, że jeśli wreszcie 
będzie szybsze ppc, to próba pełnej synchronizacji zleceń pewnie zabije 
sparca i alphę.

Acz może jestem w błędzie. Kto i do czego używa obecnie maszyn sparcowych i 
alphowych?
(zastanawiam się nad możliwością automatycznego wysyłania na alphę i sparca 
zleceń na pakiety, które zostały przeniesione z test do main; zapewniłoby to 
synchronizację i jednocześnie byłoby niewidzialne dla niezainteresowanych 
deweloperów)

-- 
Każdy człowiek, który naprawdę żyje, nie ma charakteru, nie może go mieć.
Charakter jest zawsze martwy, otacza cię zgniła struktura przeniesiona z 
przeszłości. Jeżeli działasz zgodnie z charakterem wtedy nie działasz w ogóle
- jedynie mechanicznie reagujesz.                 { Osho }