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 4266D138247 for ; Fri, 15 Nov 2013 20:18:52 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 85FDEE0A5E; Fri, 15 Nov 2013 20:18:46 +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 9EAE7E0962 for ; Fri, 15 Nov 2013 20:18:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 80F3F33F130 for ; Fri, 15 Nov 2013 20:18:44 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -0.584 X-Spam-Level: X-Spam-Status: No, score=-0.584 tagged_above=-999 required=5.5 tests=[AWL=-0.581, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from smtp.gentoo.org ([IPv6:::ffff:127.0.0.1]) by localhost (smtp.gentoo.org [IPv6:::ffff:127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlbPb4zzZzmO for ; Fri, 15 Nov 2013 20:18:37 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 4680333EFE7 for ; Fri, 15 Nov 2013 20:18:36 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VhPqa-0005n2-Cd for gentoo-dev@gentoo.org; Fri, 15 Nov 2013 21:18:32 +0100 Received: from lounge.imp.fu-berlin.de ([160.45.42.83]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Nov 2013 21:18:32 +0100 Received: from vaeth by lounge.imp.fu-berlin.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Nov 2013 21:18:32 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Martin Vaeth Subject: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask Date: Fri, 15 Nov 2013 20:18:03 +0000 (UTC) Message-ID: References: <20131115155430.16254.qmail@stuge.se> <52864645.2070506@gentoo.org> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lounge.imp.fu-berlin.de User-Agent: slrn/pre1.0.0-26 (Linux) 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 X-Archives-Salt: 80b0619f-b61c-4637-be3d-fa2c7bfeb071 X-Archives-Hash: 68844674e436070b004a29f71984e65f Ian Stakenvicius wrote: > On 15/11/13 10:54 AM, Peter Stuge wrote: >> .. >>> I think most of the confusion is caused by the necessity to put >>> a *stable* package atom into package.keywords to unmask a *USE* >>> flag. >> >> A lot can be learned just from the filenames: >> [...] >> The latter indicates that this concept has no less than four >> dimensions. > > Well, reordering this a bit: [...] > So I don't think this is entirely unclear. I think the point of Peter is not whether the *name* of the file is optimally chosen: His point is that the *semantics* (which is somehow reflected in the name) is too complex in the sense that it combines at least two concepts (USE-Flags and Stability) which from th user's point of view are completely unrelated. Only the developer's point of view of wanting to stabilize something earlier makes a connection between these concepts, but it is not really a natural conncetion: For someone who is not familiar with implicit implications of every USE-flag (i.e. a non-developer), the result looks like an almost random change of active USE-flags. Probably a lot of the confusion could be avoided if /etc/portage/package.accept_keywords would not implicitly unmask useflags. If this is not very hard to implement in portage, I would strongly vote to remove this implicit connection: This side effect is obviously the cause of the "dependency hell" examples.