Re: [gentoo-dev] linux-info.eclass: lacking sources, config checks and module building

[Robin H. Johnson]

On Sun, Aug 30, 2009 at 10:58:33PM +0100, Mike Auty wrote:
> Robin H. Johnson wrote:
> > FYI:
> > get_running_version is used in one single ebuild, in the entire tree:
> > sys-fs/evms/evms-2.5.5-r10.ebuild
> > And there it's only for a warning.
> Ok, I was just suggesting that if there was an intention to implement
> config.gz checks, they should only apply when people ask about the
> running version rather than the build version.  Since that doesn't seem
> popular or even necessary, perhaps neither is the need to check config.gz?
The running version stuff may be needed to be used more than it is
presently.

If no kernel sources are present at all, all functions that check the
kernel version presently bail out. get_version is also at the very top
of linux-info's pkg_setup function, so it bails as well:
* Determining the location of the kernel source code
* Unable to find kernel sources at /usr/src/linux
...

The existing state is:
- Force the user to install sources

Our choices are:
- `uname -r` output.
- Create an override environment variable for all the checks.

/proc/config.gz comes back here again, in that, we can use it as a
middle ground with `uname -r`, rather than having the environment
variable.

So from our discussion, I propose the following:
Finding the kernel version:
---------------------------
0. (optional) give an env var to bypass entirely.
1. Use existing logic of /usr/src/linux, KERNEL_DIR et al.
2. Fall back to using the running version, with a warning.

Checking a configuration option, for non-module use:
----------------------------------------------------
0. (optional) give an env var to make all checks non-fatal.
1. Use existing logic of .config from /usr/src/linux, KERNEL_DIR et al.
2. Fall back to /proc/config.gz if available.


> > The great majority of CONFIG_CHECK usage in the tree is fatal already.
> > It only actually needs to be fatal only when it's being used to build a
> > module.
> Ok, I see what you're suggesting now.  When people want to build
> packages, but portage knows their kernel isn't setup to run them
> properly, then it should still build them, but warn them strongly about
> it (as opposed to currently, where it'll just die).
Two different cases here:
1. Portage knows their kernel is not setup correctly.
2. Portage cannot find out enough info.

It's #2 that bites on virtual machines and hardened servers, and is what
I'd like to fix.

> > This leaves us between hand-holding the basic user's kernel configuration
> > (exiting if the kernel config option is not enabled), and changing all
> > non-module instances in the tree to be non-fatal.
> Ok, so then the question is do we sacrifice correctness for fewer
> (invalid) bugs?  Seems like a judgement call.  For what it's worth, I'm
> not sure adding extra plumbing to allow smart users to bypass the checks
> is the right middle ground.  I'd either leave it as is, or change the
> ebuilds to accurately reflect whether the userspace will build or not.
It's a one-liner to give an override making all checks non-fatal, with
the downside that it can't differentiate why the checks are being made.
So yes, in the case we should simply fix all of the ebuilds (after the
kernel source check is fixed as well).

> > If you're building modules, most of the time you're using linux-mod, not just
> > linux-info. There's no document or recommended behavior in the tree for the
> > above actually, and I'd like to introduce one.
> Sounds like a good idea, it might also be worth adding to the quizes, if
> existing devs are asking how it should be done?  I guess that's a call
> on how common it is to have kernel config requirements on userspace...
142 packages inherit linux-mod.
130 packages use functions or the MODULE_NAMES code from linux-mod.
105 packages inherit linux-info.
11 packages inherit both linux-info AND linux-mod.

So I propose this as resolutions from the above:
1. USE=modules added to the base profile.
2. Every package that builds kernel modules must offer USE=modules, 
   which can be used to disable building the kernel modules, leaving a
   pure userspace build of that package.

Most of the changes to the above can be done in the linux-mod eclass, so
I don't think we'll have to touch that many packages directly.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@g.o
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85