Nowe zasoby na ftp://ftp.pld.org.pl/

Tomasz Kłoczko kloczek w rudy.mif.pg.gda.pl
Czw, 27 Lip 2000, 19:45:58 CEST


Zapewmne już kilka osóbe zauważyło, że na ftp.pld.org.pl są już nowe
zasoby które dotąd były dostępne tylko na mer.zie.pg.gda.pl .. ano musiało
prędzej czy później do tego dojść :)

Zmian w porówniu do tego co było poprzednio jest bardzo dużo. Głównie
aktualizacje choć nie tylko. W tej chwili nie ma jeszcze pogenrowanych iso
img ale jak tylko zostanie dograny mkisofs na sparc to i to sie pojawi.
Tak czy inaczej główna róznica polega na tym, że zasoby które są obecnie
sa o wiele lepiej zsynchronizowane (jeżeli porównać "płaszczyk" pakietów
między architekturami). Jest jeszcze kilka różnic ale to już kosmetyka
(diffy z różnicami są w katalogu /stat).

Tak czy inaczej od tego momentu ftp serwer na mer.zie.pg.gda.pl przestaje
być dostępny i komputer ten udostępniać będzie po rsync zasoby wyłącznie
dla wybranych jednostek w sieci które bedą mirrorami zasobów (jeżeli
takowy ktoś gdzieś będzie chciał utworzyć to wystarczy to tylko zgłosić).

Z innych wiadomości mogę dodać, że udało mi się przekompilować glibc
(2.1.91) na sparc czyli są szanse na pełny port na sparc PLD. Kilkanaście
minut temu zapuściłem także kompilację glibc na sparc64 i jak narazie się
kompiluje (o dziwo) czyli są szanse na to, że zacznie być w najbliższym
czasuie także robiony port sparc64 PLD co byłoby o tyle ciekawe, że w
zasadzie jeszcze nie ma dostępnej nigdzie dystrybucji która byłaby w pełni
przygotowana do sparc64 (dotąd tylko kernel na usparc chodzić w trybie
64bit ale całe user space było 32bit).

Z zmian jakie w najblizszym czasie trzeba będzie wykonać przejscie na
perla 5.6 co będzie się wiązać z pełną rekompilacją większości kawałków
perlowych. W zasadzie tutaj grunt juz jest przygotowany więc dużych
niespodzianek nie ma co się chyba spodziewać.

Przejście na glibc 2.1.91 raczej na razie będzie trenowane tylko
na sparc i na axp ale to tylko z koniecznosci bo 2.1.3 bez poważnego
łatania w zasadzie nie nadaje się do pracy. Po wytestowaniu tego jak to
sie zachowa na sparc (o ile dobrze pójdzie na sparc64) i opracowaniu
procedury upgradeu będzie można próbować IMHO zrobić to samo na ix86.
Główne zmiany w przypadku tego glibc sa takie, że zmieniły się SONAME
wszystkich libnss_* czyli znowu można się spodziewać kłopotów przy upgrade
rpm-a jakie już kiedyś doświadczaliśmy. Także kolejną ważną zmianą jest
to, że samego glibc wyleciały db1 i db2, które są dostępne osobno. Z tym
db* zaczyna się robić bałagan, bo część jeszcze chce db1, część od
dłuższego czasu dobrze pracuje z db2, a juz w kilku miejscach dochodzi do
wymuszeń na rzecz używania db3. Wydaje mi się, że możnaby popróbować
zrobić to tak żeby ograniczyć ilosć używanych db* do minimum (dwie wersje
to byłoby już lepie) choć nie wiem na ile będzie to możliwe i sensowne.

Jakieś pytania ?

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*



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