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 22:58:33 +0100 [thread overview]
Message-ID: <4A9AF609.3060902@gentoo.org> (raw)
In-Reply-To: <robbat2-20090830T204430-253756533Z@orbis-terrarum.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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 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).
> This leaves us between hand-holding the basic user's kernel configuration
> (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.
>> 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?
> If you're building modules, most of the time you're using linux-mod, not 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...
Still, I think I'm on the right page, and even in agreement (which makes
me happy). 5:) Thanks!
Mike 5:)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
iEYEARECAAYFAkqa9gkACgkQu7rWomwgFXq1PwCfTbp8hqsGZjDmsxKE21gKe1Y8
lYYAoI2EBCn5KwQdlm6Xd8u0q7KGl7gI
=Jrsa
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2009-08-30 16:49 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 [this message]
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=4A9AF609.3060902@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