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

[Axel Thimm]

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
-------------- 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/20040628/01714b76/attachment.sig>