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 1Mhp1Z-0007pu-CP for garchives@archives.gentoo.org; Sun, 30 Aug 2009 18:21:09 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 66057E0855; Sun, 30 Aug 2009 23:30:05 +0000 (UTC) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by pigeon.gentoo.org (Postfix) with ESMTP id 4D4D0E0855 for ; Sun, 30 Aug 2009 23:30:05 +0000 (UTC) Received: from compute1.internal (compute1.internal [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 11D3959104 for ; Sun, 30 Aug 2009 19:30:05 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Sun, 30 Aug 2009 19:30:05 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:date:from:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; s=smtpout; bh=rBWtqW/XY8R6pgbaOv9aaFn1ZZw=; b=LDIndwt9nh8zNGHI6g4dHtO1GcuZp7hlLejqoKwRGin+5PUwbln7CYFJ+8NILxBVSq+CUhjy2rg983SQ9EuikF0D66p6VVtpWa0ZSe8aNJlNGvy/q6XM1fgkZQCiOlci248UGjbZ4/Ly4Ks13Rgc4/fGDdBfX2Z2yhfeNopw/W8= X-Sasl-enc: 6hbgIehQzvLUFkenq30gUuwD3Klj9R7qWaZX0IYSts4F 1251675004 Received: from [192.168.188.1] (82-71-33-97.dsl.in-addr.zen.co.uk [82.71.33.97]) by mail.messagingengine.com (Postfix) with ESMTPSA id 53FC410B3 for ; Sun, 30 Aug 2009 19:30:04 -0400 (EDT) Message-ID: <4A9B0B7A.2090307@gentoo.org> Date: Mon, 31 Aug 2009 00:30:02 +0100 From: Mike Auty User-Agent: Thunderbird 2.0.0.22 (X11/20090822) 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] linux-info.eclass: lacking sources, config checks and module building References: <4A9ADF44.9080504@gentoo.org> <4A9AF609.3060902@gentoo.org> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: ee5e7b34-0cd4-41b4-a160-8d5db0872ce8 X-Archives-Hash: 933b6be238dfa024b1d048957d12f746 -----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-----