future kernel module rpm situation (was: kernel-source vs. kernel-sourcecode (please revert))

[Axel Thimm]

Arjan,

please stop shouting, I am not deaf or blind! :)

On Tue, Jun 15, 2004 at 02:27:27PM +0200, Arjan van de Ven wrote:
> On Tue, Jun 15, 2004 at 02:23:03PM +0200, Axel Thimm wrote:
> > Is there something wrong with using the headers from
> 
> yes
> 
> > make mrproper
> > modify EXTRAVERSION in Makefile to reflect target arch/flavour
> > cp -a configs/<my flavour and arch>.config .config
> > make oldconfig_nonint x2 & make dep or make nonint_oldconfig & make prepare
> > make -s include/linux/version.h
> 
> you assume that the makefile is the only thing changed between
> kernel-sourcecode and what the binary kernel rpms use. That is the
> case TODAY. It wasn't the case some time ago where the makefile
> wasn't changed at all. And it won't be the case in the future where
> I expect more changes to happen.
> 
> THIS IS AN IMPLEMENTATION DETAIL. DO NOT DEPEND ON THIS.

No matter how implementation dependent the current schemes are they do
work perfectly in this setup for all current and past Red Hat/Fedora
distributions (I am going as far back as RH7.3, and I know Dag Wieers
goes back to RH6.2). If the implementation is going to _have to_
change for any reason this will adapted (like already doen for the 2.4
-> 2.6 switch).

> > not violationg rules or breaking anything. These are the usual
> > steps required and recommended for building external kernel
> > modules adapted
> 
> NO THEY ARE NOT THE RECOMMENED STEPS
> nor are they the required steps.
> 
> > Would something break the above? It should not. At least there is
> > no sign upstream considers changing kbuild again in this respect,
> > and the rpms are under your control.
> 
> Yes and I am trying to get it into your head that these
> implementation details WILL change. DO NOT DEPEND ON THIS. There is
> no need, it's wrong.  Just don't.

How will they change? Please inform us in advance this time. Perhaps
you will get useful input before making any decision that will break
all ISVs' work out there.

Your mail is full of DON'Ts, I am missing a constructive approach.

If you feel they are doing it in the wrong way, please provide a
matching alternative.

Say you have neither a running nor an installed kernel, only the
neccessary build tools captured in a chroot waiting to build kernel
modules. Please no dependecies on having the kernel installed and even
running. These requirements are far too strict, and unneccessary as
past and current practice demonstrates. They may be adequate for
someone building for his own few kernels, but not for producing
several kernel module rpms in a row.
-- 
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/20040615/fec2b547/attachment.sig>