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