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