Re: [gentoo-dev] acceptable alternatives to -Werror, was: Changing policy about -Werror
Mike Auty schrieb: Installation will proceed, but the user will get a big fat warning that the sys-fs/zfs package is potentially broken. This seems like a sure-fire way to make users paranoid and/or desensitized? People will learn to ignore warnings if we make them big red and flashing but then say they're only potential breakages (and they subsequently discover that most everything runs fine). If they learn to ignore big red flashing warnings it'll be more difficult when they're not potential breakages but actual ones we've accurately identified... Maybe "big fat warning" was a bit of an overstatement. I meant the same kind of notice that @preserved-rebuild set produces today. Or the "configuration files need updating" message. Much like the aforementioned, the affected package might continue to work totally fine, or be broken in subtle ways. It might bother the user enough to report a bug, but hopefully not enough to turn them away from Gentoo. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] acceptable alternatives to -Werror, was: Changing policy about -Werror
> On Sep 12, 2018, at 8:23 PM, Chí-Thanh Christopher Nguyễn > wrote: > > Rich Freeman schrieb: >>> Requirements: >>> >>> * Do not fail to build/install when a warning is encountered >> On a particularly critical package like a filesystem, wouldn't we want >> to still fail to install when a warning is encountered? > > Installation will proceed, but the user will get a big fat warning that the > sys-fs/zfs package is potentially broken. The way that it works is that a user explicitly must enable USE=debug for -Werror to apply. The package itself’s use of -Werror in USE=debug does not prevent corruption issues so much as it detects them because the kernel code is built in userspace. sys-fs/zfs-kmod is what matters for this. USE=debug does not turn on -Werror there because we don’t inject it into the kernel build system. If such a bug is detected and a user proceeds to use the rebuilt kernel module, things could go poorly. Anyway, I seem to have injected noise into the conversation by bringing this up because the discussion is whether -Werror by default should be allowed. I only commented because I felt that it should be an exception in the case of USE=debug or an explicit USE flag for Werror (e.g. USE=Werror). > >> I get that users might quit if packages don't install, but I'm not >> sure that a filesystem corruption is going to make them any happier... > > If the user recognizes this as a critical package, then they can do the > research before deciding on whether to use the package as is, attempt to > downgrade, or wait until a fix is released. > > > Best regards, > Chí-Thanh Christopher Nguyễn >
Re: [gentoo-dev] acceptable alternatives to -Werror, was: Changing policy about -Werror
Hiya, On 13/09/2018 01:23, Chí-Thanh Christopher Nguyễn wrote: > Installation will proceed, but the user will get a big fat warning that > the sys-fs/zfs package is potentially broken. This seems like a sure-fire way to make users paranoid and/or desensitized? People will learn to ignore warnings if we make them big red and flashing but then say they're only potential breakages (and they subsequently discover that most everything runs fine). If they learn to ignore big red flashing warnings it'll be more difficult when they're not potential breakages but actual ones we've accurately identified... Mike 5:) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] acceptable alternatives to -Werror, was: Changing policy about -Werror
Rich Freeman schrieb: If the user recognizes this as a critical package, then they can do the research before deciding on whether to use the package as is, attempt to downgrade, or wait until a fix is released. But, you've ALREADY overwritten the previous version of the package that presumably didn't have this problem. What if downgrading doesn't cause the problem to go away? What if it is due to some dependency or toolchain change? Users would presumably want to roll back to the binaries that were working just a few minutes ago, not build new ones that might or might not have the same issue. Users could weigh their options and then decide on how to best proceed. In case of zfs, they still have time until next reboot to fix this. Or the maintainer can set PROPERTIES="interactive" in anticipation of such a situation and ask "Are you sure you want to install this [y/N]?". Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] acceptable alternatives to -Werror, was: Changing policy about -Werror
On Wed, Sep 12, 2018 at 8:23 PM Chí-Thanh Christopher Nguyễn wrote: > > Rich Freeman schrieb: > >> Requirements: > >> > >> * Do not fail to build/install when a warning is encountered > > > > On a particularly critical package like a filesystem, wouldn't we want > > to still fail to install when a warning is encountered? > > Installation will proceed, but the user will get a big fat warning that the > sys-fs/zfs package is potentially broken. > > > I get that users might quit if packages don't install, but I'm not > > sure that a filesystem corruption is going to make them any happier... > > If the user recognizes this as a critical package, then they can do the > research before deciding on whether to use the package as is, attempt to > downgrade, or wait until a fix is released. But, you've ALREADY overwritten the previous version of the package that presumably didn't have this problem. What if downgrading doesn't cause the problem to go away? What if it is due to some dependency or toolchain change? Users would presumably want to roll back to the binaries that were working just a few minutes ago, not build new ones that might or might not have the same issue. -- Rich
Re: [gentoo-dev] acceptable alternatives to -Werror, was: Changing policy about -Werror
Rich Freeman schrieb: Requirements: * Do not fail to build/install when a warning is encountered On a particularly critical package like a filesystem, wouldn't we want to still fail to install when a warning is encountered? Installation will proceed, but the user will get a big fat warning that the sys-fs/zfs package is potentially broken. I get that users might quit if packages don't install, but I'm not sure that a filesystem corruption is going to make them any happier... If the user recognizes this as a critical package, then they can do the research before deciding on whether to use the package as is, attempt to downgrade, or wait until a fix is released. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] acceptable alternatives to -Werror, was: Changing policy about -Werror
On Wed, Sep 12, 2018 at 7:35 PM Chí-Thanh Christopher Nguyễn wrote: > > > Requirements: > > * Do not fail to build/install when a warning is encountered On a particularly critical package like a filesystem, wouldn't we want to still fail to install when a warning is encountered? > Also possible is to introduce FEATURES="strict-warnings" or similar, which > will cause the build to fail if warnings are encountered in a warningfree > ebuild. I guess this depends on whether warningfree is only used where -Werror would otherwise be used. Packages could presumably also warn users when installing without this feature set not to complain too much if our defaults destroy their data and to consider setting the flag... :) I get that users might quit if packages don't install, but I'm not sure that a filesystem corruption is going to make them any happier... -- Rich
[gentoo-dev] acceptable alternatives to -Werror, was: Changing policy about -Werror
Hi! So from the discussion I gather that -Werror has both desirable and undesirable effects. Question is, can we somehow mitigate the undesirable effects while still retaining the desirable effects as much as possible? Requirements: * Bother the user enough that they will report the problem, but not enough that they will leave Gentoo for another distro, which means: * Do not fail to build/install when a warning is encountered * Do not silently install the package anyway when a warning is encountered Rough suggestion: 1. Introduce a new value in ebuilds for PROPERTIES, named "warningfree" (or something similar for RESTRICT if that is preferable). 2. Introduce a new package set, named @broken-warningfree. If a package is in this set, emerge will display a notification each time it runs (like with @preserved-rebuild). 3. Extend install-qa-check.d/90gcc-warnings so that optionally all compiler warnings will be caught 4. If PROPERTIES="warningfree" is set, 90gcc-warnings catches all compiler warnings 5. If PROPERTIES="warningfree" is set, and there is a warning caught, add the package to the @broken-warningfree set on install 6. If there is no warning caught, remove the package from the @broken-warningfree set (if it is currently in there) 7. When ebuild maintainers remove -Werror from a package, they can set PROPERTIES="warningfree" at their discretion Also possible is to introduce FEATURES="strict-warnings" or similar, which will cause the build to fail if warnings are encountered in a warningfree ebuild. I need to think more how this could work with binpkgs though. Best regards, Chí-Thanh Christopher Nguyễn
