[gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Robin H. Johnson]

[-- Attachment #1.1: Type: text/plain, Size: 1760 bytes --]

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.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

[-- Attachment #1.2: linux-info-config_check_fatal.patch --]
[-- Type: text/x-diff, Size: 1740 bytes --]

Index: linux-info.eclass
===================================================================
RCS file: /var/cvsroot/gentoo-x86/eclass/linux-info.eclass,v
retrieving revision 1.95
diff -p -u -r1.95 linux-info.eclass
--- linux-info.eclass	16 Jan 2013 14:29:01 -0000	1.95
+++ linux-info.eclass	22 Jan 2013 03:23:59 -0000
@@ -57,6 +57,16 @@
 # This is to allow usage of binary kernels, and minimal systems without kernel
 # sources.
 
+# @ECLASS-VARIABLE: CONFIG_CHECK_FATAL
+# @DESCRIPTION:
+# Make failure of CONFIG_CHECK fatal.
+#
+# Enabled by default to save users.
+#
+# If you use a binary kernel, a minimal system without kernel sources, or any
+# system where checking config is no possible, you must disable this.
+[[ ${CONFIG_CHECK_FATAL+set} == set ]] || CONFIG_CHECK_FATAL=1
+
 # @ECLASS-VARIABLE: ERROR_<CFG>
 # @DESCRIPTION:
 # A string containing the error message to display when the check against CONFIG_CHECK
@@ -701,6 +711,8 @@ check_extra_config() {
 				fi
 				ewarn " - ${config#\~}${msg:+ - }${msg}"
 			done
+			[[ ${CONFIG_CHECK_FATAL} == 1 ]] && \
+				die "Cannot check kernel config per CONFIG_CHECK_FATAL."
 			ewarn "You're on your own to make sure they are set if needed."
 			export LINUX_CONFIG_EXISTS_DONE="${old_LINUX_CONFIG_EXISTS_DONE}"
 			return 0
@@ -784,7 +796,7 @@ check_extra_config() {
 		fi
 	done
 
-	if [[ ${hard_errors_count} > 0 ]]; then
+	if [[ ${hard_errors_count} > 0 ]] || [[ ${CONFIG_CHECK_FATAL} == 1 ]] && [[ ${soft_errors_count} > 0 ]]; then
 		eerror "Please check to make sure these options are set correctly."
 		eerror "Failure to do so may cause unexpected problems."
 		eerror "Once you have satisfied these options, please try merging"

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 330 bytes --]

Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Mike Gilbert]

[-- Attachment #1: Type: text/plain, Size: 2082 bytes --]

On 01/21/2013 10:38 PM, Robin H. Johnson wrote:
> 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.
> 

How does this variable interact with binpkgs?

For example, if I build a package on a system that does not have
CONFIG_CHECK_FATAL=0, what happens if I try to install it on a system
that does not have a usable kernel config?

My suspicion is that portage's environment save/restore process will
overwrite any setting I attempt to make on the destination host.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Zac Medico]

On 01/21/2013 07:45 PM, Mike Gilbert wrote:
> My suspicion is that portage's environment save/restore process will
> overwrite any setting I attempt to make on the destination host.

If necessary, you can use /etc/portage/bashrc to override
CONFIG_CHECK_FATAL for binary packages. Something like this would work:

  [[ ${EMERGE_FROM} == binary ]] && CONFIG_CHECK_FATAL=0
-- 
Thanks,
Zac

Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/21/2013 10:56 PM, Zac Medico wrote:
> On 01/21/2013 07:45 PM, Mike Gilbert wrote:
>> My suspicion is that portage's environment save/restore process will
>> overwrite any setting I attempt to make on the destination host.
> 
> If necessary, you can use /etc/portage/bashrc to override
> CONFIG_CHECK_FATAL for binary packages. Something like this would work:
> 
>   [[ ${EMERGE_FROM} == binary ]] && CONFIG_CHECK_FATAL=0
> 

does this means I need to start adding "export CONFIG_CHECK_FATAL=0" to
my catalystrc?

- -Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJQ/hFJAAoJEKXdFCfdEflK53UP/3Ngz3yBmkPz6E7sBZhjnJiW
CVaRlXvXs3sSn9zWdAxxVn1Z2z3RP387eb7jEXOoUAyIezwVfBLZIfPXUK8KN8rD
LRSntTv3E1AUpE+N0GlxRGVlKYnDf3g+EAi0M6iEjtcVBxsCNiH+UcmwHvPFp/oN
R4n79qD3jWEMMnm708RqkwKKu+/F4wfpUQe66UhAwd4yFDkndl/lwrtwmgztMjtF
W6V6Z1ZkWg0r0rRTxhuAYwMcYFKunfSzNCnaD72z0d184fwxcSw2N697vAPCXiLp
MbjCENLME3+dk088YvjNoZCCcga+9omsIKDG/gkgTJib4Ibrc028Ut0G1Oyxrx+R
6LzES1GRshlx0W9N+b+CmChffWfaGENXx2sSM5W6yD6eJtxGPw736JxGMQcpSltz
G+z+tLwDbx1rvHDBeAWzSU0k+W6Yx/QJ4L5D1LNaA/S3pEXwU6aK2ipoRpiNrJfC
aRWyJx1KGLF+vhrN70SiFASJyotmQwoFipgHjm5QbBiHn8sK0cq3gf9wb3nLRNoD
Ym7u9plg85y/W1Gme09vqlptMzwymIrCmXQHuBeqwILJ+lsVQBa1rL/0fnMyDftX
GLT35hIWM7OVUufuiKB6xiOLH0h/P9w45wUZBiPzldphd5wYr3TMkZFv4C8Qgc1/
1/h2B65Lw5wfF5SEuVo7
=oVpV
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Zac Medico]

On 01/21/2013 08:10 PM, Rick "Zero_Chaos" Farina wrote:
> On 01/21/2013 10:56 PM, Zac Medico wrote:
>> On 01/21/2013 07:45 PM, Mike Gilbert wrote:
>>> My suspicion is that portage's environment save/restore process will
>>> overwrite any setting I attempt to make on the destination host.
> 
>> If necessary, you can use /etc/portage/bashrc to override
>> CONFIG_CHECK_FATAL for binary packages. Something like this would work:
> 
>>   [[ ${EMERGE_FROM} == binary ]] && CONFIG_CHECK_FATAL=0
> 
> 
> does this means I need to start adding "export CONFIG_CHECK_FATAL=0" to
> my catalystrc?

I guess so, if you don't want those fatal config checks to kill your
catalyst builds.
-- 
Thanks,
Zac

Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Markos Chandras]

On 22 January 2013 03:56, Zac Medico <zmedico@gentoo.org> wrote:
> On 01/21/2013 07:45 PM, Mike Gilbert wrote:
>> My suspicion is that portage's environment save/restore process will
>> overwrite any setting I attempt to make on the destination host.
>
> If necessary, you can use /etc/portage/bashrc to override
> CONFIG_CHECK_FATAL for binary packages. Something like this would work:
>
>   [[ ${EMERGE_FROM} == binary ]] && CONFIG_CHECK_FATAL=0
> --
> Thanks,
> Zac
>

I guess the problem is when you create a binpkg and not when you
install it on the target. <wild idea> Would it be possible to make
this nonfatal if FEATURES contains "binpkg" or -B was passed to
emerge?</wild idea>

-- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2

Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Zac Medico]

On 01/22/2013 01:22 AM, Markos Chandras wrote:
> On 22 January 2013 03:56, Zac Medico <zmedico@gentoo.org> wrote:
>> On 01/21/2013 07:45 PM, Mike Gilbert wrote:
>>> My suspicion is that portage's environment save/restore process will
>>> overwrite any setting I attempt to make on the destination host.
>>
>> If necessary, you can use /etc/portage/bashrc to override
>> CONFIG_CHECK_FATAL for binary packages. Something like this would work:
>>
>>   [[ ${EMERGE_FROM} == binary ]] && CONFIG_CHECK_FATAL=0
>> --
>> Thanks,
>> Zac
>>
> 
> I guess the problem is when you create a binpkg and not when you
> install it on the target. <wild idea> Would it be possible to make
> this nonfatal if FEATURES contains "binpkg" or -B was passed to
> emerge?</wild idea>

The closest thing that PMS has defined is the MERGE_TYPE variable, which
is supported since EAPI 4. This variable has 3 possible values: source,
buildonly, or binary. Ebuilds can detect emerge --buildpkgonly by
checking for [[ ${MERGE_TYPE} == buildonly ]]. However, for normal
--buildpkg or FEATURES="buildpkg", the MERGE_TYPE is "source".
-- 
Thanks,
Zac

Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Mike Gilbert]

[-- Attachment #1: Type: text/plain, Size: 1026 bytes --]

On 01/21/2013 10:38 PM, Robin H. Johnson wrote:
> 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.
> 

Technical issues aside, I'm conflicted on this. In general, I don't
believe in protecting people from shooting themselves. However, I also
know how easy it is to ignore elog messages.

I guess this change is ok, given that I can opt-out fairly easily. Zac's
workaround for binary packages makes me feel better too.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Sergey Popov]

[-- Attachment #1: Type: text/plain, Size: 377 bytes --]

22.01.2013 08:23, Mike Gilbert wrote:
> I guess this change is ok, given that I can opt-out fairly easily. Zac's
> workaround for binary packages makes me feel better too.

I am curious, can not this check be added to eclass? Or eclass does not
know about type of merged package?

-- 
Best regards, Sergey Popov
Gentoo Linux Developer
Desktop-effects project lead


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 554 bytes --]

[gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Duncan]

Sergey Popov posted on Tue, 22 Jan 2013 10:22:34 +0400 as excerpted:

> 22.01.2013 08:23, Mike Gilbert wrote:
>> I guess this change is ok, given that I can opt-out fairly easily.
>> Zac's workaround for binary packages makes me feel better too.
> 
> I am curious, can not this check be added to eclass? Or eclass does not
> know about type of merged package?

AFAIK, binpkgs are a PM-specific feature that isn't managed by PMS.  As 
such, eclasses and ebuilds officially must remain binpkg agnostic, 
leaving all such handling to the PMs themselves.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Zac Medico]

On 01/21/2013 10:22 PM, Sergey Popov wrote:
> 22.01.2013 08:23, Mike Gilbert wrote:
>> I guess this change is ok, given that I can opt-out fairly easily. Zac's
>> workaround for binary packages makes me feel better too.
> 
> I am curious, can not this check be added to eclass? Or eclass does not
> know about type of merged package?

Since EAPI 4 we have the MERGE_TYPE variable which has 3 possible
values: source, buildonly, or binary.
-- 
Thanks,
Zac

Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Robin H. Johnson]

On Tue, Jan 22, 2013 at 06:51:54AM -0800, Zac Medico wrote:
> On 01/21/2013 10:22 PM, Sergey Popov wrote:
> > 22.01.2013 08:23, Mike Gilbert wrote:
> >> I guess this change is ok, given that I can opt-out fairly easily. Zac's
> >> workaround for binary packages makes me feel better too.
> > 
> > I am curious, can not this check be added to eclass? Or eclass does not
> > know about type of merged package?
> 
> Since EAPI 4 we have the MERGE_TYPE variable which has 3 possible
> values: source, buildonly, or binary.
# MERGE_TYPE = EAPI 4+                           
# EMERGE_FROM = EAPI 0-3
_frombin=${MERGE_TYPE}${EMERGE_FROM}
[[ ${_frombin//binary} == ${_frombin} ]] && [[ ${CONFIG_CHECK_FATAL+set} == set ]] || CONFIG_CHECK_FATAL=1

But probably easier to just set it in bashrc/catalystrc/make.conf

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Fabio Erculiani]

I hope this is going to be binary package manager friendly.
In Sabayon for instance, kernel sources are not even installed and at
the same time, /proc/config.gz may not even be available.
There were some corner cases in where pkg_setup failed because this
kernel config check stuff was trying to be "smarter" than the user.

-- 
Fabio Erculiani

Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Rich Freeman]

On Wed, Jan 23, 2013 at 7:32 AM, Fabio Erculiani <lxnay@gentoo.org> wrote:
> I hope this is going to be binary package manager friendly.
> In Sabayon for instance, kernel sources are not even installed and at
> the same time, /proc/config.gz may not even be available.
> There were some corner cases in where pkg_setup failed because this
> kernel config check stuff was trying to be "smarter" than the user.

Another issue with this sort of thing is that the kernel in
/usr/src/linux might not be the kernel that is running, and the kernel
that is running might not be the kernel that is running upon the next
boot.

I think warnings just make sense, but if we're going to make them
fatal then at least print out instructions on how to disable them.  I
suspect that a large number of users will end up disabling config
checks though, in which case this feature will provide a false sense
of security.

If an upgrade could make a user's system unbootable then we should
really be warning them about it BEFORE they merge the package.  A news
item before the change is committed to portage would be more
appropriate.  I don't want a fatal error during pkg_setup that isn't
fatal for 90% of our users because of all the false alarms to be an
excuse for developers to put the blame on the user.  That amounts to
telling our users that if they don't enable some make.conf option then
half of the Gentoo devs will cause their builds to break randomly, and
if they do enable it the other half of the Gentoo devs will cause
their systems to not boot.

Rich

Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Fabio Erculiani]

I think that the problem is that it is trying to be smart when it's
not really possible (unless you want to cover all the corner cases,
which is a pain).

-- 
Fabio Erculiani

Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Francesco Riosa]

[-- Attachment #1: Type: text/plain, Size: 460 bytes --]

2013/1/23 Fabio Erculiani <lxnay@gentoo.org>

> I think that the problem is that it is trying to be smart when it's
> not really possible (unless you want to cover all the corner cases,
> which is a pain).
>
>
> Hum, but if we could not be smart enough we can at least try to be very
annoying.
what about a delay of some seconds, exactly like `emerge -C portage` or
something very similar?
Trying to cover the corner cases but without pretend to be omniscent?

[-- Attachment #2: Type: text/html, Size: 863 bytes --]

Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Robin H. Johnson]

On Wed, Jan 23, 2013 at 12:32:40PM +0000, Fabio Erculiani wrote:
> I hope this is going to be binary package manager friendly.
> In Sabayon for instance, kernel sources are not even installed and at
> the same time, /proc/config.gz may not even be available.
> There were some corner cases in where pkg_setup failed because this
> kernel config check stuff was trying to be "smarter" than the user.
That was before we made it possible to have CONFIG_CHECK="~FOO" without
/proc/config.gz, for the bugs you yourself submitted, and I fixed years
ago.

I would expect that ALL Sabayon users would have CONFIG_CHECK_FATAL=0,
because they run your kernel (if you have your kernel in a package,
maybe even distribute a file that triggers it, so anybody else with
their own kernel still has the default CONFIG_CHECK_FATAL=1).

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Fabio Erculiani]

