linux/config.h (unstable)

Jeremy Utley jeremy at
Sun Jun 6 00:32:24 PDT 2004

DJ Lucas wrote:

> Aite time for unstable?  A few weeks ago I had suggested a change to 
> the linux-libc-headers.  Specifically 'linux/config.h'.  I wanted to 
> get rid of the error generated when it is used.  There is good and bad 
> to this suggestion.  The problem is that packages should not be using 
> this header at all, but quite a few do anyway.  As the headers are 
> now, it generates an error message telling you not to include that 
> file.  While I think the real problem should be fixed in BLFS packages 
> that suffer from this brokeness, what about other packages not 
> included in BLFS?  A quick assumption (I know that is probably bad):  
> A fair amount of users are not programmers, and may not feel 
> comfortable editing a source file, or even know how to remove an 
> include.  I'd like to see this done after the headers are installed:
> cat > /usr/include/linux/config.h << "EOF"
> #ifndef _LINUX_CONFIG_H
> #define _LINUX_CONFIG_H
> #endif
> The problem is that it doesen't help to track down the broken 
> packages, nor does it give the maintainers an incentive to fix their 
> code.  Should LFS do this for the sake of it's readers, or just leave 
> them to figure it out on their own?  My only real arguments are for 
> ease of use, but consistancy fits here as I had mentioned in the 
> previous thread:
> > we make changes in other packages for minor backwards
> > compatibility, take posix version for example. Why should
> > this one be any different?
> Any thoughts?
> -- DJ Lucas
I'm of mixed opinions on this one.  Personally, I think a note in the 
book is better, to the best of my knowledge there's only 3 packages 
known to use this broken include - XFree86, Xorg, and Xine-lib.  The 
thing we need to find out is, has anyone taken this upstream to them and 
found out how they will be handling this in future releases?  If it's 
going to be fixed in the future, I say don't change it, and temporarily 
patch the offending packages.  But if the changes aren't ever going to 
be made, then perhaps DJ's solution is the better option.

Just my .02

I'm especially interested in Ian's take on this, as a kernel hacker type 
guy :)


More information about the lfs-dev mailing list