-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robin H. Johnson wrote:
> It does NOT check /proc/config.gz presently. The original logic against
> not checking /proc was that we were targeting the kernel being built,
> but that's moot given the use of `uname -r` in OUTPUT_DIR.

I might be reading the eclass wrong, but it looks as though OUTPUT_DIR
is only set to use uname -r if the KV_* variables match the output of
uname -r:

[ "${KV_MAJOR}.${KV_MINOR}.${KV_PATCH}${KV_EXTRA}" == "$(uname -r)" ] && \
OUTPUT_DIR="${OUTPUT_DIR:-/lib/modules/${KV_MAJOR}.${KV_MINOR}.${KV_PATCH}${KV_EXTRA}/build}"

Otherwise it's taken from the KBUILD_DIR and then it even checks inside
the KV_DIR's Makefile to find one.  So not checking /proc/config.gz
isn't a moot point anymore, which is not to say it's not a good idea,
but the reason against doing it still stands.  To deal with running
kernel's, there's a get_running_version function, that will use uname to
fill out the KV_* variables appropriately.

> Proposed solution:
> ------------------
> We need to be able to reduce user error, so we cannot simply make it
> trust the user by default. So I propose that we add an environment
> variable (I'm not set on the name yet), eg:
> EXTERNALLY_BUILT_KERNEL=1
> 
> This option will cause linux-info.eclass to consider ALL kernel option
> checks non-fatal. That way we still get the warnings and logs, but it
> does not stop the builds.

I'm not sure what this is solving?  It doesn't seem to reduce user
error, it just allows users a way to override portage errors?  It seems
unrelated to config.gz and the discussion going on in the previous
thread.  I do like the idea of being able to override portage when it's
stopping us from building (incorrectly), but surely with the capability
to have non-fatal checks, we can try to minimize the times when
portage/the ebuild is wrong using that, instead of a whole new override?

> When is the above NOT enough?
> -----------------------------
> The only time that ANY kernel sources are required is when you are
> building an out-of-tree module. For this purpose, they must be
> configured.

There's a lot of ebuilds that use linux-info, and they can't all be
out-of-tree modules.  Are they misusing linux-info, or are you saying
there's a specific instance in which linux-info requires configured
kernel sources?

> The check for having configured kernel sources must only be executed
> when the modules are about to be compiled. Putting it in pkg_preinst
> would block use of binpkgs on (related) machines.
> 
> - If a package builds modules AND userspace, we should offer a way to
>   build the userspace only, as the user can build their modules
>   externally (or patch them into the kernel) [1]
> - For packages that ONLY build modules, and no userspace at all, having
>   EXTERNALLY_BUILT_KERNEL=1 means that they should error out? [2]
>   (this case might be thrown into the above one).

That all seems fine, but again these just seem like standard guidelines.
 Is there not already some "how to write kernel module ebuilds" page
somewhere that documents how you're supposed to use linux-info?

Mike  5:)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkqa30QACgkQu7rWomwgFXo99gCfd8NbK9QkxtJ9BKalq/n1iBxn
l0QAoLiBsvKXZRzR4Dp8HEtoxrsONCtc
=ZK9i
-----END PGP SIGNATURE-----