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.