Re: [gentoo-dev] linux-info.eclass and $CONFIG_CHECK

[John Mylchreest]

On Wed, 2005-09-21 at 12:03 -0400, Chris Gianelloni wrote:
> The current /usr/src/linux method works quite well for releases.  The
> only issue we're having is a non-fatal check being fatal, which is going
> to be fixed.

OK, so being the huy who wrote and looks after all this stuff, here is
my 2c and reasoning.

First of all, falling back on `uname -r` isn't going to happen for
several reasons. I can understand for some why this might seem sensible
(what happens if you remove your kernel sources for example). But the
fact remains that testing the currently running kernel is not a viable
option in my mind. Why? well, 1: the running kernel bares absolutely no
relevance on the environment which you're building this for. 2: you can
pass KERNEL_DIR manually, so if you refuse to work in the expected way
then set KERNEL_DIR to point to the right location.

Secondly, I have thought about this some more during the day, just as I
did at initial implementation (The code could do with a tidy-up
anyways). After much deliberation I feel the actual best way to deal
with this, is to have an override envvar which will bypass a die, and
simply warn instead. This will mean that those people who cross-compile
regularly, or building stages etc will work fine, and normal operation
would continue to refuse a build if the environment its building for
doesn't seem sane. At the end of the day, the true root cause of
something die'ing when it shouldn't is at the ebuild. That.. and if its
really not that important, then surely the ebuild can call the config
check itself, and handle it as it feels fit.

I'll update the bug also with this.

-- 
Role:            Gentoo Linux Kernel Lead
Gentoo Linux:    http://www.gentoo.org
Public Key:      gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515