From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Nwu8Z-0006H5-5E for garchives@archives.gentoo.org; Wed, 31 Mar 2010 09:22:59 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 545BCE0C9B; Wed, 31 Mar 2010 09:22:54 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 99B39E0C41; Wed, 31 Mar 2010 09:22:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id AFDD51B4058; Wed, 31 Mar 2010 09:22:37 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -2.053 X-Spam-Level: X-Spam-Status: No, score=-2.053 required=5.5 tests=[AWL=0.546, BAYES_00=-2.599] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mg-0uwcXkg3f; Wed, 31 Mar 2010 09:22:31 +0000 (UTC) Received: from mail-pz0-f175.google.com (mail-pz0-f175.google.com [209.85.222.175]) by smtp.gentoo.org (Postfix) with ESMTP id B07EB1B40E0; Wed, 31 Mar 2010 09:22:30 +0000 (UTC) Received: by pzk5 with SMTP id 5so619328pzk.0 for ; Wed, 31 Mar 2010 02:22:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:cc :subject:message-id:mime-version:content-type:content-disposition :user-agent; bh=793Tgtzb5RZvAYoHDdVcMZbHwCdYU6US25ta0yBMNpg=; b=pFXUJqCXdyXj0fvTvu9OzPwYsrLL+/jPfXmdccLXna99quzqMv8+6+KJ/2p1tc4dkW XtUP87plAFNlSh2FKxxOy4ma7SLt1tUb9/iAnNImMk59f5DUjyNOMyzoueEFOCeI0aX6 nMkLcwTohulMqumcP6MgRjhv+GB7X+TFEgGhg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:mime-version:content-type :content-disposition:user-agent; b=a212FHIxxJa8xMz4tZTYIChZex7KTWbbGPqkrQMJeVCdJ2cKgbT6qGS6N5H7FXZS9K yrAeMMqUbB0x4TIbrLJ1+apUZCdRFiQwUNiNnSPUfhBW8EiixsW2lKZCChT95PcPGm17 yjy7OK5MufV+PUOmjjsTdJ7vQluUaL1aAKIgQ= Received: by 10.114.188.16 with SMTP id l16mr969686waf.87.1270027349721; Wed, 31 Mar 2010 02:22:29 -0700 (PDT) Received: from smtp.gmail.com (c-67-171-128-62.hsd1.wa.comcast.net [67.171.128.62]) by mx.google.com with ESMTPS id 20sm5764891pzk.15.2010.03.31.02.22.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 31 Mar 2010 02:22:28 -0700 (PDT) Received: by smtp.gmail.com (sSMTP sendmail emulation); Wed, 31 Mar 2010 02:20:35 -0700 Date: Wed, 31 Mar 2010 02:20:35 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Cc: gentoo-council@lists.gentoo.org, pms-bugs@gentoo.org Subject: [gentoo-dev] pkg_pretend USE validation and VALID_USE alternative Message-ID: <20100331092035.GA11663@hrair> 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: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5mCyUwZo2JvN/JJP" Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-Archives-Salt: d4658bd4-b15e-4ed2-86f1-829a69c63df9 X-Archives-Hash: b0e868626019f497eba47194c34e5421 --5mCyUwZo2JvN/JJP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hola all- For those who aren't familiar, pkg_pretend is in EAPI4- the main usage=20 of it is will be use dep checking- this email is specifically=20 regarding an alternative to it that *should* be superior for that use=20 case, but I'm looking for feedback. Basically, we use the original VALID_USE proposal from way back in=20 '05- if you're familiar w/ MYOPTIONS, they're reasonably similar. Roughly, VALID_USE is a list of constraints stating what the allowed=20 use flag combinations are for this pkg. If you think of normal=20 depdencies (I must have openssl and python merged prior), it's the=20 same machinery. Examples: # if build is set, python and openssl must be unset VALID_USE=3D"build? ( !python !openssl )" # if mysql is set, sqlite must not be, and vice versa. # note mysql/sqlite do *not* have to be set also. VALID_USE=3D"mysql? ( !sqlite ) !sqlite? ( mysql )" # mysql or sqlite must be set; exclusive or. VALID_USE=3D"mysql? ( !sqlite ) !mysql ( sqlite )" # alternative syntax, adding an xor group operator # note xor isn't required- you can do the same thing # via spelling it out, it's just a convenient thing to have. VALID_USE=3D"^^ ( mysql sqlite )" # if gui is enabled, a widget set must be specified- can build # multiple widget bindings VALID_USE=3D"X? ( || ( gtk qt motif ) )" Note that like dependencies, these are assertions. More importantly,=20 they're also data rather then executable code. Via it being data, up=20 front GUI's can tell you exactly what conflicts arise, and what needs=20 to be adjusted. Doing it as executable, can, but it's iterative and reliant on the dev=20 writing a clear message every time (rather then the UI tool getting=20 it right once). Clarifying iterative, consider USE=3D"build X" w/ valid use states being- VALID_USE=3D"build? ( !X !python ) X? ( ^^ ( gtk qt ) ) gtk? ( ssl )" The user first flips off build. They rerun emerge- next they're told=20 "you must choose gtk or qt, not both". They change to USE=3D"X gtk". =20 Next they're told "you need ssl turned on if you want gtk". At this point, the user goes and gets a beer because aparently Murphy=20 hates them and it's going to be a long, long night. There also is one major issue with relying on pkg_pretend=20 (executable) for use state validation vs doing it as VALID_USE=20 (data)- the package manager cannot know what states are valid thus=20 limiting the things it can do. Literally the pkg manager is screwed=20 when it comes to use cycle breaking. If the pkg manager doesn't know=20 what states are valid, when it encounters a use cycle it doesn't know=20 what intermediate builds it can do to break that cycle- literally if=20 USE state validation is in pkg_pretend, the *user* will have to walk=20 the PM through breaking the cycle instead of the PM figuring out the=20 proper steps to break it. Executive summary: if use validation is implemented via pkg_pretend, 1) it still has the iterative issue 2) it's harder for configuration tools to deal with (iterative issues=20 above, plus the fact they get a blob of text they're stuck trying to=20 parse) 3) it pretty much eliminates the possibility of doing use cycle=20 breaking properly (which is already an issue, only going to get worse-=20 hence why this was proposed in '04/'05 when we started playing w/ use=20 deps in portage 3 at the time). Comments desired; assuming no significant blowback, I'll be pushing=20 this to the council level since eapi4 is annoying feature locked right=20 now. Thanks- ~harring --5mCyUwZo2JvN/JJP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEARECAAYFAkuzE+MACgkQsiLx3HvNzgeA4ACggpBqta2DvnuY0QtXign3El4C TFgAmwXlSvpU9XKgUQ3vp8o4ITO/gJyF =CjmV -----END PGP SIGNATURE----- --5mCyUwZo2JvN/JJP--