[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,

On Sun, 2004-07-04 at 14:15, Axel Thimm wrote:
> 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.)

You only need to provide the release define for what kernel you want to
build for.  if it contains smp it will build smp stuff, if the --target
is i586 it will build i586.  The spec file can be written that way and
countless examples exist as well of this working.

That doesn't mean that it cannot be useful to have such a define in some
cases; it just means that it's not necessary by default.

For regular users it's even less of an issue since a regular user just
wants to rebuild a .src.rpm for himself, and will probably not build
both i586 and i686.


> > 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?

Like I said; --target and --define 'kernel 2.6.5-1.358' or 'kernel
2.6.5-1.358smp' works just fine.

> 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.

Yes, just not in the form of kernelsrcdir; what can be done
automatically should be done automatically.  And again - kernelsrcdir is
the wrong name from the start.


> 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

If the grouping had obvious gains (like share a whole bunch of files)
that might make sense.  I'd prefer the separate, one for each kernel
release, but who knows, there are lots of factors in play.

> 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).

Why do you keep harping on this ? You cannot expect Red Hat to do
something that works out of the box for all third party kernels.  Why
don't you just make sure you have a similar solution to whatever Red Hat
does that works for your set of custom kernels ?  It's not because Red
Hat decides to lump a few together for *their* packages that it forces
you and your custom kernels to be together.

The reason I think the decision is unconstructive is just because of
stuff like this - let's focus on getting people from Red Hat that have
historically even been completely against the idea of external kernel
module packaging overall, and let's move up the ladder to a common
solution one step at a time.  Ask for something that makes it possible
what we as packagers need to do, not for one where most parties need to
compromise beyond what they're willing to compromise on.

This is btw not a troll, just to make sure.  I respect your work and I
respect the time you put into this; I'm just not convinced that whether
or not a package gets split up makes any sort of difference to whether
or not you or me can package kernel modules.

Thomas




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