On Thu, Jan 24, 2013 at 1:10 AM, Robin H. Johnson <robbat2@gentoo.org> wrote:
> On Wed, Jan 23, 2013 at 12:32:40PM +0000, Fabio Erculiani wrote:
>> I hope this is going to be binary package manager friendly.
>> In Sabayon for instance, kernel sources are not even installed and at
>> the same time, /proc/config.gz may not even be available.
>> There were some corner cases in where pkg_setup failed because this
>> kernel config check stuff was trying to be "smarter" than the user.
> That was before we made it possible to have CONFIG_CHECK="~FOO" without
> /proc/config.gz, for the bugs you yourself submitted, and I fixed years
> ago.
>
> I would expect that ALL Sabayon users would have CONFIG_CHECK_FATAL=0,
> because they run your kernel (if you have your kernel in a package,
> maybe even distribute a file that triggers it, so anybody else with
> their own kernel still has the default CONFIG_CHECK_FATAL=1).

But we cannot assume that the environment in where packages are built
is the same as the environment in where packages are installed and
run.

>
> --
> Robin Hugh Johnson
> Gentoo Linux: Developer, Trustee & Infrastructure Lead
> E-Mail     : robbat2@gentoo.org
> GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
>



-- 
Fabio Erculiani

Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[vivo75]

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

Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Rich Freeman]

On Tue, Jan 22, 2013 at 6:11 AM, vivo75@gmail.com <vivo75@gmail.com> wrote:
> 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.

Tend to agree.  I just got an elog out of udisks complaining about
USB_SUSPEND not being set, and I have no idea why I'd need that on a
system that is powered 24x7.  Even the kernel docs suggest that it
should be disabled if users aren't sure if they need it.

Maybe we need some way to distinguish between must-have and
nice-to-have situations?  Clearly failure to boot is in a different
category than not-able-to-suspend.

Rich

Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Dustin C. Hatch]

On 1/22/2013 05:56, Rich Freeman wrote:
> On Tue, Jan 22, 2013 at 6:11 AM, vivo75@gmail.com <vivo75@gmail.com> wrote:
>> 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.
>
> Tend to agree.  I just got an elog out of udisks complaining about
> USB_SUSPEND not being set, and I have no idea why I'd need that on a
> system that is powered 24x7.  Even the kernel docs suggest that it
> should be disabled if users aren't sure if they need it.
>
> Maybe we need some way to distinguish between must-have and
> nice-to-have situations?  Clearly failure to boot is in a different
> category than not-able-to-suspend.
>
> Rich
>
I agree. During an update recently, I noticed that qemu complains if 
KVM_INTEL isn't set on an AMD CPU. Making this fatal would be stupid, 
but then nobody who runs qemu-kvm would ever get a fatal error about 
missing DEVTMPFS.

-- 
♫Dustin

[gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Duncan]

Rich Freeman posted on Tue, 22 Jan 2013 06:56:08 -0500 as excerpted:


> I just got an elog out of udisks complaining about
> USB_SUSPEND not being set, and I have no idea why I'd need that on a
> system that is powered 24x7.  Even the kernel docs suggest that it
> should be disabled if users aren't sure if they need it.

FWIW, that's for runtime power management.  Even a wall-powered system 
that's always running can shutdown unused USB devices when they're not 
needed, saving power at the incremental level, anyway.

However, that is a rather newer feature, and may cause issues with USB 
wakeup on obscure or older (say USB-1.x generation) hardware, thus the 
kernel help recommendation for that option.

That said, presumably udisks would choose not to make its check fatal, 
altho changing the default to fatal could complicate things for existing 
ebuilds until they're fixed.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Rich Freeman]

On Thu, Jan 24, 2013 at 12:49 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> That said, presumably udisks would choose not to make its check fatal,
> altho changing the default to fatal could complicate things for existing
> ebuilds until they're fixed.

That was basically my whole point - it can't be one-size-fits-all.
Honestly, based on some of the other feedback I'm not convinced it
should ever be fatal.  Perhaps it should be more or less noisy.

Keep in mind that a typical user may be running parallel builds and
such - so a delay doesn't really make much sense there either.  There
should also be some way to kill any interactivity in advance - if I'm
running a bootstrap script of some kind and I'm installing/updating
udev before I even compile a kernel that shouldn't cause the whole
process to die.

Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 24/01/13 01:09 PM, Rich Freeman wrote:
> On Thu, Jan 24, 2013 at 12:49 PM, Duncan <1i5t5.duncan@cox.net>
> wrote:
>> That said, presumably udisks would choose not to make its check
>> fatal, altho changing the default to fatal could complicate
>> things for existing ebuilds until they're fixed.
> 
> That was basically my whole point - it can't be one-size-fits-all. 
> Honestly, based on some of the other feedback I'm not convinced it 
> should ever be fatal.  Perhaps it should be more or less noisy.
> 
> Keep in mind that a typical user may be running parallel builds
> and such - so a delay doesn't really make much sense there either.
> There should also be some way to kill any interactivity in advance
> - if I'm running a bootstrap script of some kind and I'm
> installing/updating udev before I even compile a kernel that
> shouldn't cause the whole process to die.
> 

a fatal die in pkg_pretend could be circumvented by an environment
variable such as ${PN}_I_KNOW_WHAT_IM_DOING being set.  Just a thought.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlEBewoACgkQ2ugaI38ACPA5fQEAucffX2nqeFvlE+WTdY9xbWTY
zDiKIRofsFlsgSOscOMA/3iqGLolGVDlYR3YyLfform8udhz1deAYSyA4tabq4zH
=ky38
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Dustin C. Hatch]

On 1/24/2013 12:18, Ian Stakenvicius wrote:
> On 24/01/13 01:09 PM, Rich Freeman wrote:
>> On Thu, Jan 24, 2013 at 12:49 PM, Duncan <1i5t5.duncan@cox.net>
>> wrote:
>>> That said, presumably udisks would choose not to make its check
>>> fatal, altho changing the default to fatal could complicate
>>> things for existing ebuilds until they're fixed.
>>
>> That was basically my whole point - it can't be one-size-fits-all.
>> Honestly, based on some of the other feedback I'm not convinced it
>> should ever be fatal.  Perhaps it should be more or less noisy.
>>
>> Keep in mind that a typical user may be running parallel builds
>> and such - so a delay doesn't really make much sense there either.
>> There should also be some way to kill any interactivity in advance
>> - if I'm running a bootstrap script of some kind and I'm
>> installing/updating udev before I even compile a kernel that
>> shouldn't cause the whole process to die.
>>
>
> a fatal die in pkg_pretend could be circumvented by an environment
> variable such as ${PN}_I_KNOW_WHAT_IM_DOING being set.  Just a thought.
>
People keep quoting, on this list and on gentoo-user, that Gentoo is not 
a "hand holding" distribution. Having to set I_KNOW_WHAT_IM_DOING=1 sure 
seems to me like I'm telling my dad I don't need him to hold my hand to 
cross the street anymore, I'm a big boy. It seems like an added step 
that isn't necessary. If users are not reading the messages they're 
receiving and it breaks their systems, why should that make extra work 
for those of us who do pay attention?

