On Fri, Feb 21, 2003 at 04:19:39AM +0100, Maciek Pasternacki wrote:
> Solar Designer <solar@private> writes:
>
> > However, there're also valid reasons to want to build applications or
> > especially kernel modules with newer kernel headers.
>
> For me, if someone needs to rebuild an app which needs more than
> distribution gives, he should know what he's doing.
True.
> > I personally prefer manual control over which kernel headers I use and
> > which kernel I run.
>
> I see it like this: in /usr/include/linux I have the very same headers
> that were used to build glibc. For most program I would need to
> compile it's enough. When I need to use newer kernel functionality,
> I just add e.g. -I/usr/src/linux-current-version and gcc happily takes
> the new headers.
So you have a solution which works well for you with our current
setup. ;-)
> > Yes, we currently have these symlinks, but
> > /usr/src/linux doesn't have to match the running kernel (although that
> > is often convenient).
>
> Keeping old, unused kernel sources (probably cut down just to
> include/) in /usr/src/linux looks like a kludge. Why not package
> these headers as a part of glibc (which they, de facto, are) and keep
> current kernel's source in /usr/src or in my home directory?
I'm not saying we won't do it. I am considering it since I've seen
Red Hat make a similar move (although the way they've done it is rather
ugly: they have a separate .tar.bz2 with Linux 2.4.2 kernel headers
in glibc-kernheaders SRPM).
Yes, it is possible that our glibc builds will package the kernel
headers they used, in a glibc-kernel-headers "binary" subpackage. Our
perl package already has something similar for *.ph's, although I am
unsure whether that is right (again, wouldn't it be better for some to
build the *.ph's whenever needed from the current kernel headers).
What I was saying is that such a setup, with /usr/include/{asm,linux}
being directories rather than symlinks, makes it less convenient for
some to build new stuff.
--
/sd
This archive was generated by hypermail 2.1.3 : Sun Jan 15 2006 - 13:43:18 PST