Zmiana supportu dla sparc i alpha w Th

Mariusz Mazur mmazur w kernel.pl
Śro, 16 Mar 2005, 18:05:13 CET


Temat w sumie powraca jak bumerang. Ale skoro nawet debian się do takich 
rzeczy przymierza (http://lwn.net/Articles/127515/) przy ich zasobach 
ludzkich, to coś w tym musi być. Prawda jest taka, że z naszego punktu 
widzenia alpha i sparc to architektury wymierające (jedno i drugie jak już 
się kupuje, to raczej razem z jakimś uniksem). Nie są specjalnie testowane i 
jest problem z reagowaniem na bugreporty. Przydałoby się coś z tym zrobić.

Wywalić kompletnie się nie da, bo jednak ludzie tego używają. Więc trzeba by 
to jakoś na boczny tor odłożyć. Do wyboru jest właściwie kilka dróg. 
Pierwsza, stosowana do tej pory, to "co to szkodzi, niech się buduje, jak się 
nie zbuduje, to najwyżej nie będzie". Teoretycznie brzmi dobrze, ale w 
praktyce jest okdr. Po pierwsze nowa automatyka nie pozwala zlikwidować 
supportu dla danej architektury w nowej wersji pakietu (znaczy było kde3 na 
alphą, kde4 się nie zbudowało na alphie, to nie pozwalamy przenieść). 
Oczywiście mogę zrobić tak, żeby w przypadku tych dwóch architektur takiej 
blokady nie było, ale wtedy ryzykujemy wywaleniem takich pierdółek jak glibc, 
gcc, czy binutilsy (a bo się akurat nie zbudowało, a blokady nie było).

W praktyce takich pakietów, których niezbudowanie na jakiejkolwiek arch 
blokuje możliwość przeniesienia pakietu, jest znacznie więcej i są one mocno 
upierdliwe. Bo ani to poprawić, ani zignorować, a przeszkadza. Najlepiej to 
widać na przykładzie kernela -- w alphie i sparcu to za dużej ilości zmian w 
kernelu nie ma, skutkiem czego często vanilla jajka nie działają i trzeba się 
trochę nakombinować, żeby mieć działający kernel. A jak ludzie chcą nowy 
driver, to nie będą pilnowali, czy to działa na sparcu, czy alphie (nawet nie 
mają zbytnio jak). Prawda jest taka, że wystarczyłoby tam trzymać jakieś 
2.6.5, byle by działało i czasami łatać jakimiś security fixami, acz i tego 
przeważnie nie trzeba, bo kto ma sploity na te architektury? :) 

A skoro wystarczy trzymać jakiś inny stary kernel, to często jest tak też z 
innymi pakietami. Na początek gcc3.4 zamiast 4.0 by zaoszczędziło pewnie w 
cholerę roboty. Do tego pewnych programów nigdy się na sparcu i alphie pewnie 
by nie używało. Można w sumie też pozbyć się nptla (na sparcu i tak nie 
działa), a jak już przy tym jesteśmy, to dodać support dla takiego okrojonego 
i386 (bo tu też nptla nie ma). 

Już nie wspominając o tym, jak miło było by się pozbyć tych dwóch 
najwolniejszych builderów i zmniejszyć przy okazji awaryjność całej 
infrastruktury (bo oddzielamy główne th od tego Th B).

Jak coś takiego robić, to teraz, także jak ktoś ma jakieś konkretne powody 
dlaczego nie zrobić geriatrycznej wersji pld (i chodzi mi o konkretne powody 
-- "lepiej mieć paczki, jak nie mieć" to tylko ignorowanie oczywistych 
problemów), to niech powie.


-- 
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 }




Więcej informacji o liście dyskusyjnej pld-devel-pl