-- 
♫Dustin

Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Rich Freeman]

On Thu, Jan 24, 2013 at 1:18 PM, Ian Stakenvicius <axs@gentoo.org> wrote:
> a fatal die in pkg_pretend could be circumvented by an environment
> variable such as ${PN}_I_KNOW_WHAT_IM_DOING being set.  Just a thought.

If we're going to do this I'd definitely have the ${PN} bit as you
suggested.  Otherwise everybody will just set it in make.conf and the
feature will be pointless.  Then we'll yell at users because they
disabled the feature that normally just tends to break half their
builds but this time by some miracle would have actually prevented a
problem.

Rich

Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Michael Orlitzky]

On 01/24/13 13:25, Rich Freeman wrote:
> On Thu, Jan 24, 2013 at 1:18 PM, Ian Stakenvicius <axs@gentoo.org> wrote:
>> a fatal die in pkg_pretend could be circumvented by an environment
>> variable such as ${PN}_I_KNOW_WHAT_IM_DOING being set.  Just a thought.
> 
> If we're going to do this I'd definitely have the ${PN} bit as you
> suggested.  Otherwise everybody will just set it in make.conf and the
> feature will be pointless.  Then we'll yell at users because they
> disabled the feature that normally just tends to break half their
> builds but this time by some miracle would have actually prevented a
> problem.

Are there really that many ways that this could cause false positives?
(Not that I'm against the $PN prefix, just curious).

I've only seen two legitimate examples: catalyst (whose developers are
more than capable of setting a variable) and a supervisor-provided
kernel for which you have no information.

Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 24/01/13 01:55 PM, Michael Orlitzky wrote:
> On 01/24/13 13:25, Rich Freeman wrote:
>> On Thu, Jan 24, 2013 at 1:18 PM, Ian Stakenvicius
>> <axs@gentoo.org> wrote:
>>> a fatal die in pkg_pretend could be circumvented by an
>>> environment variable such as ${PN}_I_KNOW_WHAT_IM_DOING being
>>> set.  Just a thought.
>> 
>> If we're going to do this I'd definitely have the ${PN} bit as
>> you suggested.  Otherwise everybody will just set it in make.conf
>> and the feature will be pointless.  Then we'll yell at users
>> because they disabled the feature that normally just tends to
>> break half their builds but this time by some miracle would have
>> actually prevented a problem.
> 
> Are there really that many ways that this could cause false
> positives? (Not that I'm against the $PN prefix, just curious).
> 
> I've only seen two legitimate examples: catalyst (whose developers
> are more than capable of setting a variable) and a
> supervisor-provided kernel for which you have no information.
> 

How about, you know what you're doing and are going to build a new
kernel as soon as the emerge finishes (since the emerge is also
bringing in a new gentoo-sources)??


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlEBhEsACgkQ2ugaI38ACPDYHAD/RCYlN6hcItJYn/gCcEdEgh+C
owE/NaeGNDiH+3H/+uAA/jRfeJ+HPxDLdGNxt/VARcrqYnA15o6SmAiHOIj4i8Au
=FTEj
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Rich Freeman]

On Thu, Jan 24, 2013 at 1:58 PM, Ian Stakenvicius <axs@gentoo.org> wrote:
> How about, you know what you're doing and are going to build a new
> kernel as soon as the emerge finishes (since the emerge is also
> bringing in a new gentoo-sources)??

Or my earlier example - USB_SUSPEND and such.  If there end up being
lots of config checks that are fatal then users will inevitably end up
overriding them, and then they'll get burned when the check really
matters.

I think the better option in any case is to use a news item when
things change so that users can actually plan for the upcoming changes
and not find out in the middle of a build.  News can be targeted at
those who need to know, it shows up for users 5 years from now if
still relevant not if otherwise, and it only shows up once when it
matters.

Rich

Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Michael Orlitzky]

On 01/24/13 13:58, Ian Stakenvicius wrote:
> 
> 
> How about, you know what you're doing and are going to build a new
> kernel as soon as the emerge finishes (since the emerge is also
> bringing in a new gentoo-sources)??
> 

If you're going to upgrade both anyway, you should be upgrading the
kernel first. That way if you lose power or the system crashes, the box
can reboot.

Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[vivo75]

Il 24/01/2013 20:21, Michael Orlitzky ha scritto:
> On 01/24/13 13:58, Ian Stakenvicius wrote:
>>
>> How about, you know what you're doing and are going to build a new
>> kernel as soon as the emerge finishes (since the emerge is also
>> bringing in a new gentoo-sources)??
>>
> If you're going to upgrade both anyway, you should be upgrading the
> kernel first. That way if you lose power or the system crashes, the box
> can reboot.
>
which can be the exact opposite order if instead you have to _disable_ a 
feature in the kernel which would make udev not bootable.
Don't remember exactly what, but it happened in the past when Greg was 
still maintainer and an obsolete feature was making udev confused.

Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Michael Orlitzky]

On 01/24/13 15:26, vivo75@gmail.com wrote:
>> If you're going to upgrade both anyway, you should be upgrading the
>> kernel first. That way if you lose power or the system crashes, the box
>> can reboot.
>>
> which can be the exact opposite order if instead you have to _disable_ a
> feature in the kernel which would make udev not bootable.
> Don't remember exactly what, but it happened in the past when Greg was
> still maintainer and an obsolete feature was making udev confused.
> 

Suppose, you're on e.g. udev-1, and,

  * udev-2 requires CONFIG_FOO=n
  * udev-1 will not boot with CONFIG_FOO=y

Then it doesn't make much sense to die without CONFIG_FOO=n, because it
can't possibly exist. So we would warn with either a non-fatal config
check or news item. Hopefully we would also execute the person responsible.

Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Michael Orlitzky]

On 01/24/13 15:39, Michael Orlitzky wrote:
> On 01/24/13 15:26, vivo75@gmail.com wrote:
>>> If you're going to upgrade both anyway, you should be upgrading the
>>> kernel first. That way if you lose power or the system crashes, the box
>>> can reboot.
>>>
>> which can be the exact opposite order if instead you have to _disable_ a
>> feature in the kernel which would make udev not bootable.
>> Don't remember exactly what, but it happened in the past when Greg was
>> still maintainer and an obsolete feature was making udev confused.
>>
> 
> Suppose, you're on e.g. udev-1, and,
> 
>   * udev-2 requires CONFIG_FOO=n
>   * udev-1 will not boot with CONFIG_FOO=y

Sorry, that should be an 'n' instead of a 'y'. I started out with 'y'
and tried to switch to 'n' to match your example.

Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[vivo75]

Il 24/01/2013 21:45, Michael Orlitzky ha scritto:
> On 01/24/13 15:39, Michael Orlitzky wrote:
>> On 01/24/13 15:26, vivo75@gmail.com wrote:
>>>> If you're going to upgrade both anyway, you should be upgrading the
>>>> kernel first. That way if you lose power or the system crashes, the box
>>>> can reboot.
>>>>
>>> which can be the exact opposite order if instead you have to _disable_ a
>>> feature in the kernel which would make udev not bootable.
>>> Don't remember exactly what, but it happened in the past when Greg was
>>> still maintainer and an obsolete feature was making udev confused.
>>>
>> Suppose, you're on e.g. udev-1, and,
>>
>>    * udev-2 requires CONFIG_FOO=n
>>    * udev-1 will not boot with CONFIG_FOO=y
> Sorry, that should be an 'n' instead of a 'y'. I started out with 'y'
> and tried to switch to 'n' to match your example.
>
>
actually it wasn't an issue that could made a system un-bootable but was 
like this:

