Gentoo Archives: gentoo-dev

From: Matt Turner <mattst88@g.o>
To: gentoo development <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] Changing policy about -Werror
Date: Sun, 09 Sep 2018 20:48:19
Message-Id: CAEdQ38FQrvZHg-y+twfoqTE9nXB3vSgC=MMAjFqXJbRRj_+-7A@mail.gmail.com
In Reply to: [gentoo-dev] Changing policy about -Werror by Andrew Savchenko
1 On Sun, Sep 9, 2018 at 4:32 AM Andrew Savchenko <bircoph@g.o> wrote:
2 >
3 > Hi!
4 >
5 > Our current -Werror policy demands unconditional removal:
6 > https://devmanual.gentoo.org/ebuild-writing/common-mistakes/index.html#-werror-compiler-flag-not-removed
7 >
8 > I think this is wrong, see bugs 665464, 665538 for a recent
9 > discussion why.
10
11 Bug 665464 supports the exact opposite conclusion. Werror turned a
12 trivial warning into a build failure.
13
14 > My point is that in *most* cases -Werror indeed should be removed,
15 > because upstream rarely can keep up with all possible configure,
16 > *FLAGS, compiler versions and arch combinations. But! In some cases
17 > — especially for security oriented software — this flag may be
18 > pertain and may be kept at maintainer's discretion.
19 >
20 > The rationale is that -Werror usually points to dangerous
21 > situations like uninitialized variables, pointer type mismatch or
22 > implicit function declaration (and much more) which may lead to
23 > serious security implications.
24
25 Warnings are often over unimportant details (like in this bug). It is
26 certainly not the case that they "usually point to dangerous
27 situations".
28
29 > So, if maintainer has enough manpower to support this flag, we
30 > should allow to keep it. Of course if it will cause long-standing
31 > troubles (e.g. bugs opened for a long time) QA should have power to
32 > remove it or demand its removal.
33
34 In the bug that started this, it was the case that the maintainer
35 himself had not built the package with this configuration. Nor had any
36 arch team that recently stabilized the package (x86, amd64, ia64, ppc,
37 ppc64, arm).
38
39 So again, the bug supports the opposite conclusion.
40
41 The policy is sound, and I don't think we could have found a worse bug
42 as supporting evidence that we should revise the policy.