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 874EA139085 for ; Fri, 27 Jan 2017 11:17:01 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 545FF2241C6; Fri, 27 Jan 2017 11:16:52 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 0E1292241B3 for ; Fri, 27 Jan 2017 11:16:51 +0000 (UTC) Received: from [192.168.2.10] (62.65.231.75.cable.starman.ee [62.65.231.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: leio) by smtp.gentoo.org (Postfix) with ESMTPSA id 58EB534106E for ; Fri, 27 Jan 2017 11:16:50 +0000 (UTC) Message-ID: <1485515805.22895.4.camel@gentoo.org> Subject: Re: [gentoo-dev] berkdb and gdbm in global USE defaults From: Mart Raudsepp To: gentoo-dev@lists.gentoo.org Date: Fri, 27 Jan 2017 13:16:45 +0200 In-Reply-To: <20170127235857.3cd9e847@katipo2.lan> References: <1485503640.22895.2.camel@gentoo.org> <20170127083223.GK42019@gentoo.org> <20170127235857.3cd9e847@katipo2.lan> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.3 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 Content-Transfer-Encoding: 8bit X-Archives-Salt: aeed8390-843b-4923-89ee-73456557b0d3 X-Archives-Hash: 35e1fda0c4d21fd678cb51731ae3d596 Ühel kenal päeval, R, 27.01.2017 kell 23:58, kirjutas Kent Fredric: > On Fri, 27 Jan 2017 09:32:23 +0100 > Fabian Groffen wrote: > > > I'm interested to hear how other people feel about this. > > Yeah. Pretty much my reaction to  > > Mart Raudsepp wrote: > > > The maintainer should be giving the choice of both, > > but if only one can be chosen, the maintainer should make the > > choice > > for you by preferring one of them. Likely gdbm, given berkdb > > licensing > > saga. > > Brought the same question to me: > > If the design is intended to force your hand when you have both, what > is indeed > the point of a REQUIRED_USE feature at all? It can be very useful in some cases, especially when these cases involve local USE flags in a way that the errors come after enabling something locally in an unsuitable way. But yes, ideally the package manager would have a clue about what happened for the cases like the one in question, but REQUIRED_USE provided a faster solution to some of the problems that could be implemented in package managers in a reasonable time for the EAPI this was introduced in. We could work on top of this in a future EAPI. > If "choose a useflag for the user" is something that is happening, it > should > at least be *visible* to the user that this is happening, not being a > silent > decision that didn't allow the user to have any say in the matter. > > What if the feature you chose instead, was contrary to the one they > wanted? > > If anything, I think this is a suggestion that *maybe* we should a > way to > specify a mechanism for allowing a default to be chosen from a > mutually > exclusive set, and then: Sure, I have some thoughts for this and a rough draft, at least in my head :) I don't have it as a priority to sketch it out well alone, but if someone is honestly interested, I could braindump my ideas in realtime medium. Or someone thinks of them themselves :) > a. Inform the user via pretend output that this automatic conflict > reduction >    has been performed > > b. Define a portage option that disables automatic conflict > resolution for >    required USE, so users who hate (a) can turn it off. > > > But as it stands, Mart's suggestion of "Hey, just don't use required > use, > decide for the user" stands essentially as a regression against > portage itself.