Il 22/01/2013 04:38, Robin H. Johnson ha scritto:
I'm raising this patch because of the recent spate of bugs with the
latest udev that now fails to boot your system if CONFIG_DEVTMPFS is
not available in your kernel.
Bugs: 408947, 409393, 437320, 453074
CONFIG_CHECK has not been fatal for some years now, because there turned
out to be some cases where it cannot detect what the system really has
[1], or what is returned is wrong [2].
However, while this is has been superb in helping those corner-cases,
the fallout is that users frequently ignore the non-fatal warnings that
a configuration option is needed to run a binary later, and end up with
weird breakage.
This patch introduces a new option, CONFIG_CHECK_FATAL, defaulting to
enabled, that explicitly causes a die if:
- CONFIG_CHECK cannot be performed successfully.
- Any CONFIG_CHECK options fail.
For the aforementioned corner cases, those environments are used to
customizing their make.conf heavily, and they should add:
CONFIG_CHECK_FATAL=0
This patch does NOT change the handling of ~/tilde in CONFIG_CHECK
- options that are required at compile-time MUST NOT use ~/tilde.
- options that are only required at run-time MUST include the ~/tilde.
Footnotes:
1. If you are using a VM environment, where the kernel is provided
outside of your VM, and you don't have kernel sources, or
/proc/config.gz, you CANNOT detect what options the kernel is
configured with.
2. Building stages for example. You may have /proc bind-mounted from the
host system, but it does not reflect the environment you are building
for.
IMHO the number of cases where CONFIG_CHECK is reliable is so small that
making it fatal will only bloat make.conf and env with a new var for
most users.
However this move could make sense if (and only if) CONFIG_CHECK could
reliabily know where it's used.
It could be made fatal for example if all the following conditions are met:
- buildpkg is disabled
- /proc/config.gz (decompressed) is the same as
${KERNEL_BUILD_DIR}/.config and both exists
- /boot is mounted and the bootloader will load the currently running kernel
AIMHO it's very difficult (would say impossible) to implement this in a
cross package manager and reliable way.
So please don't
