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 8EAE4139694 for ; Thu, 1 Jun 2017 08:55:40 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9B219E0ECA; Thu, 1 Jun 2017 08:55:31 +0000 (UTC) Received: from smtp.gentoo.org (mail.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 41857E0CA7 for ; Thu, 1 Jun 2017 08:55:31 +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 23B1634172A for ; Thu, 1 Jun 2017 08:55:28 +0000 (UTC) Date: Thu, 1 Jun 2017 10:55:23 +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: <20170601105523.08a9234e@gentoo.org> In-Reply-To: <1496257344.25758.1.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> <20170530173340.0b575526@gentoo.org> <1496167898.1335.1.camel@gentoo.org> <20170530204614.61e8e42c@gentoo.org> <1496213717.1164.1.camel@gentoo.org> <20170531093257.23b66f88@gentoo.org> <1496217792.1164.5.camel@gentoo.org> <20170531103819.417c2420@gentoo.org> <1496235892.25038.1.camel@gentoo.org> <20170531193922.477245bb@gentoo.org> <1496257344.25758.1.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: 0668c166-8fc3-4562-9a4e-9933f227bc08 X-Archives-Hash: d1bd84a86d02c8c8dce871926cce61d1 On Wed, 31 May 2017 21:02:24 +0200 Micha=C5=82 G=C3=B3rny wrote: > On =C5=9Bro, 2017-05-31 at 19:39 +0200, Alexis Ballier wrote: > > > > Again, you *need* to process the constraints in order. '!a? > > > > ( b ) !b? ( a )' is not deterministic when none of a and b are > > > > enabled otherwise. =20 > > >=20 > > > You can't rely on any particular order of constraints, especially > > > when eclass stacking comes into play. You could try defining some > > > constraint- sorting algorithm but it's going to be complex and > > > it's usefulness will be limited anyway due to various kinds of > > > grouping. =20 > >=20 > >=20 > > Better have some order: If half of the above constraint comes from > > ebuild and the other half comes from eclass, then PM might toggle > > 'a' or 'b' depending on the phase of the moon which is specifically > > what we're trying to avoid. =20 >=20 > No, it can't. That's the whole point. The algorithm must be defined so > that it is always predictable independently of order (maybe except > the ordering inside ^^, ||, ??) and independently of how it's nested > (i.e. 'a? ( b? ( c ) )' must give the same result as 'b? ( a? ( c ) > )'). This is a lot of handwaving without real description of how it would work. This starts to look a lot like confluence in rewriting systems and you want developers to write only confluent rules and repoman to decide that. Good luck with that. Let's look at real world examples: gtk+: REQUIRED_USE=3D" || ( aqua wayland X ) xinerama? ( X ) " Let's assume aqua is masked, which reduces to: REQUIRED_USE=3D" || ( wayland X ) xinerama? ( X ) " With USE=3D'-* xinerama' this one is invalid: applying the first constraint first enables wayland, then the 2nd enables X, giving a result of USE=3D"xinerama wayland X". Applying the 2nd first enables X, then the 1st does nothing, giving a result of USE=3D"xinerama X". Now the funny one: $ portageq metadata / ebuild dev-lang/php-7.0.18 REQUIRED_USE cli? ( ^^ ( readline libedit ) ) truetype? ( gd ) webp? ( gd ) cjk? ( gd ) exif? ( gd ) xpm? ( gd ) gd? ( zlib ) simplexml? ( xml ) soap? ( xml ) wddx? ( xml ) xmlrpc? ( || ( xml iconv ) ) xmlreader? ( xml ) xslt? ( xml ) ldap-sasl? ( ldap ) mhash? ( hash ) phar? ( hash ) qdbm? ( !gdbm ) readline? ( !libedit ) recode? ( !imap !mysqli ) sharedmem? ( !threads ) mysql? ( || ( mysqli pdo ) ) || ( cli cgi fpm apache2 embed phpdbg ) There are probably dozens of ways to make that non deterministic. Here's one: USE=3D'-*'. Apply '|| ( cli cgi fpm apache2 embed phpdbg )' last; this enables 'cli'. Since it's the last one, REQUIRED_USE is not satisfied because of 'cli? ( ^^ ( readline libedit ) )'. If you process it first, then you enable cli and readline and are good. > If you start relying on stuff like ordering, you're one step from > making stuff suddenly fail or change meaning due to minor changes, > like sorting stuff. What we want to ensure is that for 2 identical inputs the results are identical. If ordering is specified, then re-ordering REQUIRED_USE in an ebuild is not minor anymore. That's a trade off. > > eclass stacking is not a problem: specify if it's append or prepend > > and be done. =20 >=20 > What about multiple inherits with guards? Next thing I know, we end up > putting REQUIRED_USE outside guards (like we have to do with > EXPORT_FUNCTIONS now) because you need a specific order, and guards > make it unpredictable. guards wont make much of a difference: They'll simply de-duplicate constraints by keeping only the rightmost one in the prepend case and the leftmost one in the append case I think. > > Note that if you want to remove the need for an order, you'll need > > to ensure that all orderings of the constraints give the same > > result. It's not sufficient to "only" check all possible inputs. =20 >=20 > That's the matter of the algorithm. For what I know, this algorithm does not even exist. > > Also, what happens if we applied all the constraints and obtained > > some useflags setting that still fails REQUIRED_USE check ? =20 >=20 > It can't happen. If you can apply all the constraints, then implicitly > REQUIRED_USE is satisfied. If you can't apply all the constraints, > then it just fails. Of course, we want to ultimately avoid that case. See the php example above. How do you ensure this does not happen? Note that your assertion 'If you can apply all the constraints, then implicitly REQUIRED_USE is satisfied.' is false: You're changing the values of useflags, thus might violate some previously checked constraint. > > > The point would be: by definition, the solver should be able to > > > touch *any* USE flag. If it can't, it mostly implies that you > > > can't use the automatic solver, and so the case is irrelevant for > > > checking. Attempting to go beyond that is going to give a lot of > > > complexity and most likely kill the whole idea. > > >=20 > > > One thing we need to worry about are masks. We need to think about > > > them. =20 > >=20 > > It makes zero difference for any solver if you replace variables > > (useflags) by 'true' or 'false' constants (masked/forced/user-forced > > useflags). It's even simpler actually. Whether the formula is not > > constantly 'true' (ie REQUIRED_USE is useless) or constantly > > 'false' (ie there's no way to solve it) is equivalent to solving > > SAT. We likely don't want that for repoman running on php. > > =20 >=20 > Well, probably yes. We just need to make sure to apply them correctly > in different contexts, to avoid accidentally skipping some > constraints. I think it would be reasonably to assume that: [...] Yes, you can eliminate constants. It is probably even confluent, i.e. the order in which you eliminate them does not matter and it always converges to the same result. Alexis.