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: Mon, 31 Aug 2009 01:41:38 +0100 [thread overview]
Message-ID: <4A9B1C42.8030805@gentoo.org> (raw)
In-Reply-To: <robbat2-20090831T000741-908543613Z@orbis-terrarum.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Robin H. Johnson wrote:
> If you feel like reviewing ~140 packages and filing bugs for them, I
> won't stop you. But I'm just going to go and fix the ones that seem
> simple enough to me, and only file bugs for the complex ones.
Ok, I'll do what I can tomorrow. I'm off to bed now... 5:)
> Err, I'm not following what you claim is the problem here?
>
> cat/foo-mod:
> inherit linux-mod
> CONFIG_CHECK="!option"
>
> ...
>
> The user sets USE=-modules because they have built cat/foo-mod on their
> own, into the kernel. foo-mod installs nothing
Just checking that it will actually install nothing, rather than failing
out with an error because the kernel has "option" set. I'm just
re-iterating that CONFIG_CHECK should only occur if USE="modules". If
USE="-modules", then the CONFIG_CHECK options should probably be ignored
shouldn't they?
> It needs to be ALWAYS available. The ipset bug I linked earlier in the
> thread was an example of that. The userspace is useless without the
> kernel code, but there is nothing to stop the user patching it into
> their kernel and not having it as a module at all (as is the case on a
> couple of my work boxes, which is why the bug got filed).
Ok, fair enough. However, in that instance, ipset is a userspace
dependency, I was talking about kernel modules that have no userspace
dependencies. I suppose there could be a case where someone is trying
to custom build a userspace tool that isn't in portage yet, but I still
think it might cause confusion to allow USE="modules" on kernel modules
(without any dependencies) that then install nothing. I'm wondering
which will cause more bugs to be filed?
Mike 5:)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
iEYEARECAAYFAkqbHEEACgkQu7rWomwgFXrEpQCeIMWofCtvwHKJoZsb3/qUyLcP
tTUAoIb3Sr645x6NY82LXK6i/3g75NF5
=uaOB
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2009-08-30 19:32 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 [this message]
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=4A9B1C42.8030805@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