* udev-129 could live with CONFIG_SYSFS_DEPRECATED=y
* udev-130 require CONFIG_SYSFS_DEPRECATED not set

The example was given just to underline the fact that a different emerge 
order may be required.

cheers

Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Michael Orlitzky]

On 01/24/13 19:29, vivo75@gmail.com wrote:
> actually it wasn't an issue that could made a system un-bootable but was
> like this:
> 
> * udev-129 could live with CONFIG_SYSFS_DEPRECATED=y
> * udev-130 require CONFIG_SYSFS_DEPRECATED not set
> 
> The example was given just to underline the fact that a different emerge
> order may be required.
> 

So you upgrade the kernel (unsetting CONFIG_SYSFS_DEPRECATED), and then
upgrade udev (which would now pass the config check). Same situation?

Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Rich Freeman]

On Thu, Jan 24, 2013 at 2:21 PM, Michael Orlitzky <michael@orlitzky.com> wrote:
> On 01/24/13 13:58, Ian Stakenvicius wrote:
>>
>>
>> How about, you know what you're doing and are going to build a new
>> kernel as soon as the emerge finishes (since the emerge is also
>> bringing in a new gentoo-sources)??
>>
>
> If you're going to upgrade both anyway, you should be upgrading the
> kernel first. That way if you lose power or the system crashes, the box
> can reboot.

The problem is that we're trying to solve a very specific issue (a
udev upgrade, which already happened) with a general solution.

Whatever we come up with has to be override-able in a way that doesn't
then just come back to haunt them.

As far as what order you upgrade what in - in the case where I'd be
most likely to run into this the system wouldn't be bootable before I
upgrade, or after I upgrade.  I'd tend to run into this issue when
building a new system from a stage3 - just dump a bunch of stuff in
@world (including a kernel) and then run an emerge -uDN world followed
by building a kernel.

Yes, this isn't a typical case, and neither are the 10 billion other
cases where config checks break.  However, typical users don't run
Gentoo to begin with.  Everybody has some odd case or another - so we
warn people of potential breakage before we break things and let them
use the brains they needed to get Gentoo working in the first place.

Rich

Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Fabio Erculiani]

I am starting to think that the real problem is that Gentoo does not
have ebuilds for building kernels (binary kernels). At that point, it
would be easy to add USE flags and virtual packages to solve the
config check problem at the dependencies level once and for all.

-- 
Fabio Erculiani

[gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Duncan]

Fabio Erculiani posted on Sat, 26 Jan 2013 10:34:25 +0000 as excerpted:

> I am starting to think that the real problem is that Gentoo does not
> have ebuilds for building kernels (binary kernels). At that point, it
> would be easy to add USE flags and virtual packages to solve the config
> check problem at the dependencies level once and for all.

Yes, but people think the number of USE flags and testing their 
combinations on php is bad and equery u php | wc says that's only about 
80.  Try about 500 (just picking a number out of the air, maybe it's 
5000...) USE flags, and you're getting closer to kernel territory.

While in theory it could be done with less, hardcoding "reasonable" 
defaults for many options and forcing module for most drivers, it's 
unlikely that many real gentooers would be particularly happy with that, 
for the same reasons they're using gentoo in the first place.

Of course, it /would/ be possible to simply ship the gentoo kernel ebuilds 
that way, and let those who want more handle their kernel using other 
means, as I and I suppose many already do.  But doing that would force 
some seriously complex package.provided hacks for those choosing that 
route, which would effectively get us back in the same spot we're in now, 
no reliable way to check, because half the userbase would be using those 
package.provided hacks.

I've said it before and I imagine I'll say it again.  Gentoo isn't a 
handholding distro and we can't make it one.  Do the warnings and 
RESOLVED/PEBKAC or whatever if people can't read them.  People will 
either learn to read, or they'll go elsewhere, and eventually it'll no 
longer be the sort of problem it is today, due to gentoo trying to market 
a handholding service it simply cannot deliver.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Fabio Erculiani]

What I always wondered is why we have ebuilds for every kind of binary
except for kernels, yet we build official kernels with official
configs for our livecds.

-- 
Fabio Erculiani

Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Rich Freeman]

On Sat, Jan 26, 2013 at 5:30 PM, Fabio Erculiani <lxnay@gentoo.org> wrote:
> What I always wondered is why we have ebuilds for every kind of binary
> except for kernels, yet we build official kernels with official
> configs for our livecds.

Yup.  I don't think the solution is to have a USE flag for every
kernel parameter, but having a standardized kernel with a few flags
probably isn't a bad idea.

However, since I'm sure we want to fully support user-built kernels I
don't really see that solving the config check problem.  You can't
just depend on the standardized kernel, unless you use a virtual and
make gentoo-sources something that fulfills it (which means users
going that route just don't get the check).  That still isn't a bad
solution - those who want the hand-holding version can just use the
canned kernel.

I would still suggest that if we went that route the kernel needs more
modules than present on our install CDs.  Nothing wrong with the
install CDs per-se - they're focused on doing installation, not
interfacing with webcams, IR remotes, or radios.

Rich

Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Peter Stuge]

Rich Freeman wrote:
> having a standardized kernel with a few flags probably isn't a bad idea.

That doesn't scale at all. Suggest instead take a .config as input to
the emerge, maybe something like savedconfig for busybox, and add
shortcuts for common options.

That way, the same mechanism can be used for arbitrarily complex
configurations too.


//Peter

Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Rich Freeman]

On Sat, Jan 26, 2013 at 7:31 PM, Peter Stuge <peter@stuge.se> wrote:
> Rich Freeman wrote:
>> having a standardized kernel with a few flags probably isn't a bad idea.
>
> That doesn't scale at all. Suggest instead take a .config as input to
> the emerge, maybe something like savedconfig for busybox, and add
> shortcuts for common options.
>
> That way, the same mechanism can be used for arbitrarily complex
> configurations too.

The intent would be to have all non-mutually-incompatible options
enabled as modules and an accompanying initramfs.  That's what every
single other distro does - it works reasonably well.  USE flags might
be used for any odd situations that can't be covered in this way
(though I can't think of any offhand - odd situations are probably
handled best with a manual build).

If you're just going to feed it a .config file then you might as well
use genkernel - the idea is to be bulletproof.  Just emerge the
package and run grub-install and you have a bootable system.

Rich

[gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Duncan]

Michael Orlitzky posted on Thu, 24 Jan 2013 13:55:46 -0500 as excerpted:

