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
