On Mon, 2004-06-28 at 10:22, Axel Thimm wrote: > > > 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... exactly, but it can only do that AFTER building the kernel. So the plan of one grand unified kernel-devel for all architectures isn't a feasible one. > > > > 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)? that's unrelated entirely. > b) splitting kernel headers for the kernel? I don't see splitting as a goal. Providing separate we can talk about, but splitting I don't see as option; the current mechanism has too many advantages for that. > > > 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 your kernel-axel-devel can't Provides: kernel-devel = <foo> ? > 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. I disagree with that conclusion. It's one simple script as the openafs rpms and the other method posted here both have shown.
Attachment:
signature.asc
Description: This is a digitally signed message part
