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 446E1138247 for ; Wed, 13 Nov 2013 15:41:49 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C4A90E0A44; Wed, 13 Nov 2013 15:41:43 +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 BE399E09E0 for ; Wed, 13 Nov 2013 15:41:42 +0000 (UTC) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: floppym) by smtp.gentoo.org (Postfix) with ESMTPSA id CBBEF33F32F for ; Wed, 13 Nov 2013 15:41:41 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id to1so768727ieb.17 for ; Wed, 13 Nov 2013 07:41:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=A09Eai2Av7Hm5xkWEKcPIDIZwvYd2JdUhn5FcCVFhfM=; b=Tt3mkqpeC22+uIe+Pnp9qlwdl9004yLrTHFq7FhZCrWGjDypFdq+2zH36si+gtsIOf V7DspUhN/1U2ct8NkN3+v+SizNBrvee0I5bKz8YSaoUdxaZpSZrifIsQuVVcsX0N3h3H P0VJ0qQ09kI/wr3c0sMGeGgIFq3YqAvgQtO8kndqcKqHtf8qPOyAF4hqAL1mrjivauun +RqNmslx6+H6O5baD+q9MhnWXI8ndmrVCWLaPJG6uIJva21VQWhPQUdkqJQ23J4uLQxO QDaj+mk5s/hwoGsGhqbKtYq7RTaPos7SND/I6MeEAKNVvizReprZgmGF9BsEiTOQm8JX 1Ngw== 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 X-Received: by 10.50.117.103 with SMTP id kd7mr18811534igb.4.1384357300511; Wed, 13 Nov 2013 07:41:40 -0800 (PST) Received: by 10.64.139.5 with HTTP; Wed, 13 Nov 2013 07:41:40 -0800 (PST) In-Reply-To: References: <20131113151012.04145837@gentoo.org> Date: Wed, 13 Nov 2013 10:41:40 -0500 Message-ID: Subject: Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask From: Mike Gilbert To: Gentoo Dev Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 8e785bdf-677d-48c9-90e9-671aaf51e8f5 X-Archives-Hash: 57abfe80f9eb7dee63a66a8222c52076 On Wed, Nov 13, 2013 at 10:23 AM, Martin Vaeth wrote: > Micha=C5=82 G=C3=B3rny wrote: >> >>> As I understand, it tries to solve a "social" issue >>> (that an ARCH user might set a USE-flag which eventually >>> pulls in an ~ARCH package) on a technical level >>> (by forcibly disabling the USE-flag for the user). >>> Solving social problems by technical means is never a good >>> idea: >> >> Then you don't understand it. >> >> The basic issue is that we couldn't stabilize a package without >> stabilizing all of its optional dependencies. > > Exactly: The social issue is that you have this rule fixed > without any exceptions and do not want to discuss about exceptions. > >> There were even cases when I had to revbump a package in order to keep >> 'limited' revision to stabilize and 'full' to keep testing. > > The social issue has to be solved and it has to be clarified > when packages are allowed to have USE-flags depending on unstable > packages which the user has to resolve when he wants them. > >> Just to be clear -- this isn't only a social issue. This is a valid QA >> concern that we had no distinction between 'flags that are fine on >> stable' and 'flags that are not'. If some flags work and some do not, >> resulting in 'unsatisfiable dep' errors, this is technical. > > No. The user has to be told that he *should* not use such certain > flags on a stable system. This can happen by portage reporting > a message that some USE-dependency is pulling in an unstable package, > but it can also happen in a different way. > The use.stable.mask "solution" is to not inform the user but just > decide behind his back that he cannot use the flag and enforce > this decision. > Instead, e.g. one can let portage report if some useflag described > in use.stable.mask needs to be disabled, or one can use some > "I_KNOW_WHAT_I_AM_DOING" name, or whatever. There are many ways > of reporting. But forcing a decision on the user without even > communicating reasonably why this decision was forced is very bad IMHO. Let's talk about the development workflow we use for a minute: Say I want to stabilize a package on a given architecture. One of the first tests I run is to change KEYWORDS and run repoman. repoman will check to ensure that all dependencies are at least visible with the given set of KEYWORDS. This is a fairly important check, and it often prevents major fuck ups. If we were to remove use.stable.mask, I as a developer would require some alternate way to declare a use flag unsupported on stable so that repoman knows not to check the optional dependencies for it with stable keywords. This is not a completely social issue; there is a very real technical/QA issue that needs to be addressed on the development side. If you can figure that out, we can talk about changing the end-user experience.