On Thu, Jan 24, 2013 at 9:22 PM, Michael Orlitzky <mich...@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