> On 01/24/13 13:25, Rich Freeman wrote:
>> On Thu, Jan 24, 2013 at 1:18 PM, Ian Stakenvicius <axs@gentoo.org>
>> wrote:
>>> a fatal die in pkg_pretend could be circumvented by an environment
>>> variable such as ${PN}_I_KNOW_WHAT_IM_DOING being set.  Just a
>>> thought.
>> 
>> If we're going to do this I'd definitely have the ${PN} bit as you
>> suggested.  Otherwise everybody will just set it in make.conf and the
>> feature will be pointless.  Then we'll yell at users because they
>> disabled the feature that normally just tends to break half their
>> builds but this time by some miracle would have actually prevented a
>> problem.
> 
> Are there really that many ways that this could cause false positives?
> (Not that I'm against the $PN prefix, just curious).

It's worth noting that for example, glibc uses I_KNOW_WHAT_I_AM_DOING to 
bypass its don't-break-the-system-by-downgrading-glibc check.

Unfortunately, due to environment saving and because I have 
FEATURES=buildpkg set, that means I have to set it at build-time, in 
ordered to have it in the glibc binpkg for the PREVIOUS version (the one 
I'd be downgrading to), in ordered to avoid a needless rebuild despite my 
having the binpkg I was JUST using until the upgrade and thus KNOW to be 
working, right at hand!

Now I've chosen to set that using package.env so it applies only to glibc, 
but I imagine many users have it set in their make.conf, because a lot of 
packages use it, and they were forced to set it for one or another at 
some point.

Thus, adding the package name to enforce per-package 
I_KNOW_WHAT_I_AM_DOING seems a good idea.

Or perhaps use the usual I_KNOW_WHAT_I_AM_DOING var, but instead of just 
checking that it's set, check that it's set to the specific package name.


Meanwhile, my vote is for a NON-FATAL pkg_pretend warning.  That gets run 
at the beginning when people are still likely to be watching, so should 
be good enough.  Beyond that, gentoo can't keep the obtuse from ignoring 
the warnings, so if it breaks they get to keep the pieces, and RESOLVED/
READTHEWARNINGS to any resulting bugs.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Robin H. Johnson]

On Fri, Jan 25, 2013 at 01:39:08AM +0000, Duncan wrote:
> Meanwhile, my vote is for a NON-FATAL pkg_pretend warning.  That gets run 
> at the beginning when people are still likely to be watching, so should 
> be good enough.  Beyond that, gentoo can't keep the obtuse from ignoring 
> the warnings, so if it breaks they get to keep the pieces, and RESOLVED/
> READTHEWARNINGS to any resulting bugs.
Ok, I'll see about implementing pkg_pretend in linux-info.eclass as
well.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Michael Orlitzky]

On 01/24/2013 08:39 PM, Duncan wrote:
> 
> Now I've chosen to set that using package.env so it applies only to glibc, 
> but I imagine many users have it set in their make.conf, because a lot of 
> packages use it, and they were forced to set it for one or another at 
> some point.

Using package.env is preferable, since it basically exists in lieu of
prefixing every environment variable with $PN. But I don't particularly
care about the details. I was just curious if there are real cases where
the config check would do harm.

If there's no downside (i.e. no one will notice, except the people whose
machines would be broken), then the whole debate is stupid.


> Thus, adding the package name to enforce per-package 
> I_KNOW_WHAT_I_AM_DOING seems a good idea.
> 
> Or perhaps use the usual I_KNOW_WHAT_I_AM_DOING var, but instead of just 
> checking that it's set, check that it's set to the specific package name.
> 
> 
> Meanwhile, my vote is for a NON-FATAL pkg_pretend warning.  That gets run 
> at the beginning when people are still likely to be watching, so should 
> be good enough.  Beyond that, gentoo can't keep the obtuse from ignoring 
> the warnings, so if it breaks they get to keep the pieces, and RESOLVED/
> READTHEWARNINGS to any resulting bugs.

They're not warnings, they're "we just broke your system, hope you
weren't doing anything tonight!" A boulder with WARNING: FALLING ROCKS
spray-painted on the bottom.

Better to spare the innocents, and for the people who set
I_KNOW_WHAT_I_AM_DOING=y in make.conf, we can create
RESOLVED:I_THOUGHT_YOU_KNEW.

Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Rich Freeman]

On Thu, Jan 24, 2013 at 9:22 PM, Michael Orlitzky <michael@orlitzky.com> wrote:
> Using package.env is preferable, since it basically exists in lieu of
> prefixing every environment variable with $PN. But I don't particularly
> care about the details. I was just curious if there are real cases where
> the config check would do harm.

A few have come up.  They mostly involve with building on systems
where the package won't be deployed, in things like chroots, during
things like upgrading stage3s before installing the kernel, and so on.
 The USB_SUSPEND case came up as well - things like that shouldn't be
fatal.

Does package.env support having more than one environment file per
package?  If somebody is already using package.env to tweak CFLAGs and
such then also using it for this flag means basically doubling the
number of configurations (ie having a debug-flags and
debug-flags-ikwiad file, and ditto for any other tweaks).

>
> If there's no downside (i.e. no one will notice, except the people whose
> machines would be broken), then the whole debate is stupid.
>

I don't think that we'd have a debate if there wasn't a sense that
people would notice.  The whole "your use case isn't the same as mine
thus it doesn't matter" thing gets old.  I don't expect devs to do a
lot of work to maintain corner cases, but in this case the desire is
to not make users patch ebuilds if they don't want to have them die
when nothing is wrong, and accomplishing this doesn't really cost
anybody time.

>
> Better to spare the innocents, and for the people who set
> I_KNOW_WHAT_I_AM_DOING=y in make.conf, we can create
> RESOLVED:I_THOUGHT_YOU_KNEW.
>

Remember, it isn't the skipped check that broke the system - it was
the package change that required the check in the first place.  If the
package just silently fails (even due to an override) then that is a
bad design.  It should at least give as many warnings as it does
presently (but non-fatally), and it should still be preceded with a
news item.

Otherwise we're just finding creative ways to drive away users.  Sure,
we can call them stupid on their way out the door, but while I can't
speak for anybody else, I'm mainly here because I'd like to do some
good, and I wouldn't mind it if I found Gentoo useful along the way.

I think what we need is a combination of:
1.  Only truly critical issues trigger fatal errors.  This can't be
used for default config checks.
2.  The fatal errors are overridable.
3.  If overriden the errors are still output.
4.  The error output includes instructions on how to override, and the
instructions are package-specific (ie don't stick i_know_what_im_doing
in make.conf).
5.  The change introducing the issue is preceded with a news item.

Honestly I think #5 is more important than having the check in the
first place.  Also, most of these can be handled at the eclass level -
the package should explain the issue, but all the
instructions/behavior can be generic (that is, generic instructions on
how to do the override in a package-specific way, such as through
package.env or whatever).

Rich

Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Michael Orlitzky]

On 01/24/2013 10:12 PM, Rich Freeman wrote:
> 
> Otherwise we're just finding creative ways to drive away users.  Sure,
> we can call them stupid on their way out the door, but while I can't
> speak for anybody else, I'm mainly here because I'd like to do some
> good, and I wouldn't mind it if I found Gentoo useful along the way.
> 
> I think what we need is a combination of:
> 1.  Only truly critical issues trigger fatal errors.  This can't be
> used for default config checks.
> 2.  The fatal errors are overridable.
> 3.  If overriden the errors are still output.
> 4.  The error output includes instructions on how to override, and the
> instructions are package-specific (ie don't stick i_know_what_im_doing
> in make.conf).
> 5.  The change introducing the issue is preceded with a news item.
> 

I completely agree with this, so I won't drag the issue out any further.

[gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Duncan]

Michael Orlitzky posted on Thu, 24 Jan 2013 21:22:10 -0500 as excerpted:

