Hi, again, On Sun, Jul 04, 2004 at 01:13:59PM +0200, Thomas Vander Stichele wrote: > > The idea is to have kernel module src.rpms with > > > > Requires: kernel-devel >= 2.6.0 > > > > and have the external build-system provide the matching rpms and > > kernel modules against. > > The build system does not need to provide kernelsrcdir if the location > where the build files are stored has a decent name. It does, because you may have installed several kernel headers for different kernels, so you'd like to pass to the build process for which kernels to build kernel modules. New kernels get added and old ones removed, and the src.rpm & specfile is to be kept invariant over time (unless other changes require patching etc.) > The spec file already has all the info to distinguish what type and arch > to build for (up/smp and i586/i686), so just give sensible names to the > path and it's solved. How does the specfile know, whether I want to build up/smp and i586/i686 etc on my x86_64 smp build host that produces all kernel modules archs and flavours for all supported distros? You could use defaults, for the running kernel, or the installed kernel(s), of course, but in general you would need that information to be an external input to the build process. > > You also want to provide users with a uniform way to build their own > > kernels and kernel-headers/devel packages, so you don't have much > > choice than to do it per kernel and not bundled. > > Nope, already works, and they're bundled. Not sure I follow, my remark was wrt to a suggested mega-kernel-devel package containing kernel development bits for the N Red Hat kernel errata in one package, e.g. bundling the kernel headers for kernels 2.6.5-1.358 2.6.6-1.427 2.6.6-1.434 2.6.6-1.435 2.6.6-1.435.2.1 2.6.6-1.435.2.3 Each new kernel errata would require updating of this package, which may be fine for RH, but not for custom kernels that will be missing in the above package (e.g. a 2.6.7-bk9 kernel). (I assume you read bundled and associated kernel and kernel header bundling, which is also bad for other reasons ;) -- Axel.Thimm at ATrpms.net
Attachment:
pgphVZ4rvuymo.pgp
Description: PGP signature
