Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 103878 - linux-info eclass needs a way to *warn* about config options missing
Summary: linux-info eclass needs a way to *warn* about config options missing
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: High blocker (vote)
Assignee: Gentoo Kernel Bug Wranglers and Kernel Maintainers
Depends on:
Blocks: 103396 103877
  Show dependency tree
Reported: 2005-08-26 21:57 UTC by SpanKY
Modified: 2005-09-22 13:01 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description SpanKY gentoo-dev 2005-08-26 21:57:51 UTC
a bunch of ebuilds use the CONFIG_CHECK option ... however, they will compile
just fine if the option doesnt exist, they just may not load/run properly

so linux-info needs a way to differentiate between fatal checks (the package
wont compile without the option enabled) and non-fatal checks (the package will
build but will not run correctly)
Comment 1 Henrik Brix Andersen 2005-08-27 02:59:23 UTC
I really fail to see the logic of this. Please see my comments on bug #103396
and bug #103877.
Comment 2 Stefan Schweizer (RETIRED) gentoo-dev 2005-08-27 03:21:39 UTC
Because the user maybe wants to make his kernel later?
When he is installing it should be imo the choice of the user when he compiles
his kernel. Same for embedded .. I think it is against the spirit of gentoo to
aggressively check for kernel-options being present.

What makes more sense imo is to add postemerge warnings that you need a certain
option to be present to run the program.

I think we can leave out linux-info of the deal then.
It will also make many packages compile faster as the linux-info inheriting and
pkg_setup is not needed.
Comment 3 Daniel Drake (RETIRED) gentoo-dev 2005-08-27 05:22:57 UTC
Maybe a way to override it from the user environment would be ok (some obscure 
env var or something?) but I don't see any reason for it to be done on a per-
ebuild basis, or on by default, or encouraged for normal usage.

The reasons I can see for this are for those people building the livecd's, and 
those people who are cross compiling (presumably mike included here)
Comment 4 SpanKY gentoo-dev 2005-08-27 12:08:23 UTC
or those people who build packages on a central host and deploy onto sub-machines

plenty of valid reasons you'd want to change the error to a warning ... and
since it is a pretty common thing, toss in an ebeep/esleep ... forcing people to
use some obscure var for this package is a pita, especially when other devs
start making you export other obscure vars for their packages to work ...
Comment 5 Daniel Drake (RETIRED) gentoo-dev 2005-08-27 16:55:01 UTC
I don't agree, as the way it is done currently is correct for the majority of
users - not allowing them to install software that doesn't work.

Ignoring my own opinion, you suggest differentiating between between "build"
problems (and lack of them), how do you define this? Almost all module ebuilds
which rely on a certain kernel feature will compile fine but spit out a ton of
"unknown symbol" messages every time you run depmod, modules-update, etc, unless
they have the relevant object files to link against (which are very often
controlled by kernel config options). Also, a few of the CONFIG_CHECK packages I
have worked with include their own configuration checks, but these are
replicated in portage for consistency (plus the ability to control the error
Comment 6 SpanKY gentoo-dev 2005-08-27 23:34:07 UTC
i was just covering all bases ... i dont know if it's possible to have a bad
compile if certain features are disabled in your kernel

depmod doesnt write any object files, it just generates the modules files in
/lib/modules/$(uname -r)/modules.*
Comment 7 Daniel Drake (RETIRED) gentoo-dev 2005-08-29 03:38:33 UTC
Thinking about it more, I can't think of any cases where a lack of kernel option
would cause compilation failure (exception is those packages which check
themselves and abort if their runtime requirements aren't met).

I didn't mean that depmod actually writes object files - I was referring to how
 it calculates module dependencies. If one module references symbol a_symbol,
depmod will try and figure out which module provides this symbol (so it can be
loaded first by modprobe) or if it is already provided by the kernel. If no
other module provides a_symbol and the kernel doesn't either, then it'll spit
out a message: Unknown symbol a_symbol

You'll get lots of these sorts of messages if you compile a module without the
required options used to configure the kernel.
Comment 8 Alin Năstac (RETIRED) gentoo-dev 2005-09-12 12:25:19 UTC
IMO, linux-info should provide a way for warning users about a missing kernel
option. vapier is right on this one.

take for instance net-dialup/ppp. it needs CONFIG_PPP in order to run but it
doesn't need it at compile time.
in case you are building your packages on another machine, you will be forced to
activate this option if you want to build ppp, but this test makes no sense on
the building machine.

the way I see it is either:
a) add a parameter to check_extra_config which will inhibit die call in this
function (along with some minor changes of the info messages)
b) write a brand new function that warn user about missing options

