From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 1B257138247 for ; Sat, 28 Dec 2013 17:23:55 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2946FE0B1F; Sat, 28 Dec 2013 17:23:49 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 3837EE0AA1 for ; Sat, 28 Dec 2013 17:23:48 +0000 (UTC) Received: from [192.168.0.10] (unknown [78.129.121.117]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: patrick) by smtp.gentoo.org (Postfix) with ESMTPSA id 37EC433F75F for ; Sat, 28 Dec 2013 17:23:47 +0000 (UTC) Message-ID: <52BF09D7.3060508@gentoo.org> Date: Sat, 28 Dec 2013 18:26:47 +0100 From: Patrick Lauer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/umurmur: metadata.xml ChangeLog References: <20131225095020.A91BE2004C@flycatcher.gentoo.org> <52BACEE8.1010006@gentoo.org> <52BADA97.8010600@gentoo.org> <52BC2E30.9080006@gentoo.org> <20131226132724.6b9477af@googlemail.com> <52BEEA2D.2020103@gentoo.org> <20131228173502.224c9f96@TOMWIJ-GENTOO> In-Reply-To: <20131228173502.224c9f96@TOMWIJ-GENTOO> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 8e0c5218-3213-43e6-8575-133685cb2b0b X-Archives-Hash: b35cb7311f16bfcbf96532cd81864f96 > The discussion is based on some questions that are hard to agree on: > > 1. How much of a problem is an unused USE flag in metadata.xml? Cosmetic issue. No functional impact. > 2. Should such repoman warnings be fixed? By whom? When? How? Yes. You see it, you fix it. Not fixing cosmetic issues (cf. compiler warnings) leads to more and more noise until real issues are just drowned in the noise; the only way to achieve excellence (in terms of quality) is discipline in adhering to rules and standards obsessively. If there are (too) many false positives we should add proper annotations to silence repoman ... > 3. Can USE flags actually be removed from stable ebuilds? Usually removing stable ebuilds makes useflags "disappear", rarely does masking stuff (e.g. old cups) lead to the disappearance of useflags as they would now be broken > 4. ... Do we need to discuss this? No. It's an amazing waste of time, almost as if we had no real problems to focus on. > > Because this can yield quite some bike-shedding; the alternative "out of > the box thinking" package.use.mask solution satisfies both parties, > which renders that discussion unnecessary. Nobody has objected this. That is a "fix" specific to this package alone, in the general case it is not valid.