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 4B684139694 for ; Tue, 30 May 2017 15:34:04 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BD2F621C073; Tue, 30 May 2017 15:33:48 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (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 703D421C012 for ; Tue, 30 May 2017 15:33:48 +0000 (UTC) Received: from localhost (unknown [IPv6:2a01:e34:eeaa:6bd0:4ecc:6aff:fe03:1cfc]) (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 00F0D33BE61 for ; Tue, 30 May 2017 15:33:46 +0000 (UTC) Date: Tue, 30 May 2017 17:33:40 +0200 From: Alexis Ballier To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE) Message-ID: <20170530173340.0b575526@gentoo.org> In-Reply-To: <1496154812.1238.5.camel@gentoo.org> References: <1496071993.31087.1.camel@gentoo.org> <20170529200037.2559f80a@gentoo.org> <1496093035.12795.3.camel@gentoo.org> <20170530094245.40e1cf64@gentoo.org> <20170530092245.681d4aeb@snowblower> <20170530104654.31b89e10@gentoo.org> <20170530095607.1adbc0b8@snowblower> <20170530112518.65b4f9e9@gentoo.org> <22829.24276.295.969060@a1i15.kph.uni-mainz.de> <1496154812.1238.5.camel@gentoo.org> Organization: Gentoo X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; 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=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 13123fcb-ed3d-4797-b6c9-1113ed986f5d X-Archives-Hash: 03c7930b494e51efaa10f0c1d23ee840 On Tue, 30 May 2017 16:33:32 +0200 Micha=C5=82 G=C3=B3rny wrote: [...] > The problem is: how far is that going to work? That's what I would > like to try determining in the first place. >=20 > I'm most worried about complex constructs like: >=20 > foo? ( bar ) ^^ ( baz=C2=A0bar ) The order in which it is written will matter: Assuming user has enabled 'foo', first process 'foo? ( bar )', which gives you "USE=3D'foo bar'". Then process '^^ ( baz=C2=A0bar )'; all good, we're done. If user has enabled 'foo baz' then there is a problem and it is normal to rant. > But I do not have any obvious ideas how to express them safely while > preserving readability and relative simplicity of the constructs, i.e. > not having to write a big mapping table. >=20 > Especially if we are to allow having a preference on baz, the mapping > for ^^ alone would be: >=20 > !bar !baz -> !bar baz > bar !baz -> bar !baz [valid] > !bar baz -> !bar baz [valid] > bar baz -> !bar baz >=20 > With the additional foo constraint, it becomes harder but not > impossible. However, with more constraints we may reach a dead end. You already made a convincing argument that || & co are good things to have, that's not to write the combinatorics of the whole thing as implications! Moreover, you can use implications and the processing order as hints: If you believe 'if foo and bar are enabled then baz should most likely be enabled even if the latter '|| ( bay baz )' would select 'bay' and not 'baz'' you prepend required_use by 'foo? bar? baz' and are done with it. > Of course, we could just validate all the possible cases via repoman, > and reject the ebuild if there's at least one conflict between them. > Not sure how to express that properly in the spec though. Not sure > how it would work practically. Adding a 2^n check to repoman isn't gonna work well. [...]