No more kernel-source(code) ??? (was: rawhide report: 20040623 changes)

[Arjan van de Ven]

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. 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040628/3e0c5935/attachment.sig>