On Mon, Jun 28, 2004 at 10:10:41AM +0200, Arjan van de Ven wrote: > On Mon, Jun 28, 2004 at 09:15:49AM +0200, Axel Thimm wrote: > > On Sun, Jun 27, 2004 at 07:20:30PM +0200, Arjan van de Ven wrote: > > > 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? > > the generated .mod.c and .mod.o files (for example jbd.mod.c and jbd.mod.o > for jbd.ko module) would be missing for example. OK, the kernel %install script could detect whether modversions have been selected in .config and package these files, too, then. Will be quite a bloat, but if there is no other way... > > packages on par with the kernel[-smp|-<other flavour>] packages, and > > have the latter have a symlinked /build/ to the former. > > I do not want /build/ to become a symlink again. How will you solve the issues with a) same uname -r for different kernels (different archs)? b) splitting kernel headers for the kernel? For a) you could start adding archs to EXTRAVERSION, for b) you could only skip the build folder/symlink altogether, or have kernel-headers/devel install into there. Given the possible bloat these would uneccessarily occupy needed space on /. > > 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. > > no it's not harder, they just provide their add-on kernel-devel package, so > your kernel series could have a kernel-axel-devel rpm ... No, it is ;) 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 --define 'kernelsrcdir /a/b/c' for which path to chose for building kernel modules against. Having kernel module specfile for each kernel series defeats the purpose of specfile invariance across kernels. 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. -- Axel.Thimm at ATrpms.net
Attachment:
pgp2JYA5dY5Ri.pgp
Description: PGP signature
