On Wed, 15 Mar 2006, Roger Blake wrote:
Although the script might be a good *short term* plan I think an adequate
long term solution requires a complete evaluation of *each* header -
identifying what code to delete or include. From what I can see the majority
of these headers are NOT required by userspace. I have got the basic LFS
building with about 150 headers only. Possibly guess at another 150 for a
complete set. (figures for i386 only)
Personally, I think the fun and games will come in BLFS. Certainly I
think I've noticed Mariusz's "this time I'll include it for you" in my
logs quite often. Of course, as long as fedora are using their own
headers and packages build like that, I don't think many upstream
maintainers will be too concerned.
I think eventually we need to go through each header identifying *and
documenting* every piece of code to be included/removed. That really is the
only way, and obviously it is a pretty massive + longer-term task.
I suspect you are right, but at the moment the size of the task is
unknown - maybe it *will* mean reviewing every header for every release
(certainly, that seems to have been Mariusz's view, otherwise why would
he try to do each missing kernel release instead of going straight
towards 2.15 or 2.16 ?), or maybe there will be patterns we can use.
Remember, Mariusz's headers worked well enough for most of us, even in
CLFS - I know that at the moment they are *very* different from what the
script produces (I'm in the middle of trying to document the differences
for 2.6.12, it will be a long job), I'm hopeful that we can find an
acceptable solution - at least Jim doesn't only care about x86 ;)
And giving any script back to LKML will only encourage an inadequate
short-term fix to be propagated indefinitely.
Actually, trying to offer this back to lkml will probably generate an
almighty amount of heat. But, if the eventual result is a script that
only needs to be run (modulo problems introduced in the current
development kernel), we might have a chance. Our big problem as a
community is that we don't have a good reputation on lkml.
But, what practical alternatives are there ? Stay on 2.6.12 headers
until they bit-rot ? Develop a script which seems to work well enough
for us, but is hidden away so that casual enquirers can't easily get to
it (and is therefore not properly reviewed by people who might have a
view on the details) ?
Ken
--
das eine Mal als Tragödie, das andere Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
