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...