No more kernel-source(code) ??? (was: rawhide report: 20040623 changes)

Jeff Spaleta jspaleta at gmail.com
Fri Jun 25 16:04:14 UTC 2004


On Fri, 25 Jun 2004 17:23:10 +0200, Arjan van de Ven <arjanv at redhat.com> 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





More information about the fedora-devel-list mailing list