On Mon, Aug 31, 2009 at 12:30:02AM +0100, Mike Auty wrote: > > 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? Yes, a warning with using /proc/config.gz.
I missed a bit for the config option. If there is NO source of the config data, what do we do? Error out or more warnings? > 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? This is what I use for my home workstation: /etc/portage/profile/virtuals:virtual/linux-sources sys-kernel/git-sources /etc/portage/profile/virtuals:virtual/alsa sys-kernel/git-sources /etc/portage/profile/package.provided:sys-kernel/git-sources-2.6.30 Saves having any fake package like that. > > 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. Want to lend a hand fixing up the ebuilds then? I'll work on the eclass sources check. > > 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. > 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). There IS still a point of having the entirely empty kernel package installed: - Split userspace/kernel packages where the userspace package has a dependency on the module-providing package. - other packages that might have a dependency on the module-providing package. - /etc/modprobe.d/ files. USE=-modules will ONLY block files installed to /lib/modules/. > Also, I'd assume +modules would be added as a default. I'm not sure we can get away with USE-defaults for this change, due to the amount of EAPI=0 stuff that will be changing, so it'll be in profiles/base/make.defaults instead. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
