(Hi again)^squared,
On Sun, Jul 04, 2004 at 01:10:39PM +0200, Thomas Vander Stichele wrote:
> > 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.
>
> Why is this ? Don't really see why this would make it harder.
Hm, saw this too late, the answer is in my previous post.
In short:
o bundling of kernel and kernel headers is bad, because
- you run into file space clashes for different archs (currently you
cannot have the kernel headers for i586 and i686 installed at the
same time).
- you don't need the kernel (running or installed) for developing
against its headers
- you don't need the headers for running the kernel
o bundling of N different kernel-header packages in on mega-kernel-header
package is bad, because
- with each new kernel you need to add the kernel headers to this
mega package, instead of just creating another light-weigh per
kernel kernel-header package.
- non-vendor kernels, such as 3rd party kernels and custom kernels
cannot use this mega-package at all.
So all is solved if
o kernel building splits subpackages into kernel and kernel-headers
o kernel-headers are per arch and flavour and are installed under say
/usr/src/kernel-headers/`uname -r`.<arch>
o /lib/modules/`uname -r`/build (part of the kernel subpackage)
becomes a symlink to /usr/src/kernel-headers/`uname -r`.<arch>
Benefits:
o Users can install the kernel-header package matching their kernel and
create all modules they'd like either manually or from kernel
modules src.rpms
o ISVs/Packagers can install as many kernel-header rpms and build
kernel module rpms for the whole lot of them w/o
installing/deinstalling kernel-headers or even whole kernels.
o Vendors are happy they found a solution that work for all
Drawbacks:
o Users will have to install kernel-header-`uname -r` for building
kernel modules.
I think the benefits far outweigh the drawbacks.
--
Axel.Thimm at ATrpms.net
Attachment:
pgpoT6ilBuUeY.pgp
Description: PGP signature
