[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: No more kernel-source(code) ??? (was: rawhide report: 20040623 changes)



Hi, again,

On Sun, Jul 04, 2004 at 01:13:59PM +0200, Thomas Vander Stichele wrote:
> > The idea is to have kernel module src.rpms with
> > 
> > Requires: kernel-devel >= 2.6.0
> > 
> > and have the external build-system provide the matching rpms and
> > kernel modules against.
> 
> The build system does not need to provide kernelsrcdir if the location
> where the build files are stored has a decent name.

It does, because you may have installed several kernel headers for
different kernels, so you'd like to pass to the build process for
which kernels to build kernel modules. New kernels get added and old
ones removed, and the src.rpm & specfile is to be kept invariant over
time (unless other changes require patching etc.)

> The spec file already has all the info to distinguish what type and arch
> to build for (up/smp and i586/i686), so just give sensible names to the
> path and it's solved.

How does the specfile know, whether I want to build up/smp and
i586/i686 etc on my x86_64 smp build host that produces all kernel
modules archs and flavours for all supported distros?

You could use defaults, for the running kernel, or the installed
kernel(s), of course, but in general you would need that information
to be an external input to the build process.

> > 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.
> 
> Nope, already works, and they're bundled.

Not sure I follow, my remark was wrt to a suggested mega-kernel-devel
package containing kernel development bits for the N Red Hat kernel
errata in one package, e.g. bundling the kernel headers for kernels

2.6.5-1.358
2.6.6-1.427
2.6.6-1.434
2.6.6-1.435
2.6.6-1.435.2.1
2.6.6-1.435.2.3

Each new kernel errata would require updating of this package, which
may be fine for RH, but not for custom kernels that will be missing in
the above package (e.g. a 2.6.7-bk9 kernel).

(I assume you read bundled and associated kernel and kernel header
bundling, which is also bad for other reasons ;)
-- 
Axel.Thimm at ATrpms.net

Attachment: pgp00019.pgp
Description: PGP signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]