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 69542138247 for ; Wed, 13 Nov 2013 13:38:04 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7E032E0CD2; Wed, 13 Nov 2013 13:37:53 +0000 (UTC) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 819CEE0C53 for ; Wed, 13 Nov 2013 13:37:52 +0000 (UTC) Received: by mail-vc0-f181.google.com with SMTP id lf12so282196vcb.12 for ; Wed, 13 Nov 2013 05:37:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=+dqdT7RuMnsipK0wG8USbXnsA/qRzHIim2Xq1PyhTMU=; b=jq3juBrwvRQxu2TAOmsB+0cpeCard5lXKfbhQQCZxeDNAGoGNHCKrO48b3VwoRmef9 9TH2fGWNeyUBH/g6oogLxJCnvOnfiZRqUVe2t9khVV5xRa3ibEsfTVW7MH5BopE7f3p0 5QvxTLPU92ma6ad5NFjN1oUluwQE2Lmyy1eOH4KoogPcwwvVkSyq4VxY6uvZ1RpXncaN GZlEu9TrLyO7YRk51RuokAJr9ZMmg4lJF7jgLdUY0Ovx/H9sAYSbAFhojAt2g4Y6G9ad pn8ajA4MkUOQ4+wl2EPEZERfSd3BDxcfJjeK4TGRfs5B7R2+vNu9tqipKbSmBxaoUCHb KNTA== 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.52.230.202 with SMTP id ta10mr805262vdc.41.1384349871432; Wed, 13 Nov 2013 05:37:51 -0800 (PST) Sender: freemanrich@gmail.com Received: by 10.52.108.199 with HTTP; Wed, 13 Nov 2013 05:37:51 -0800 (PST) In-Reply-To: <52837DB7.90805@gentoo.org> References: <20131113123953.623ac06d@TOMWIJ-GENTOO> <52837DB7.90805@gentoo.org> Date: Wed, 13 Nov 2013 08:37:51 -0500 X-Google-Sender-Auth: bXLbsJorccdWex1s2WotVgNHrIY Message-ID: Subject: Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask From: Rich Freeman To: gentoo-dev Content-Type: text/plain; charset=ISO-8859-1 X-Archives-Salt: 5a5aba54-49a4-4521-a9c0-1f7fc794aae2 X-Archives-Hash: 80206b2a4306ebd91e8d309d37dace73 On Wed, Nov 13, 2013 at 8:25 AM, Thomas Kahle wrote: > On 11/13/2013 12:39 PM, Tom Wijsman wrote: >> On Wed, 13 Nov 2013 10:28:02 +0000 (UTC) >> Martin Vaeth wrote: >> >>> Hello. >>> >>> The new "features" use.stable.mask and package.use.stable.mask >>> have turned maintaining systems with mixed ARCH and ~ARCH keywords >>> into a nightmare: >> >> They are considered unsupported by many; so, going down that path you >> need to be acquainted with Portage enough to keep a consistent system. > > This argument has come up several times, but is it valid? Honestly, opinions vary on this one and I don't think it is a productive path to go down. I also feel that being able to mix keywords is a big benefit of using Gentoo. I'd rather focus on practical ways to make this easier rather than whether it is desirable. That said, there are always going to be situations where mixing keywords isn't practical. You're not going to run stable chromium against ~arch v8, or mixed keywords between kdelibs and kwin, etc. > We could consider reducing the feature set of portage and live > with the "problems" that arise. When I started using Gentoo a > package could simply not go stable until all dependencies for all > USE flags were also stable. Masking USE flags was reserved to a > short list of very special architecture depend special cases. I don't think going backwards is the solution. Back in the old days packages broke from time to time because we didn't have adequate ways to express dependencies, and I don't think it is a good solution to strip USE flags out of packages when they go stable so that users don't even have the option to use them. It makes more sense to identify what specifically is causing problems and come up with better solutions to them. That said, your original email contained a few separate issues and they're probably best dealt with individually. We're not going to have a common solution for multilib, stable use masking, python-exec, and whatever other issues are lurking beneath the surface. Rich