> On 01/24/2013 08:39 PM, Duncan wrote:
>> 
>> Meanwhile, my vote is for a NON-FATAL pkg_pretend warning.  That gets
>> run at the beginning when people are still likely to be watching, so
>> should be good enough.  Beyond that, gentoo can't keep the obtuse from
>> ignoring the warnings, so if it breaks they get to keep the pieces, and
>> RESOLVED/ READTHEWARNINGS to any resulting bugs.
> 
> They're not warnings, they're "we just broke your system, hope you
> weren't doing anything tonight!" A boulder with WARNING: FALLING ROCKS
> spray-painted on the bottom.

But a pkg_pretend warning would happen BEFORE the breakage, normally at
--pretend/--ask time, when people are still paying attention.  So it 
wouldn't be a boulder with the warning posted on the bottom, it would be 
a sign (which retaining the analogy, could be painted on the SIDE of a 
boulder) posted a kilometre ahead.

That's the purpose for which pkg_pretend was created, and AFAIK, the 
purpose for which it is used, tho there's a limitation on the EAPI it can 
be used with, since it didn't appear in early EAPIs.

> Better to spare the innocents, and for the people who set
> I_KNOW_WHAT_I_AM_DOING=y in make.conf, we can create
> RESOLVED:I_THOUGHT_YOU_KNEW.

The thing is, if we use it so much that most folks have that variable 
set, then we've defeated the purpose and just executed an exercise in 
futility.

That said, as should be plain from previous posts, I'm certainly of the 
opinion that once we have the warning, it's no longer our responsibility, 
and people who ignore it get to keep the pieces.  In fact, I'm on record 
as being of the opinon that if such a case were to happen reasonably 
early in their gentoo experience (as it did back in the day when 
baselayout shipped /etc/fstab and some people ended up learning the hard 
way to actually pay attention to etc-updates as a result), ultimately, 
we'd have fewer bugs of this sort, because people would quickly learn 
that they had /better/ pay attention... or find another distro if they 
weren't willing to do so!

So yes, RESOLVED/READTHEWARNINGS or the like could be a viable bug 
status, indeed. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Nuno J. Silva]

On 2013-01-22, Robin H. Johnson wrote:

> 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.

[...]

Is there any syntax to check if something is either disabled or built as
a module? One case where being fatal by default would be annoying and
perhaps wrong is net-wireless/broadcom-sta, where there is no problem in
having b43 and ssb as modules, as far as they are not loaded when you
want to use broadcom's binary driver.

(In fact, even if it is not fatal right now, the message ends up being a
bit misleading, because it *can* be set.)

-- 
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/

Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Rich Freeman]

On Fri, Jan 25, 2013 at 1:24 PM, Nuno J. Silva <nunojsilva@ist.utl.pt> wrote:
> Is there any syntax to check if something is either disabled or built as
> a module?

Very problematic.  What is built in for the currently running kernel
can be fairly reliably determined by grepping /proc/config.gz - IF
support for that was enabled in the kernel.  But, there is no
guarantee that this kernel will be running on the next boot.
Determining what is build as a module really requires interpreting the
contents of /lib/modules - a module could have been built after the
kernel was built, in which case /proc/config.gz might indicate no
support even though it is supported.  I don't think DEVTMPFS can be
made a module, however (not sure on that).

You can also check /usr/src/linux/.config, but the sources might not
correspond to the running kernel, or the kernel on the next reboot, or
whatever.

It really is a touchy situation, hence all the emails in the thread.
You can build something that will work OK 80% of the time though by
checking the source tree.

Part of me wonders if we should just ship a binary kernel/initramfs as
an option.  Then again, users could just use genkernel and get
something like that anyway.  My main issue with genkernel is that its
default options are focused more on the install CD than ordinary use -
things like tuners/multimedia/lirc and the like tend to not be
enabled.  I would think a typical desktop-oriented distro is going to
enable as a module anything that doesn't cause breakage.

Rich

Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Christopher Head]

On Fri, 25 Jan 2013 13:47:05 -0500
Rich Freeman <rich0@gentoo.org> wrote:

> Very problematic.  What is built in for the currently running kernel
> can be fairly reliably determined by grepping /proc/config.gz - IF
> support for that was enabled in the kernel.  But, there is no
> guarantee that this kernel will be running on the next boot.
> Determining what is build as a module really requires interpreting the
> contents of /lib/modules - a module could have been built after the
> kernel was built, in which case /proc/config.gz might indicate no
> support even though it is supported.  I don't think DEVTMPFS can be
> made a module, however (not sure on that).

Surely even that isn’t good enough, since the user could have built an
option as a module, tested it out, discovered it worked fine, and then
rebuilt the kernel with the option set to Y, but the .ko file would
still be left lying around?

Chris

Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Rich Freeman]

On Fri, Jan 25, 2013 at 2:19 PM, Christopher Head <chead@chead.ca> wrote:
> Surely even that isn’t good enough, since the user could have built an
> option as a module, tested it out, discovered it worked fine, and then
> rebuilt the kernel with the option set to Y, but the .ko file would
> still be left lying around?

Yup.  Until the day comes when we have a USE flag for every kernel
parameter (in both built-in and module form) and just have the ebuild
actually build and install the kernel, it is going to be messy.  The
kernel is a bit unique in that we just dump a pile of source on the
disk and ask the user to have at it.  Note that I'm by no means
advocating that we actually do any of that - the kernel is unusual in
that it is EXTREMELY configurable otherwise this is probably what
would have been done.

As I mentioned in my last email maybe having a kernel package that
does do exactly that for a desktop-oriented kernel with maybe only a
few USE options might not be a bad idea - perhaps even managing grub
config and all.  That could be something that would make life easier
on users who don't care to customize their kernels.

Rich

[gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Nuno J. Silva]

On 2013-01-25, Rich Freeman wrote:

> On Fri, Jan 25, 2013 at 1:24 PM, Nuno J. Silva <nunojsilva@ist.utl.pt> wrote:
>> Is there any syntax to check if something is either disabled or built as
>> a module?
>
> Very problematic.  What is built in for the currently running kernel
> can be fairly reliably determined by grepping /proc/config.gz - IF
> support for that was enabled in the kernel.  But, there is no
> guarantee that this kernel will be running on the next boot.
> Determining what is build as a module really requires interpreting the
> contents of /lib/modules - a module could have been built after the
> kernel was built, in which case /proc/config.gz might indicate no
> support even though it is supported.  I don't think DEVTMPFS can be
> made a module, however (not sure on that).

Sorry, what's the difference between cheching =y and =m? I thought those
were both part of the kernel config...

> You can also check /usr/src/linux/.config, but the sources might not
> correspond to the running kernel, or the kernel on the next reboot, or
> whatever.

Ok, what do these checks do right now? I thought that they were checking
.config...

So you're saying that it's perfectly OK to check for =y or =n, but that
it's somehow more difficult to check for =m?

> It really is a touchy situation, hence all the emails in the thread.
> You can build something that will work OK 80% of the time though by
> checking the source tree.

I am not taking about introducing a different way to check, just asking
if there is a way to make the broadcom-sta check a bit more realistic.

> Part of me wonders if we should just ship a binary kernel/initramfs as
> an option.  Then again, users could just use genkernel and get
> something like that anyway.  My main issue with genkernel is that its
> default options are focused more on the install CD than ordinary use -
> things like tuners/multimedia/lirc and the like tend to not be
> enabled.  I would think a typical desktop-oriented distro is going to
> enable as a module anything that doesn't cause breakage.

