SPECS: glibc-kernheaders.spec (NEW)

[Tomasz Pala]

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?

> > 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ć
dostarczane z tymi nagłówkami, które były używane do ich kompilowania.

INNĄ sprawą jest to, że glibce nie powinny być budowane na czystych
nagłówkach kernela, tylko na 'odpowiednio' zmodyfikowanych. Takich
jednak dziś nie ma (a przynajmniej taki stan zakładam, dopóki nie
zobaczę stanowiska ludzi od glibca, że te z RH nadają się do używania).

> Chodzilo o _unikniecie_ budowania kernela 2.4
[...]
> > Albo nie rozumiem, albo uderzasz w stronę problemu boostrap.
> > kernel-headers na 2.4.x masz, z tego robisz odpowiednie dla buildera
> > glibc-kernel-headers.
> 
> Uderzam w strone problemu bootstrap. Tzn. jak to zbudowac bazujac na Ra,
> nie korzystajac z pakietow NEST-a. Tylko przebudowujac ichnie zasoby na
> builderach.

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:

  --with-headers=PATH     location of system headers to use (for example
                          /usr/src/linux/include) [default=compiler
                          default]

[...]
> 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ć.

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

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

> Ja zamierzam przestac uzywac Ra, jak bedzie mozliwe _plynne_ przejscie z
> niego na pre-Ac. Albo przejde na RH/debian/cokolwiek i dam sobie spokoj z
> PLD.
> 
> Przez _plynne_ rozumiem, ze np. poldkiem.

:( Szkoda. Bo już widziałem deklarację, że KDE nie przejdzie.
Ile miałbyś maszyn do upgrade'u? Bo jest to relatywnie łatwe.

-- 
GoTaR <priv0.onet.pl->gotar>           USA sux
      http://mops.uci.agh.edu.pl/~gotar/
GEOS:.  http://informatica.agh.edu.pl/  .:LF&A