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

["Robin H. Johnson" <robbat2@gentoo.org>]

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     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85