From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id D1829198005 for ; Thu, 21 Feb 2013 18:43:12 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4917321C004; Thu, 21 Feb 2013 18:43:00 +0000 (UTC) Received: from virtual.dyc.edu (mail.virtual.dyc.edu [67.222.116.22]) by pigeon.gentoo.org (Postfix) with ESMTP id 694AEE0026 for ; Thu, 21 Feb 2013 18:42:59 +0000 (UTC) Received: from [192.168.3.7] (cpe-67-252-134-33.buffalo.res.rr.com [67.252.134.33]) by virtual.dyc.edu (Postfix) with ESMTPSA id DD3CF74C02A for ; Thu, 21 Feb 2013 13:42:57 -0500 (EST) Message-ID: <51266AA2.40505@opensource.dyc.edu> Date: Thu, 21 Feb 2013 13:42:42 -0500 From: "Anthony G. Basile" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130218 Thunderbird/17.0.2 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: [gentoo-dev] Building against /usr/src/linux and linux-info.eclass Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 850c6766-abfa-4f7f-b354-6b0fb6921b84 X-Archives-Hash: 597c76575150b2c27cf475937e8d6fa6 Hi everyone, This issue has come up in a few bugs so I want to bounce it off the community. When building packages that need a configured kernel source tree, many ebuilds inherit linux-info to find configuration info about the kernel. However, there is the running kernel with its configuration (/proc/config.gz if it exists), there is the kernel source tree (/usr/src/linux if it exists and is configured) and both of these can be of a different version than linux-headers. Since building modules consumes headers from /usr/include/linux, but uses code from /usr/src/linux and then these modules are expected to insmod against the running kernel, all of which can be mismatched, we have a lot of room for breakage. Eg. bug #458014. Any ideas about how to deal cleanly with situations like that? -- Anthony G. Basile, Ph. D. Chair of Information Technology D'Youville College Buffalo, NY 14201 (716) 829-8197