From: "Robin H. Johnson" <robbat2@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] linux-info.eclass: lacking sources, config checks and module building
Date: Mon, 7 Sep 2009 10:42:07 +0000 [thread overview]
Message-ID: <robbat2-20090907T103524-874704368Z@orbis-terrarum.net> (raw)
In-Reply-To: <4AA4D22B.7000805@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 2010 bytes --]
On Mon, Sep 07, 2009 at 10:28:11AM +0100, Daniel Drake wrote:
> Robin H. Johnson wrote:
> >It does NOT check /proc/config.gz presently. The original logic against
> >not checking /proc was that we were targeting the kernel being built,
> >but that's moot given the use of `uname -r` in OUTPUT_DIR.
> That seems like a bug. OUTPUT_DIR should default to unset which
> would cause the internal KV_OUT_DIR to be set to KV_DIR. However I
> can see from the code that's not the case, and it's not clear why.
It's messy. I'll maybe tackle it after I'm done the work on configs and
USE=modules.
> Relying on "uname -r" or /proc/config.gz is still something we
> should avoid (unless user configured, perhaps, or in very
> exceptional circumstances) however it looks like this isn't a change
> that you are proposing.
The only time I'm saying that uname -r and /proc/config.gz are looked
as, is where there is no kernel sources or they are installed but not
configured. But that is as part of a larger body of work to fix up all
packages that are merely checking the kernel options during build, not
relying on the config to build.
Kernel modules still require configured sources to be installed.
> Thanks for working on this. It's a sensitive area so please take
> care and help people pick up the pieces. If you are really
> motivated, it might be worth rethinking the whole separate output
> directory implementation.
For anybody following this, we're doing the work on two tracker bugs:
283320 - Changes to linux-info
283900 - USE=modules change for linux-mod and packages.
We've got the core eclass stuff done, but not enabled yet.
If you want to test it it:
1. mv your .config or entire kernel sources away
2. I_KNOW_WHAT_I_AM_DOING=1 emerge udev
You should get warnings, but no errors.
--
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
[-- Attachment #2: Type: application/pgp-signature, Size: 330 bytes --]
prev parent reply other threads:[~2009-09-07 10:42 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-30 19:58 [gentoo-dev] linux-info.eclass: lacking sources, config checks and module building Robin H. Johnson
2009-08-30 20:21 ` Mike Auty
2009-08-30 21:29 ` Robin H. Johnson
2009-08-30 21:58 ` Mike Auty
2009-08-30 23:02 ` Robin H. Johnson
2009-08-30 23:30 ` Mike Auty
2009-08-30 23:46 ` Robin H. Johnson
2009-08-31 0:00 ` Mike Auty
2009-08-31 0:27 ` Robin H. Johnson
2009-08-31 0:41 ` Mike Auty
2009-08-31 22:43 ` Mike Auty
2009-09-07 9:28 ` Daniel Drake
2009-09-07 10:42 ` Robin H. Johnson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=robbat2-20090907T103524-874704368Z@orbis-terrarum.net \
--to=robbat2@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox