On Fri, 25 Jun 2004 17:23:10 +0200, Arjan van de Ven <arjanv@xxxxxxxxxx> wrote: > > well.... the problem here is that a significant number of x86 class > machines don't boot the smp kernel.... to arjan: I'm not expecting a perfect solution, and considering the other constraints associated with the problem at hand i think in the end having to install smp cruft on a uniprocessor machine, is a rather small price to pay for gains in other areas, like distribution bloat. And I'm not really sure that throwing in the crap thats needed to build modules into the binary kernel package is any worse than throwing the smp kernel cruft in with the uniprocessor cruft. I certaintly know a lot of uni and smp machines that never need to build a kernel module, so the logic holds equally poorly on both counts. I'm not sure i see any gains at all with moving the smp kernel into the kernel package just like I'm not sure there is any gain moving the needed bits to build modules into the binary kernel module. I think having a kernel-devel subpackage makes a lot of sense, especially if the goal is to treat the kernel package similarly to other packages. I dont need to compile modules on most of the computers I admin, so I dont need the associated bits. to everyone else: Can we please continue to focus discussion on identifying and proposing solutions for real problems associated with dropping kernel-sourcecode. So far I only see one real problem ( potentially pre-existing problem that people have grown accustom to hacking around a certain way). And that problem is simply, 'What is the best way to build add-on modules for multiple arches of the same binary kernel version with the goal of providing repository access for other people to those kernel modules packages` This is pretty much the only real issue so far discussed. And I personally would like to see more discussion aimed at flushing out the technical limitations and benefits of creating a kernel-devel package similar to the -devel packages for other pieces of core. Can everything thats needed to build modules be placed in a kernel-devel package? Including all the supported kernel arches? Or would there be a need to created per arch kernel-devel packages? Are there any show-stopping tehcnical limitations to using kernel-devel package? Does the concept of a kernel-devel package play well with dkms? -jef
