Split off kernel-header/devel package (was: No more kernel-source(code) ???)

[Axel Thimm]

On Sun, Jul 04, 2004 at 01:43:48PM +0200, Thomas Vander Stichele wrote:
> 
> > But that is exactly the point of discussion. A kernel-devel package
> > should be per kernel version, arch and flavour, not a
> > conglomerate. That way you both have less bloat and it is universal to
> > be extended to arbitrary kernel, e.g. ones in future errata, custom
> > kernels and so on.
> 
> You have said this over and over but not provided any explanation on why
> this is so.  "should be" is your personal opinion.

Thomas, I understand the thread is long and old by now, but this kind
of statements are completly moot and only to be considered as
heat-ups. I have given grounds to all the above in past and today's
posts. I'd like to ask you to check the thread again, as this is the
third (!) post from you having me presented as a hot-air mouthed
troll.

> "universal to be extended to arbitrary kernel": maybe you should give an
> example, because I really don't understand what you're trying to say
> here.

OK, check my recent nvidia-graphics drivers that have been build out
of the same src.rpm for the following 30 kernels:

2.4.20-35_39.rh7.3.at 20-35_39.rh7.3.atbigmem 20-35_39.rh7.3.atsmp
2.4.20-35_39.rh8.0.at 20-35_39.rh8.0.atbigmem 20-35_39.rh8.0.atsmp
2.4.20-35_39.rh9.at 20-35_39.rh9.atbigmem 20-35_39.rh9.atsmp 20-35.7
2.4.20-35.7bigmem 20-35.7smp 20-35.8 20-35.8bigmem 20-35.8smp 20-35.9
2.4.20-35.9bigmem 20-35.9smp 22-1.2197.nptl 22-1.2197.nptl_51.rhfc1.at
2.4.22-1.2197.nptl_51.rhfc1.atsmp 22-1.2197.nptlsmp
2.4.26-1.ll.rhfc1.ccrma 26-1.ll.rhfc1.ccrmasmp 2.6.6-1.427
2.4.2.6.6-1.427smp 2.6.6-1.435.2.3 2.6.6-1.435.2.3smp
2.4.2.6.7-1.456_4.rhfc2.at 2.6.7-1.456_4.rhfc2.atsmp

It includes vendor (RH) kernels, ATrpms kernels, and even PlanetCCRMA
kernels. These are all the common kernels packaged and deployed BTW.

All this using a non-packaged version of the kernel-headers per kernel
flavour/arch as descibed above. I'd call that "universal to be
extended to arbitrary kernels", wouldn't you? And I'd also say the
method has already proven in the field. There two dozen kernel module
rpms successfuly deployed at ATrpms.net in the above manner resulting
in several thousands (!!!) of binary kernel modules rpms.

So, yes, it's quite more than hot air ...

> I don't see how creating *four* rpms for four kernels as compared to
> *one* devel rpm for four kernels is extra maintenance.

Ehm, how will the user with his custom rpm be treated? Open the
conglomerated rpm and add his own kernel? No, that's far from
user-friendly. And the discussion of keeping things bundled is done in
favour of the user, right?

And don't forget, the suggestion of one kernel header package per
kernel/flavour/arch is producing those _automatically_ while building
the kernels themselves. There is nothing you need to _do_ to get them,
e.g. no extra maintenance, while adding a new kernel header to the
mega-kernel-header package is extra maintainance.

> People releasing their custom kernel in the wild should take up
> responsibility and provide the same mechanism as upstream does.

You mean each _user_ who wants to have his custom kernel packaged and
kernel modules build for it should become an rpm expert? Not really.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040704/9ebe37b4/attachment.sig>