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

Jeff Spaleta jspaleta at gmail.com
Sun Jun 27 16:51:07 UTC 2004


Toshio wrote:
> I see Arjan did understand it differently.  Thanks for the
> clarification, it makes more sense that way (kernel-devel is built from
> a separate, kernel-devel SRPM.).

I'm dense.... why exactly would it make sense to have a seperate
kernel-devel SRPM?
Does any other -devel package for a piece of core come from an a
seperate -devel SRPM?

Let's recap again.... the potential benefits so far stated for
dropping the kernel-sourcecode binary have been:
1) Reduced bloat in Core, to prevent shipping and mirring the
sourcecode when the srpm can be used to rebuild a custom kernel using
the packaging methodology of srpms
2) Treating the kernel packages just like all the other packages in Core.

The ONLY known problem with removing kernel-sourcecode, is dealing
with how to build extra modules for multiple arches for binary kernels
by just installing binary packages, something public and intranet
repositories need a clean solution for.  But there's never really been
a clean solution for this.

One potential solution to the problem of add-on module building
repository style which is in line wht the potential benefits as
stated, is reworking the kernel packaging to create a kernel-devel
package.  If we want to make the kernel package as similar to other
packages as possible, kernel-devel should be used to hold the bits
needed to compile add-on modules for the kernel, instead of the kernel
package itself.  But I see no reason for kernel-devel package to hold
information for ALL the previous released kernels as well. I just
don't see why thats needed. If kernel binaries across versions can be
installed in parallel the associated kernel-devel from different
kernel version should be parallel installable as well as a matter of
design.

The only problem with using a kernel-devel package is the same problem
the kernel binary suffers from right now, dealing with situations like
parallel installs of i586 and i686. The only potential solution to
this problem has been to have kernel-devel include build information
for ALL arches for the given kernel release. Several people have
brought this up, but I've seen very little to no discussion on the
potential downsides to piling in all the arches into one kernel-devel.


-jef





More information about the fedora-devel-list mailing list