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...
Attachment:
signature.asc
Description: This is a digitally signed message part
