From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1MhpHr-0001vo-Cq for garchives@archives.gentoo.org; Sun, 30 Aug 2009 18:37:59 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5A5C5E0952; Sun, 30 Aug 2009 23:46:55 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 1D5A7E0952 for ; Sun, 30 Aug 2009 23:46:55 +0000 (UTC) Received: from mail.isohunt.com (b01.ext.isohunt.com [208.71.112.51]) by smtp.gentoo.org (Postfix) with ESMTP id A00FB655A8 for ; Sun, 30 Aug 2009 23:47:03 +0000 (UTC) Received: (qmail 3214 invoked from network); 30 Aug 2009 23:46:52 -0000 Received: from tsi-static.orbis-terrarum.net (HELO grubbs.orbis-terrarum.net) (76.10.188.108) by mail.isohunt.com (qpsmtpd/0.33-dev on beta01) with (CAMELLIA256-SHA encrypted) ESMTPS; Sun, 30 Aug 2009 23:46:52 +0000 Received: (qmail 10302 invoked by uid 10000); 30 Aug 2009 23:46:51 -0000 Date: Sun, 30 Aug 2009 23:46:51 +0000 From: "Robin H. Johnson" To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] linux-info.eclass: lacking sources, config checks and module building Message-ID: References: <4A9ADF44.9080504@gentoo.org> <4A9AF609.3060902@gentoo.org> <4A9B0B7A.2090307@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A9B0B7A.2090307@gentoo.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Archives-Salt: bba4c933-a2f2-449c-b3ce-3fd53a8eebb8 X-Archives-Hash: d873822e0dbf4a75f7346a2d9b56ee23 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