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 15E6F1386F3 for ; Wed, 12 Aug 2015 15:56:10 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0296F1428A; Wed, 12 Aug 2015 15:56:00 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 209EA1424D for ; Wed, 12 Aug 2015 15:55:54 +0000 (UTC) Received: from localhost (AMontpellier-655-1-335-201.w90-0.abo.wanadoo.fr [90.0.79.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: aballier) by smtp.gentoo.org (Postfix) with ESMTPSA id C5666340961 for ; Wed, 12 Aug 2015 15:55:52 +0000 (UTC) Date: Wed, 12 Aug 2015 17:55:47 +0200 From: Alexis Ballier To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: useflag policies Message-ID: <20150812175547.3e889a82@gentoo.org> In-Reply-To: <55CB669F.8020501@gentoo.org> References: <55C7AC24.2040503@gentoo.org> <55C9CA32.3060300@gentoo.org> <55C9F189.10102@gentoo.org> <20150812052120.5a83c3b1@googlemail.com> <20150812150349.00f8c8f9@gentoo.org> <21963.24971.636400.468846@a1i15.kph.uni-mainz.de> <55CB669F.8020501@gentoo.org> Organization: Gentoo X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-pc-linux-gnu) 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-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: 9ae6fbe9-aa36-4b28-82cb-a4de1601bdd5 X-Archives-Hash: 26b9d75d41047c065c0b1bd2419cc256 On Wed, 12 Aug 2015 11:30:39 -0400 Ian Stakenvicius wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 12/08/15 11:08 AM, Ulrich Mueller wrote: > >>>>>> On Wed, 12 Aug 2015, Alexis Ballier wrote: > > > >> i.e. something that really tells the PM how to automate the > >> choice: - 'qt5 -> !qt4' is rather straightforward to solve and > >> tells the PM how (note that it is not equivalent to 'qt4 -> > >> !qt5') - '^^ ( qt5 qt4 )' requires the PM to make a choice in > >> order to automate it > > > > I was thinking about some syntax like this: > > > > REQUIRED_USE="|| ( +foo bar ) ^^ ( +qt5 -qt4 )" > > > > The package manager would first evaluate each group in > > REQUIRED_USE with the original set of USE flags. If that doesn't > > evaluate to true, retry with flags changed as indicated by the + > > and - signs. > > > > Ulrich > > > > Having the ability for REQUIRED_USE to provide a default resolution > path should definitely help with things; I assume this is meant to > do its work via --autounmask-write or similar, ie to help users > adjust their config files? Or was the thought to allow PMs to > override USE immediately? I think it is better seen as a list of implications, esp. for this kind of questions :) With that in mind, there is no autounmask-write: effective USE for a given package is input USE with these implications applied. > Questions: > > 1 - how does +foo in REQUIRED_USE relate to use-defaults set in IUSE? This questions remains. I see use-defaults in IUSE as part of "input USE" above. [...] > 3 - will having REQUIRED_USE be able to force flags on (and others > off) likely result in abuse of profiles and other use defaults? I > forsee this being a way, for instance, for a dev to get around users > setting USE="-*" in make.conf to ensure a default use flag setting > is honoured. How? > 4 - Will a change to which flag the '+' is on likely to require a > revbump for VDB updates? For something like '^^ ( +qt4 qt5 )' I > could see maintainers wanting to switch which flag is default across > a bunch of packages at once when, say, the qt team wants qt5 to > become the de-facto default. It'll "require" a rebuild for those whose default changes anyway. I'd say no revbump since we don't revbump all affected packages when we add default enabled flags to make.defaults. Alexis.