SPECS: glibc-kernheaders.spec (NEW)

[Andrzej Krzysztofowicz]

> On Thu, May 29, 2003 at 23:14:45 +0200, Andrzej Krzysztofowicz wrote:
> 
> > > Ale chyba nie pisaliście, czy kiedykolwiek taki problem się ujawnił?
> > 
> > Nie pisalismy. Ujawnil sie. Nie sledzilem jak zostal rozwiazany (wlasne
> > naglowki w pakiecie, czy Linus jednal raczyl przyjac patch na zrodla jadra).
> > W kazdym razie bylo odsylanie na /dev/drzewo.
> > A problem dotyczyl nazwy zmiennej (lub pola struktury) identycznej ze slowem
> > kluczowym C++.
> 
> O ile się nie mylę to odesłanie nie wynikało z posiadania przez kogoś
> nagłówków kernela w userspace (bo nagłówków userspace nie ma), a tego,
> że _autor programu_ _użył_ takiego nagłówka zamiast własnej struktury?

Dokladnie. Ale ZTCP, potrzebna mu byla lista ioctl-i, ktora z kernela na
kernel lubi sie zmieniac.

> > > Tak. Do 2.4.x prawidłowe (z dokładnością do tamtego potencjalnego), na
> > > skutek braku odpowiednich nagłówków userspace (archiwa lkml).
> > 
> > Nie do konca. Wynik budowania pakietu nie powinien zalezec od srodowiska
> > budowania.
> 
> IMVHO mylisz się. Już we wczesnym Nest można było zobaczyć, jak
> rozjechały się gdk-pixbuf i imlib, ponieważ zostały zbudowane w
> otoczeniu libpng z innym SONAME. Jedynym lekarstwem na takie coś jest
> równoczesna kompilacja w tym samym środowisku. Dlatego glibce muszą być

Albo odpowiednie BR/BC,

> dostarczane z tymi nagłówkami, które były używane do ich kompilowania.
> 
[...]
> Bez zbudowania kernela 2.4.x się nie obejdzie (chyba że ręcznie wskaże
> się jego nagłówki). A później prosta droga, gdyż ./configure glibcy ma:

Wlasnie. Chodzilo o zbudowanie samego pakietu z naglowkami. Poza
kernel.spec.

> > To nalezy cofnac. Ale to co bylo na head, nie jest calkiem OK.
> 
> Jak już pisałem: my jako 'tylko pakowacze' nie mamy na to wpływu, możemy
> tylko biernie czekać, aż odpowiednie nagłówki zostaną stworzone. Chyba
> że przejdziemy na poziom 'my developerzy środowiska okołokernelowego'...
> Najlepszym dowodem jest wyżej zacytowana opcja glibcy - pojawienie się
> tam informacji, że w RH są lepsze (właściwe) nagłowki do userspace,
> będzie oznaczało moment, w którym należy się przełączyć.

Wydaje mi sie, ze w paru miejscach widzialem bledy (wycofane wyrownywanie
struktur), na pewno nie wspieraja crypto i wielu specyficznych dla PLD
zmian, ale wydaje mi sie, ze moga stanowic dobry punkt zaczepienia.
Bo w wiekszosci to co zostalo tam zrobione zostalo IMO zrobione _dobrze_.

> > > odpowiednich nagłowków nie dorobił (o czymś może nie wiem!?).
> > 
> > Mialem ochote sie za to wziac.
> 
> Dobrze rozumiem, że chciałeś opracowywać nagłówki userspace?

Dobrze rozumiesz.

> > Ale obecna sytuacja zniechecila mnie
> > dostatecznie do robienia _jakichkolwiek_ commitow do _jakiegokolwiek_
> > repozytorium.
> 
> Jeśli na poprzedni akapit odpowiadasz twierdząco, to może powinieneś
> nawiązać współpracę z ludźmi, którzy już nad tym pracują? Wykonywanie
> takiej rzeczy tylko dla PLD byłoby zapewne dublowaniem czyjejś pracy.
> No i tam miałbyś środowisko niezależne od aktualnych wydarzeń w PLD.

Niekoniecznie. Sa zmiany specyficzne dla PLD. I o nie glownie mi chodzilo.
W RH wysla mnie na /dev/drzewo. I beda mieli racje.

> > Przez _plynne_ rozumiem, ze np. poldkiem.
> 
> :( Szkoda. Bo już widziałem deklarację, że KDE nie przejdzie.

KDE mnie specjalnie nie interesuje.

> Ile miałbyś maszyn do upgrade'u? Bo jest to relatywnie łatwe.

kilkanascie - 20+

-- 
=======================================================================
  Andrzej M. Krzysztofowicz               ankry w mif.pg.gda.pl
  phone (48)(58) 347 14 61
Faculty of Applied Phys. & Math.,   Gdansk University of Technology