do I have kernel herd approval to implement one of the above variants?
Comment 9 John Mylchreest (RETIRED) gentoo-dev 2005-09-21 02:46:01 UTC
Sorry, missed commenting on this one.
Yeah, no objections at all - not every config option should be fatal. I suppose
I'd ask the question why not just call the config check from src_unpack or
pkg_setup, but untimately they can produce the same outcome anyways.

If someone wants to suggest a specialchar to prefix the check with, then I can
sort something out if no one else beats me to it.

right now ! is the only recognised prefix, which negates the check.
Comment 10 John Mylchreest (RETIRED) gentoo-dev 2005-09-21 02:50:10 UTC
also to note...
I cant see this being normal behaviour.
I wouldn't encourage this for any specific package in portage.
Comment 11 John Mylchreest (RETIRED) gentoo-dev 2005-09-21 02:51:59 UTC
At the end of the day, if we die or not people can avoid it.
Reading through the bug comments again, maybe an envvar is the way forward.
Comment 12 Georgi Georgiev 2005-09-21 03:26:24 UTC
One more thing. What should linux-info do if there are no kernel sources at all?
Currently it dies if there is nothing in $KERNEL_DIR but it does not pull a
dependency on the sources.

If I'm not being clear enough, this comment is a follow-up of
Comment 13 Chris Gianelloni (RETIRED) gentoo-dev 2005-09-21 06:14:44 UTC
Oh yeah... ppp now barfs when building a new livecd with the same specs from
2005.1, so something changed since July 9th, which isn't necessary, as it
compiled *perfectly* before without a configured kernel.
Comment 14 C. Daelhousen (sapphirecat) 2005-09-21 09:25:35 UTC
To summarize my use case: as a convenience, I keep rp-pppoe, dhcpcd, and pppd
all installed in case the net access is changed. (Which is quite possible for
people who are moving relatively frequently.) Since this is a Linux-only
machine, getting packages to enable net access is extremely painful in
comparison to a kernel recompile.

IMHO, packages requiring certain kernel configurations to *run* should be
checking at *runtime* and giving a sensible error message in event of failure.
If the error message is wrong/obsolete/nonexistent and it's fixed upstream, then
Gentoo developers (and presumably those of other distros) don't have to waste
time playing games with patches or the package manager to deal with the issue
every release.
Comment 15 John Mylchreest (RETIRED) gentoo-dev 2005-09-21 09:55:37 UTC
I have thought about this some more during the day, just as I
did at initial implementation (The code could do with a tidy-up
anyways). After much deliberation I feel the actual best way to deal
with this, is to have an override envvar which will bypass a die, and
simply warn instead. This will mean that those people who cross-compile
regularly, or building stages etc will work fine, and normal operation
would continue to refuse a build if the environment its building for
doesn't seem sane. At the end of the day, the true root cause of
something die'ing when it shouldn't is at the ebuild. That.. and if its
really not that important, then surely the ebuild can call the config
check itself, and handle it as it feels fit.

Any objections?
Comment 16 Chris Gianelloni (RETIRED) gentoo-dev 2005-09-21 11:02:56 UTC
Objection here for the reasons stated in the email thread on -dev, summarized below.

This won't work for releases as it'll make it into stages and stage building
doesn't support per-package environments.
Comment 17 Alin Năstac (RETIRED) gentoo-dev 2005-09-21 12:28:15 UTC
given the fact that warnings should occur in pkg_postinst, I think the best
thing to do is a new function called warn_extra_config (maybe a better name
should be found) which analyse CONFIG_WARN content in the same way as
check_extra_config do on CONFIG_CHECK.

a new function should be added at the end of linux-info.eclass:
linux-info_pkg_postinst() {
        get_version || die "Unable to calculate Linux Kernel version"
        [ -n "${CONFIG_WARN}" ] && warn_extra_config;
Comment 18 Georgi Georgiev 2005-09-21 13:06:10 UTC
(In reply to comment #17)
> a new function should be added at the end of linux-info.eclass:
> linux-info_pkg_postinst() {
>         get_version || die "Unable to calculate Linux Kernel version"
>         [ -n "${CONFIG_WARN}" ] && warn_extra_config;
> }

You accomplish nothing, as the kernel sources still aren't there. Not when in
postinst, not when in unpack... I hope releng will agree on this one.

Simply put -- no DEP on linux-sources == no sources. (Well, maybe not...)
Also, while you're on it, try to make it so that it works for the extremely
perverted case of running "emerge package-in-question" in a chroot on a FreeBSD
after unpacking a stage2 in the chroot (this implies the missing kernel sources).
Comment 19 Alin Năstac (RETIRED) gentoo-dev 2005-09-21 13:09:22 UTC
ok, maybe this version will do:
linux-info_pkg_postinst() {
        get_version && [ -n "${CONFIG_WARN}" ] && warn_extra_config;
Comment 20 Alin Năstac (RETIRED) gentoo-dev 2005-09-21 13:11:01 UTC
oh, another mistake :(
linux-info_pkg_postinst() {
        get_version && [ -n "${CONFIG_WARN}" ] && warn_extra_config
        return 0
Comment 21 Alin Năstac (RETIRED) gentoo-dev 2005-09-22 02:13:01 UTC
if no one want to solve this bug, I will.
in about 8 hours I will submit a new linux-info.
Comment 22 Henrik Brix Andersen 2005-09-22 03:59:31 UTC
By "submit" I trust it you mean attach a proposed patch to this bug report for 
reviewing by the kernel herd?
Comment 23 Alin Năstac (RETIRED) gentoo-dev 2005-09-22 04:19:14 UTC
Not really. Since comment #8 haven't received any feedback (positive or
negative) for about 10 days, I take the silence as approval. 

Anyway, judging after comments at the beggining of linux-info.eclass, the actual
maintainer is johnm, not kernel herd.
Comment 24 Henrik Brix Andersen 2005-09-22 04:24:46 UTC
johnm being the kernel herd lead, yes.
Comment 25 John Mylchreest (RETIRED) gentoo-dev 2005-09-22 04:27:43 UTC
(In reply to comment #16)
> Objection here for the reasons stated in the email thread on -dev, summarized
> This won't work for releases as it'll make it into stages and stage building
> doesn't support per-package environments.

Just trying to work out exactly what you mean here.
Do you setting an environment variable in the build scripts wont work for you?
It isnt per-package.
Comment 26 John Mylchreest (RETIRED) gentoo-dev 2005-09-22 04:30:20 UTC
(In reply to comment #21)
> if no one want to solve this bug, I will.
> in about 8 hours I will submit a new linux-info.

No you won't.
I heavily object to anyone comitting any changes to the tree, regardless how
trivial if the actual maintainer of said code is active and working.
Comment 27 John Mylchreest (RETIRED) gentoo-dev 2005-09-22 04:41:04 UTC
Let me just re-itterate a point here.
What were discussing is the general use of CONFIG_CHECK.

CONFIG_CHECK in general, as described in the eclass is a way of ensuring some
kernel option which *must* exist, or not exist is correct.
*generally* speaking, it should die. if its not finding kernel-sources
correctly, then specify KERNEL_DIR, if there are no kernel sources, we cant
ensure a sane environment. Makes sense to me. And it also makes sense to allow
an over-ride for those people who really refuse for it to work like this (Cant
find any real scenario where it shouldn't)

So.. lets assume the more delicate things like CONFIG_PPP and pppd *shouldn't*
die. Fine, OK. Then why not get the maintainer to move the check into the
appropriate phase and call linux_chkconfig_present() directly?

Anyways.. I still feel the actual solution was as previously mentioned, an
override envvar, and I hope releng and I can find that solution. Afterall, if
releng and the build scripts work, then there is no other scenario I can think
of which shouldn't either.
Comment 28 John Mylchreest (RETIRED) gentoo-dev 2005-09-22 05:09:18 UTC
I've just spoken with Henrik and I think I see where the problem is with what im
saying and how its perceived.

Userland tools are using CONFIG_CHECK as a way to tella user that the tool wont
work without this option. This is wrong because it isnt actually building
against something in the destination kernel. It should be building against
for a userspace tool to need to know an option about the destination kernel, it
will be purely informational. So deal with it in the ebuild specifically and
dont use CONFIG_CHECK.

Somethign which genuinely relies on headers for the destination kernel will
actually want to die if it cant find them, because otherwise it wont work
anyways. Thats when you SHOULD use CONFIG_CHECK.

Anything more specific than this, please get in touch with me direct and I'll
Comment 29 John Mylchreest (RETIRED) gentoo-dev 2005-09-22 06:47:43 UTC
so after a long discussion ensuring what is right and what is wrong, a solution
has been made.
Let me confirm whats right and whats wrong.

Fatal checks are RIGHT when the package requires target-kernel headers based on
config options to build.
Fatal checks are WRONG when the package requires kernel options to run.

anything which doesnt need to build against ${KERNEL_DIR} does *NOT* need fatal
checks. Historically, this should not use CONFIG_CHECK.
CONFIG_CHECK was assumed for modules, and userland could simply just use the
chkconfig functions.

For convenience, CONFIG_CHECK now accepts a ~ flag for options. so a negative
option is: !~foo and a normal option is ~foo.
This means that it will check it, and it will throw a warning, but it will not
die. Instead it displays a checklist.

This is purely informational.
BY the way, these changes are going to go into cvs shortly after I have finished
Comment 30 SpanKY gentoo-dev 2005-09-22 13:01:24 UTC
thanks dear, greatly appreciated