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

[Mike Auty]

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

Robin H. Johnson wrote:
> 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.

Ok, that seems a very reasonable use.

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

Where 2 also issues a warning, presumably?  I've had a think and can't
see any repercussions in changing the default behaviour, but I'm
assuming people would only generally hit 2 with virtual machines and/or
hardened servers.  Can you see either of these suffering from defaulting
to the running kernel?  Do you know of many circumstances where 2 might
get hit by normal users other than those situations?

Also (and potentially off-topic), if we're using linux-info to detect
kernel sources, whether installed or not, should we also check the tree
for ebuilds that require a package which PROVIDES="sources"?  I
personally use a single git checkout, since I think (possibly
mistakenly, I honestly haven't checked) that it will leave different
checkouts of the kernel all over my /usr/src directory, whenever a new
version's emerged.  I've had to create a fake-sources package to trick
ebuilds that need *some* sources installed, and I'm wondering if that
should be necessary?

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

Ok, I'm all for it, and the solution you've suggested sounds fine.

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

I'd definitely try and do things the right way, and a global override
(whilst easy) doesn't sound like it.  Fixing all the ebuilds (and the
kernel source check) sounds like the way to go.

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

Yep, although if the changes are in linux-mod, then those packages that
*only* provide kernel modules will need a way to not present that use
flag (no point installing a package is USE="-modules" and nothing gets
installed).  Also, I'd assume +modules would be added as a default.

The whole plan sounds extremely sensible in general!  5:)

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

iEYEARECAAYFAkqbC3oACgkQu7rWomwgFXpwywCeKzcB0Znzuul3wq9U9ew5+SuX
scQAnjShkQTVQQrFABb8u2t0RsP9K34z
=LFlY
-----END PGP SIGNATURE-----