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

[Arjan van de Ven]

On Mon, 2004-06-28 at 11:05, Axel Thimm wrote:
> o 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. 
> 
> So where will you put kernel headers for different arches, if you
> don't redesign this part? You either have to change uname -r or blow
> away the concept of non-symlinked /build/. I don't think that is
> unrelated, at all.

actually it 100% is. kernel-devel, if it ever comes to a reasonable
thing, will be in *addition* to what is there right now not as
replacement.

> 
> > > 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.
> 
> What advantages? That you need to install a kernel only for building
> kernel modules for it? And that this kernel may even conflict with the
> running one?
> 
> Split the headers off the kernel rpms, you will be doing yourself,
> users and packagers a great favour. There are no advantages in either
> bundling all header files together, nor in bundling kernel and kernel
> header files.

no splitting this off will hurt users. Maybe not packers but users it
does.

> > > 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. 
> 
> And you have read the comments on that.

yes and nothing really bad has come up.


> Please do trust the people that have been doing the packaging of
> several kernel module rpms for some time now. We have learned to cope
> with the shortcomings of the current kernel-source(code) methods, and
> since we now have the opportunity to do it right, we should do so.

I'm sorry but I have a really hard time taking packaging advice from
anyone who uses the current kernel-sourcecode method to build module
rpms.

> Just check a few kernel module rpms yourself to see the real problems
> in the dirt and not on the blueprints ;)

I've looked at some and I have yet to find a single one that is packaged
remotely correctly. (if that is at all possible, something I'm not
entirely convinced of)


> The demand profile is
> o kernel module rpm should be agnostic of location of kernel
>   headers/source. This is passed with "--define"s to the src.rpm.

this basically makes the point moot of where the kernel headers come
from. If you have to pass the location in the name of the exact
requires: is utterly irrelevant surely.

> o They should be independent of RH, ATrpms, other 3rd party repos,
>   custom kernel rpms, e.g. one specfile/src.rpm for all. The choice is
>   driven by the --define above

... and the --define can't give the exact package to require for the
headers? I don't believe that.

> o header files/source may not overlap for different arch/flavour
>   combination.

I think you mean "it must be possible to get all headers for all
archs/flavors installed in parallel somehow". That is a quite less
restrictive requirement.

Anyway I thank you for this list of requirements, as far as I can see
there's nothing in there that voids or blocks the kernel-devel mechanism
I proposed, in fact it strengthens it...
-------------- 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/e1b49333/attachment.sig>