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