On Fri, 2007-07-27 at 13:43 -0400, Bill Nottingham wrote:
Jeremy Katz (katzj(a)redhat.com) said:
> > Actually, the more I think about it... is this really appropriate for all
> > upstream m-i-t users? Especially since it will probably be a never-ending
> > task of adjusting the symbol list to find the proper modules.
> When davej and I talked about it, we decided "probably not". And
> maintaining two lists of it is insane, so we decided putting the info in
> the kernel package wasn't a bad thing. Especially as that's where
> you'll know when you need to change it
But that means any time the symbol list changes, you'll need to rebuild
the kernel ; you effectively have a DOA kernel for the installer.
Lots of things can lead to a DOA kernel. It's not like the symbols
we're talking about here are things that change frequently. And it's
more likely to actually get *done* if it's in the same place that the
changes occur. Otherwise, no one's going to tell us that the symbol
list changed until someone happens and we're in exactly the same place
we are now. There is zero reason why this information should be
maintained within the installer,etc
it's done at runtime, you can handle whatever kernel you happen to get,
even if it's not one of ours.
There are plenty of constraints we have around kernel configuration.
Asking for a file to be shipped with the kernel which tells us a little
bit about what modules were configured just doesn't seem that out there