From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id EBA4D138334 for ; Mon, 10 Sep 2018 00:30:53 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 59E72E0BDA; Mon, 10 Sep 2018 00:30:50 +0000 (UTC) Received: from mail-pg1-f195.google.com (mail-pg1-f195.google.com [209.85.215.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id EFEE3E0BD2 for ; Mon, 10 Sep 2018 00:30:49 +0000 (UTC) Received: by mail-pg1-f195.google.com with SMTP id l63-v6so9530686pga.7 for ; Sun, 09 Sep 2018 17:30:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ZWB1OfsDHeHwueSn3kSKwPMw1KzxqJcF4JUxKDvtmLo=; b=NwRh/RKA+2ZrAK9qVLKQBneGIHmj/BTSbp7XNKaXfYffkbcMBTZ4kzSU93mNcqkBxf mVoAjTvRSHfaJLccpIVvdsQ0ZxfgiTyhp77rz4cD6CwDQXhnDbQmDjVRea7hDaFbX87r OXwp2Y0n71fp63tn7oYB5KP4sO6XP6O3XN1skpCCPQtAUGxRGcpoW4viZdTpx5jU8gxn Ete94l9wjGftIYNZFBLb8E1CaPharPO6FMCU3e/9CEg4REZgXxK7bF5vSag848T2ER5G eOvj3BzG9dgG4tnN4JvVQ92G46NZPkAPUwMs+iaUaE9LZ5Vl3ND9gPzJABbknbfGjKkH i1AA== X-Gm-Message-State: APzg51AdR8wy6/Qxi59ntRxu0dcGeOrPbT9HW9cHNSgh01Ag8uWiC4w6 GLjzNDoe2WDutmP4YF1l5PxO9YAubFx0U7go2Uf92nTr X-Google-Smtp-Source: ANB0Vdbju7NKFGdNm/ghmr720p4ZL00XxmGL/11hQlXNUoKXKe98mmvfB7TNInuEbwLkzAnALIwnqCDTI6RWFTNLHxs= X-Received: by 2002:a62:8d16:: with SMTP id z22-v6mr20969281pfd.181.1536539448542; Sun, 09 Sep 2018 17:30:48 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 References: <20180909143221.21d784d02f51623e8c57c545@gentoo.org> <90173cf2-4b81-7337-f10f-e8c99ad8eaa7@gentoo.org> In-Reply-To: <90173cf2-4b81-7337-f10f-e8c99ad8eaa7@gentoo.org> From: Rich Freeman Date: Sun, 9 Sep 2018 20:30:37 -0400 Message-ID: Subject: Re: [gentoo-dev] Changing policy about -Werror To: gentoo-dev Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: 73de57b5-c280-4e7a-ae78-798de68758c9 X-Archives-Hash: 471d04f2f6643495ba01d447fcb3f3ed On Sun, Sep 9, 2018 at 1:50 PM Michael Orlitzky wrote: > > So if you're using -Werror to prevent a > "vulnerable" package from being installed, it doesn't work, and can > actually be harmful if it prevents me from using a better compiler. > Whether or not the new compiler is better, it is clearly untested with the package-version in question (otherwise these warnings would have been addressed). For something critical like a filesystem (zfs) that could be useful to know. I'm not convinced that this rule ought to be absolute. That said, I do agree with your later comments that this creates a messy situation by painting a user into a corner. Other than sticking painful ranged version dependencies on the toolchain into the package I'm not sure if there is a cleaner solution that guarantees that the package won't be built with a version of gcc that is untested with that specific package without a user override. I guess we could just have sensitive ebuilds output that it might eat your data if you didn't add -Werror to your CFLAGS and then leave it to the users to decide how much they care about build errors vs unlikely sorry-I-lost-your-10PiB-array errors. -- Rich