Re: [gentoo-dev] Changing policy about -Werror

[Michał Górny]

On Sun, 2018-09-09 at 14:32 +0300, Andrew Savchenko wrote:
> Hi!
>
> Our current -Werror policy demands unconditional removal:
> https://devmanual.gentoo.org/ebuild-writing/common-mistakes/index.html#-werror-compiler-flag-not-removed
>
> I think this is wrong, see bugs 665464, 665538 for a recent
> discussion why.
>
> My point is that in *most* cases -Werror indeed should be removed,
> because upstream rarely can keep up with all possible configure,
> *FLAGS, compiler versions and arch combinations. But! In some cases
> — especially for security oriented software — this flag may be
> pertain and may be kept at maintainer's discretion.
>
> The rationale is that -Werror usually points to dangerous
> situations like uninitialized variables, pointer type mismatch or
> implicit function declaration (and much more) which may lead to
> serious security implications.

It may also point to a different coding style, user's flags (like
clang's 'argument unused during X' warnings.  Are you suggesting that
upstream is going to detect all those situations and prevent them from
occurring, or are you going to WONTFIX the resulting bugs?

>
> So, if maintainer has enough manpower to support this flag, we
> should allow to keep it. Of course if it will cause long-standing
> troubles (e.g. bugs opened for a long time) QA should have power to
> remove it or demand its removal.

What you're saying basically boils down to 'it's fine that the package
randomly fails to build if somebody will fix it'.  However, some people
actually use Gentoo on real systems and really prefer when things
*build*.  While resolving warnings etc. is usually a worthwhile goal,
not at the cost of having users repeatedly hit failures, have to report
bugs about them and wait for the maintainer to fix them.

Not to mention that those fixes only work for new versions,
and therefore this whole idea turns downgrading (however undesirable you
might consider it) into a pointless effort of chasing old warnings.

This is just another example of writing programs for a single toolchain,
and adding more hacks every time someone tests with another one.

-- 
Best regards,
Michał Górny