On Mon, Jun 28, 2004 at 10:32:53AM +0200, Arjan van de Ven wrote: > 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. So have a list of required files be created at the end of %build. And a GUT of kernel-devel is a bad idea, really! > > > > 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. 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. > > 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. > > > > 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> ? Recent (FC1 upwards) versions of rpm define versioned Provides as to be uniqified, so no, apt/yum/rpm and so on will chose to only have one of them installed (It has been filed as a bug and closed with consdiered as defined behaviour). It is also the intention to have a _uniform_ way of packaging kernels and kernel modules, and not having 3rd parties and users do kludgy stuff again, right? > > 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. 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. Just check a few kernel module rpms yourself to see the real problems in the dirt and not on the blueprints ;) 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. 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 o Allow for arbitrary flavours (up, smp, "custom", old flavours like bigmem, new flavours). flavour is also passed from outside. o header files/source may not overlap for different arch/flavour combination. -- Axel.Thimm at ATrpms.net
Attachment:
pgpi3sINzyJBI.pgp
Description: PGP signature
