Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
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
Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
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
On Sat, Jan 26, 2013 at 5:30 PM, Fabio Erculiani lx...@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
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
On Sat, Jan 26, 2013 at 7:31 PM, Peter Stuge pe...@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
Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
On Fri, Jan 25, 2013 at 1:24 PM, Nuno J. Silva nunojsi...@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
On Fri, 25 Jan 2013 13:47:05 -0500 Rich Freeman ri...@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
On Fri, Jan 25, 2013 at 2:19 PM, Christopher Head ch...@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
Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
On Fri, Jan 25, 2013 at 2:47 PM, Nuno J. Silva nunojsi...@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
Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
On Fri, Jan 25, 2013 at 3:06 PM, Nuno J. Silva nunojsi...@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
Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
On Thu, Jan 24, 2013 at 12:49 PM, Duncan 1i5t5.dun...@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
-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.dun...@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
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.dun...@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
On Thu, Jan 24, 2013 at 1:18 PM, Ian Stakenvicius a...@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
On 01/24/13 13:25, Rich Freeman wrote:
On Thu, Jan 24, 2013 at 1:18 PM, Ian Stakenvicius a...@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
-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
a...@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
On Thu, Jan 24, 2013 at 1:58 PM, Ian Stakenvicius a...@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
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
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
On 01/24/13 15:26, viv...@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
On 01/24/13 15:39, Michael Orlitzky wrote: On 01/24/13 15:26, viv...@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
On Thu, Jan 24, 2013 at 2:21 PM, Michael Orlitzky mich...@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
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, viv...@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
On 01/24/13 19:29, viv...@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
On Fri, Jan 25, 2013 at 01:39:08AM +, 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 : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
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
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
Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
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.