This won't even solve the issue, even if some people may actually prefer
a pre-built kernel.

It would be a bit more realistic to perform checks against *all* the
kernels under /usr/src/linux, in a non-fatal way, of course. This would
still generate lots of noise, but would produce a more useful output,
like:

| net-wireless/broadcom-sta - The following issues were found:
|
| Option CONFIG_B43 cannot be built-in, but was found to be built-in in
| the following kernels :
|
| - linux-2.6.30-gentoo-r5
| - linux-2.6.34-gentoo-r6
| - linux-3.2.1-gentoo-r2


Or maybe have a dedicated directory to store .config's portage should
check against, and check only against these.

But, definitely, fatal checks should not be a default, there are way too
many scenarios.

-- 
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/

Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Rich Freeman]

On Fri, Jan 25, 2013 at 2:47 PM, Nuno J. Silva <nunojsilva@ist.utl.pt> wrote:
>
> Sorry, what's the difference between cheching =y and =m? I thought those
> were both part of the kernel config...

I'm talking about /proc/config.gz, which only reflects .config at the
time that the kernel was built.  So, build with config=n, then set
config=m and install the modules but don't replace the kernel.  Now
/proc/config.gz still says n, but the module is there and works fine.
And this is in fact the easiest way to add a module for something that
you didn't realize you needed at kernel build time - you can do this
on a running system.

>
>> You can also check /usr/src/linux/.config, but the sources might not
>> correspond to the running kernel, or the kernel on the next reboot, or
>> whatever.
>
> Ok, what do these checks do right now? I thought that they were checking
> .config...

I dunno.  I wasn't talking about how the current config checks work.
The question was whether it was possible to determine how the kernel
was configured - I was answering in general.

>
> So you're saying that it's perfectly OK to check for =y or =n, but that
> it's somehow more difficult to check for =m?

My previous paragraph was referring to checking config.gz - and that
is unreliable for modules.  /usr/src/linux/.config is unreliable for
the reason I stated in the next paragraph - it doesn't necessarily
reflect the running kernel.

> This won't even solve the issue, even if some people may actually prefer
> a pre-built kernel.

Depends on the issue.  There isn't just one issue under discussion in
this thread.  A fairly bulletproof kernel solves a lot of issues in
general as it can have newbie-safe defaults (like just about anything
in any config check).  There is a reason that most distros don't need
config checks.

> But, definitely, fatal checks should not be a default, there are way too
> many scenarios.

Yup - just trying to point out some of the perils.  As I said there
are lots of 80% solutions.

Rich

[gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Nuno J. Silva]

On 2013-01-25, Rich Freeman wrote:

> On Fri, Jan 25, 2013 at 2:47 PM, Nuno J. Silva <nunojsilva@ist.utl.pt> wrote:
>>
>> Sorry, what's the difference between cheching =y and =m? I thought those
>> were both part of the kernel config...
>
> I'm talking about /proc/config.gz, which only reflects .config at the
> time that the kernel was built.  So, build with config=n, then set
> config=m and install the modules but don't replace the kernel.  Now
> /proc/config.gz still says n, but the module is there and works fine.
> And this is in fact the easiest way to add a module for something that
> you didn't realize you needed at kernel build time - you can do this
> on a running system.
>
>>
>>> You can also check /usr/src/linux/.config, but the sources might not
>>> correspond to the running kernel, or the kernel on the next reboot, or
>>> whatever.
>>
>> Ok, what do these checks do right now? I thought that they were checking
>> .config...
>
> I dunno.  I wasn't talking about how the current config checks work.
> The question was whether it was possible to determine how the kernel
> was configured - I was answering in general.

I am almost sure the current check does *not* use config.gz but
/usr/src/linux/.config. At least, I've not had config.gz enabled for a
long time, and I've always seen the checks working. In fact, I think the
checks print something along the lines of "looking for kernel source
under /usr/src/linux... found config for linux-...".

>> So you're saying that it's perfectly OK to check for =y or =n, but that
>> it's somehow more difficult to check for =m?
>
> My previous paragraph was referring to checking config.gz - and that
> is unreliable for modules.  /usr/src/linux/.config is unreliable for
> the reason I stated in the next paragraph - it doesn't necessarily
> reflect the running kernel.

Not only for modules, config.gz may not even be available, while
/usr/src/linux/.config is reliable, as it should exist, and, when you're
compiling, you're typically compiling for what is going to be your main
kernel, the one under /usr/src/linux, which, to have been built, must
have a .config, an.

And you do not want to check against the running kernel, you want to
check against the currently selected kernel. Checking /proc/config.gz
would lead to issues when you're in middle of a kernel update and
rebuilding modules before reboot.

>> This won't even solve the issue, even if some people may actually prefer
>> a pre-built kernel.
>
> Depends on the issue.  There isn't just one issue under discussion in
> this thread.  A fairly bulletproof kernel solves a lot of issues in
> general as it can have newbie-safe defaults (like just about anything
> in any config check).  There is a reason that most distros don't need
> config checks.

Well, we could also get rid of issues with clashing USE flags by getting
rid of USE flags and offering monolithic binary packages with almost
every compatible feature enabled by default.

And newbie-safe, I've had far too many systems where your usual binary
distro "newbie-safe" kernel fails and the first thing I need to do even
with binary distros is to build my own kernel to get something that
actually boots with no issues.

>> But, definitely, fatal checks should not be a default, there are way too
>> many scenarios.
>
> Yup - just trying to point out some of the perils.  As I said there
> are lots of 80% solutions.


-- 
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/

Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Rich Freeman]

On Fri, Jan 25, 2013 at 3:06 PM, Nuno J. Silva <nunojsilva@ist.utl.pt> wrote:
> Well, we could also get rid of issues with clashing USE flags by getting
> rid of USE flags and offering monolithic binary packages with almost
> every compatible feature enabled by default.

I'm not suggesting that we get rid of options - only that we have
simplified ones for those who don't need them.  You can get all the
benefits of Gentoo without tweaking every other kernel parameter.

That's no different from having a desktop profile/etc.  The value of
Gentoo is the /ability/ to tweak anything and everything, not the
/necessity/ to do so.  We already offer genkernel - why not a package
that basically runs it with a more comprehensive configuration and
installs the kernel?

Rich

[gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Duncan]

Nuno J. Silva posted on Fri, 25 Jan 2013 22:06:35 +0200 as excerpted:

> I am almost sure the current check does *not* use config.gz but
> /usr/src/linux/.config. At least, I've not had config.gz enabled for a
> long time, and I've always seen the checks working. In fact, I think the
> checks print something along the lines of "looking for kernel source
> under /usr/src/linux... found config for linux-...".

Actually, AFAIK the current check looks for both config.gz and in the 
kernel sources dir, since often one or the other isn't available, but a 
lot of the time one or the other /is/ available, as well.  (The kernel 
can be configured without config.gz, and the sources symlink might be 
stale and point to something not installed any more, or maybe the 
partition containing the sources isn't mounted, or maybe the sources dir 
is there but belongs to a user other than portage or root, with 
permissions such that portage can't access it.)

So the current check is for whichever one it can find.  I don't know 
which it checks first and whether it checks both if the first is there 
but comes up with a problem, but if one is there and not the other, it 
should properly find and use the one, regardless of which one it is.

(Of course the checks are in the eclass.  Anyone sufficiently curious 
could just go look to see what it did.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman