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)
I really fail to see the logic of this. Please see my comments on bug #103396 and bug #103877.
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.
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)
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 ...
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 messages).
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.*
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.
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) or 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?
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.
also to note... I cant see this being normal behaviour. I wouldn't encourage this for any specific package in portage.
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.
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 http://thread.gmane.org/gmane.linux.gentoo.devel/31679
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.
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.
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?
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.
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; }
(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).
ok, maybe this version will do: linux-info_pkg_postinst() { get_version && [ -n "${CONFIG_WARN}" ] && warn_extra_config; }
oh, another mistake :( linux-info_pkg_postinst() { get_version && [ -n "${CONFIG_WARN}" ] && warn_extra_config return 0 }
if no one want to solve this bug, I will. in about 8 hours I will submit a new linux-info.
By "submit" I trust it you mean attach a proposed patch to this bug report for reviewing by the kernel herd?
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.
johnm being the kernel herd lead, yes.
(In reply to comment #16) > 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. 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.
(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.
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.
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 linux-headers. 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 clarify.
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 testing.
thanks dear, greatly appreciated