On Sun, Jun 27, 2004 at 07:20:30PM +0200, Arjan van de Ven wrote: > > > 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. > > well you first would need to show it's possible and future proof.... > > right now we put the info in /lib/modules/../build *after* building that > exact kernel, and there's a good reason for that: the kbuild system > assumes a fully built tree. Now in the rpm we cheat and effectively > remove the files we don't need. And *maybe* now that doesn't depend too > much on the build results, but if you enable modversions for example it > already does. In what way? What files would be missing? > And some of the kbuild proposals on lkml also go in the general > direction of not being able to get all the needed info without doing > a full build..... > > Having a separate kernel-devel src.rpm which is made *after* the build > takes all this mess away since it can just take the right headers from > the actual packages. Well, since you do have a full build at kernel package creation time the current procedure seems fine, only the final packaging needs to be changed, e.g. introduce kernel-headers/devel[-smp|-<other flavour>] packages on par with the kernel[-smp|-<other flavour>] packages, and have the latter have a symlinked /build/ to the former. Each kernel has its own kernel-devel/header, and yum/apt/up2date etc need to be tought to handle these new multiple packages just like "kernel" itself. You don't want to shove all headers in one rpm, as this will again make it harder to build custon kernels with their custom kernel-headers/devel packages. -- Axel.Thimm at ATrpms.net
Attachment:
pgpUD0Oj4c53M.pgp
Description: PGP signature
