The issue (to me at least) would be "do I know before I start what functionality is provided by the base kernel and what is provided by third party modules.?" My nightmare scenario goes like this.
 
1)  I install fedora feature X works due to non-upstream patch.
2)  Build custom kernel.  feature X no longer works.
 
Using Nvidia as an example...(I realize that they will nver be included in the kernel).
 
If I see build a custom kernel, I know I will need to rebuild the nvidia drivers.  If these drivers were in the kernel rpm,  I might carelessly assume that my video card is handled by upstream and be in for a nasty shock. 
 
In the case of multiple packages I know what will need to be redone.  If the module is in the kernel RPM due to a patch,etc; I would have a much harder time determining what to rebuild. 
 
My vote would be for:  kernel rpm == upstream (kernel.org) as much as possible with only rare exceptions (devicescape wireless stack for example).
 
Mark Bidewell

 
On 8/3/07, Jesse Keating <jkeating@redhat.com> wrote:
On Fri, 3 Aug 2007 16:31:06 -0400
"Mark Bidewell" < mark.bidewell@alumni.clemson.edu> wrote:

> One thing that concerns me (or I am not clear on what is being
> proposed) is that if out-of-tree drivers are merged with the kernel
> package, we will have a distro that works with the stock kernel but
> drop in a custom kernel and suddenly everything breaks.

How is that different from today?  Unless you build those out of tree
kmod packages against your custom kernel, they'll go boom.

But if they're in the kernel package, and you customize your kernel
based on that package, you'll get those mods you want for free.

--
Jesse Keating
Fedora -- All my bits are free, are yours?

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list