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 1MhoaU-00035N-Ig for garchives@archives.gentoo.org; Sun, 30 Aug 2009 17:53:10 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C1D2DE093E; Sun, 30 Aug 2009 23:02:06 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 7D6EDE093E for ; Sun, 30 Aug 2009 23:02:06 +0000 (UTC) Received: from mail.isohunt.com (b01.ext.isohunt.com [208.71.112.51]) by smtp.gentoo.org (Postfix) with ESMTP id EB46E66A53 for ; Sun, 30 Aug 2009 23:02:14 +0000 (UTC) Received: (qmail 20585 invoked from network); 30 Aug 2009 23:02:04 -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:02:04 +0000 Received: (qmail 3183 invoked by uid 10000); 30 Aug 2009 23:02:02 -0000 Date: Sun, 30 Aug 2009 23:02:02 +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> 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: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JwB53PgKC5A7+0Ej" Content-Disposition: inline In-Reply-To: <4A9AF609.3060902@gentoo.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Archives-Salt: 1dd09120-24e1-4f12-8e93-60bf7698781d X-Archives-Hash: 7ec7222bea22721dff751d5d25cc28b8 --JwB53PgKC5A7+0Ej Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 30, 2009 at 10:58:33PM +0100, Mike Auty wrote: > Robin H. Johnson wrote: > > FYI: > > get_running_version is used in one single ebuild, in the entire tree: > > sys-fs/evms/evms-2.5.5-r10.ebuild > > And there it's only for a warning. > Ok, I was just suggesting that if there was an intention to implement > config.gz checks, they should only apply when people ask about the > running version rather than the build version. Since that doesn't seem > popular or even necessary, perhaps neither is the need to check config.gz? The running version stuff may be needed to be used more than it is presently. If no kernel sources are present at all, all functions that check the kernel version presently bail out. get_version is also at the very top of linux-info's pkg_setup function, so it bails as well: * Determining the location of the kernel source code * Unable to find kernel sources at /usr/src/linux =2E.. 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. 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. > > The great majority of CONFIG_CHECK usage in the tree is fatal already. > > It only actually needs to be fatal only when it's being used to build a > > module. > Ok, I see what you're suggesting now. When people want to build > packages, but portage knows their kernel isn't setup to run them > properly, then it should still build them, but warn them strongly about > it (as opposed to currently, where it'll just die). 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. > > This leaves us between hand-holding the basic user's kernel configurati= on > > (exiting if the kernel config option is not enabled), and changing all > > non-module instances in the tree to be non-fatal. > Ok, so then the question is do we sacrifice correctness for fewer > (invalid) bugs? Seems like a judgement call. For what it's worth, I'm > not sure adding extra plumbing to allow smart users to bypass the checks > is the right middle ground. I'd either leave it as is, or change the > ebuilds to accurately reflect whether the userspace will build or not. 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). > > If you're building modules, most of the time you're using linux-mod, no= t just > > linux-info. There's no document or recommended behavior in the tree for= the > > above actually, and I'd like to introduce one. > Sounds like a good idea, it might also be worth adding to the quizes, if > existing devs are asking how it should be done? I guess that's a call > on how common it is to have kernel config requirements on userspace... 142 packages inherit linux-mod. 130 packages use functions or the MODULE_NAMES code from linux-mod. 105 packages inherit linux-info. 11 packages inherit both linux-info AND linux-mod. So I propose this as resolutions from the above: 1. USE=3Dmodules added to the base profile. 2. Every package that builds kernel modules must offer USE=3Dmodules,=20 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. --=20 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 --JwB53PgKC5A7+0Ej Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Robbat2 @ Orbis-Terrarum Networks - The text below is a digital signature. If it doesn't make any sense to you, ignore it. iEYEARECAAYFAkqbBOoACgkQPpIsIjIzwixEvACg0CWO4wmPthuxRmFPNTMI5rVW vBMAnRME1cRmr16MGCCPpnGj0dx3ilw+ =wO/q -----END PGP SIGNATURE----- --JwB53PgKC5A7+0Ej--