From: Mike Auty <ikelos@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] linux-info.eclass: lacking sources, config checks and module building
Date: Sun, 30 Aug 2009 21:21:24 +0100 [thread overview]
Message-ID: <4A9ADF44.9080504@gentoo.org> (raw)
In-Reply-To: <robbat2-20090830T192224-029701861Z@orbis-terrarum.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.
I might be reading the eclass wrong, but it looks as though OUTPUT_DIR
is only set to use uname -r if the KV_* variables match the output of
uname -r:
[ "${KV_MAJOR}.${KV_MINOR}.${KV_PATCH}${KV_EXTRA}" == "$(uname -r)" ] && \
OUTPUT_DIR="${OUTPUT_DIR:-/lib/modules/${KV_MAJOR}.${KV_MINOR}.${KV_PATCH}${KV_EXTRA}/build}"
Otherwise it's taken from the KBUILD_DIR and then it even checks inside
the KV_DIR's Makefile to find one. So not checking /proc/config.gz
isn't a moot point anymore, which is not to say it's not a good idea,
but the reason against doing it still stands. To deal with running
kernel's, there's a get_running_version function, that will use uname to
fill out the KV_* variables appropriately.
> Proposed solution:
> ------------------
> We need to be able to reduce user error, so we cannot simply make it
> trust the user by default. So I propose that we add an environment
> variable (I'm not set on the name yet), eg:
> EXTERNALLY_BUILT_KERNEL=1
>
> This option will cause linux-info.eclass to consider ALL kernel option
> checks non-fatal. That way we still get the warnings and logs, but it
> does not stop the builds.
I'm not sure what this is solving? It doesn't seem to reduce user
error, it just allows users a way to override portage errors? It seems
unrelated to config.gz and the discussion going on in the previous
thread. I do like the idea of being able to override portage when it's
stopping us from building (incorrectly), but surely with the capability
to have non-fatal checks, we can try to minimize the times when
portage/the ebuild is wrong using that, instead of a whole new override?
> When is the above NOT enough?
> -----------------------------
> The only time that ANY kernel sources are required is when you are
> building an out-of-tree module. For this purpose, they must be
> configured.
There's a lot of ebuilds that use linux-info, and they can't all be
out-of-tree modules. Are they misusing linux-info, or are you saying
there's a specific instance in which linux-info requires configured
kernel sources?
> The check for having configured kernel sources must only be executed
> when the modules are about to be compiled. Putting it in pkg_preinst
> would block use of binpkgs on (related) machines.
>
> - If a package builds modules AND userspace, we should offer a way to
> build the userspace only, as the user can build their modules
> externally (or patch them into the kernel) [1]
> - For packages that ONLY build modules, and no userspace at all, having
> EXTERNALLY_BUILT_KERNEL=1 means that they should error out? [2]
> (this case might be thrown into the above one).
That all seems fine, but again these just seem like standard guidelines.
Is there not already some "how to write kernel module ebuilds" page
somewhere that documents how you're supposed to use linux-info?
Mike 5:)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
iEYEARECAAYFAkqa30QACgkQu7rWomwgFXo99gCfd8NbK9QkxtJ9BKalq/n1iBxn
l0QAoLiBsvKXZRzR4Dp8HEtoxrsONCtc
=ZK9i
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2009-08-30 15:12 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 [this message]
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
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=4A9ADF44.9080504@gentoo.org \
--to=ikelos@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