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 1NxFIG-0003sk-VI for garchives@archives.gentoo.org; Thu, 01 Apr 2010 07:58:25 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 93A5BE0B8C; Thu, 1 Apr 2010 07:58:16 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id C7F00E0A9D for ; Thu, 1 Apr 2010 07:58:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 6E8541B4025 for ; Thu, 1 Apr 2010 07:58:09 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -2.128 X-Spam-Level: X-Spam-Status: No, score=-2.128 required=5.5 tests=[AWL=0.471, 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 65mwpM6DO+Gh for ; Thu, 1 Apr 2010 07:58:02 +0000 (UTC) Received: from mail-pv0-f177.google.com (mail-pv0-f177.google.com [74.125.83.177]) by smtp.gentoo.org (Postfix) with ESMTP id A741A1B40E8 for ; Thu, 1 Apr 2010 07:58:02 +0000 (UTC) Received: by pvf33 with SMTP id 33so272175pvf.36 for ; Thu, 01 Apr 2010 00:58:02 -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:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=dkRY2baTIhMQRrysdcdlssMlvxKEQ41M2zvC7gC8kj4=; b=ekeR4NQ2rW8ecJ49t1YyOszb1UOb2c0DN/og1KsbczwvUE0JAknsE2KYlb1ZBBKN2b 15KEidXWIxWR26bEMn+dP29yNQqtWv8EOQz/zJGVfHSGumuvf4kaFHwkb/Bx79OvbR2S mkaKVTdlfSMbK48jGa8blZx5v1rKUyvPAqW5g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=tc2q/PeaJ3xVLJAsyBUSdByV7AY+OJ5tagBpoAA+y3cm7RfnR90DNB3kStSO5+5h/w /KL8balt0rP77ykLYDB3le+8xIuHWRUvclO2MSJRtmrnYl/LGcRv3976EJMWG4l06U9O Oov3IiAg9ZqemQm+R0xoT+QHPteAwIqx8o6WY= Received: by 10.141.188.24 with SMTP id q24mr2431051rvp.0.1270108682063; Thu, 01 Apr 2010 00:58:02 -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 22sm1098271pzk.9.2010.04.01.00.57.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 01 Apr 2010 00:58:01 -0700 (PDT) Received: by smtp.gmail.com (sSMTP sendmail emulation); Thu, 01 Apr 2010 00:56:08 -0700 Date: Thu, 1 Apr 2010 00:56:08 -0700 From: Brian Harring To: Ciaran McCreesh Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] pkg_pretend USE validation and VALID_USE alternative Message-ID: <20100401075608.GJ11663@hrair> References: <20100331092035.GA11663@hrair> <20100331174925.GA16267@faith> <20100331194626.GG11663@hrair> <20100331205628.368fb02c@snowmobile> <20100401073109.GI11663@hrair> <20100401084102.2560f3a3@snowmobile> 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="Ah9ph+G2cWRpKogL" Content-Disposition: inline In-Reply-To: <20100401084102.2560f3a3@snowmobile> User-Agent: Mutt/1.5.20 (2009-06-14) X-Archives-Salt: e09ed52a-4566-4108-a289-4a6bd4d838b7 X-Archives-Hash: 4917457adcefc6325a879e67c420893a --Ah9ph+G2cWRpKogL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 01, 2010 at 08:41:02AM +0100, Ciaran McCreesh wrote: > On Thu, 1 Apr 2010 00:31:09 -0700 > > As demonstrated, that cycle is easily broken. A lot of the cycles=20 > > users run into originate that way also. >=20 > Congratulations. You just turned on 'build' and 'bootstrap', and turned > off 'acl'. Actually, I'm well aware I did. See, if PMS wasn't developed in a=20 void you'd know build, bootstrap, acl and friends were already a known=20 issue with use cycle breaking. Thing is, in checking the problem through we couldn't find a single=20 instance where it was the *wrong* thing to do. Build, boostrap, acl, etc, they're relevant only when you've got=20 basically a from scratch system, or are rebuilding enough things you=20 need to revert to that level. Meaning it's the right damn thing to do- same thing the user would=20 have to do. > > And as I've already laid out in the bug, pkg_pretend has it's own set= =20 > > of issues when compared to pkg_setup due to it being non temporal,=20 > > thus having high false positive potentials. >=20 > These are exactly the same issues that pkg_setup has. You can't block a > useful feature simply because developers could theoretically screw > things up by using it. Ciaran, seriously stop lieing. Your own words disprove this claim,=20 I quote from pms/ebuild-functions.tex: """ The \t{pkg\_pretend} function may be used to carry out sanity=20 checks early on in the install process. For example, if an ebuild=20 requires a particular kernel configuration, it may perform that check in \t{pkg\_pretend} and call \t{eerror} and then \t{die} with=20 appropriate messages if the requirement is not met. \t{pkg\_pretend} is run separately from the main phase function=20 sequence, and does not participate in any kind of environment saving.=20 There is no guarantee that any of an ebuild's dependencies will be met at this stage, and no guarantee that the system state will not=20 have changed substantially before the next phase is executed. """ It's ironic that the only example PMS can give for this functionality=20 is als one that should not be implemented in pkg_pretend, but I=20 digress. Pure/simple, as I've explained repeatedly: pkg_setup: ran just before the build of the pkg, after the pkg's=20 DEPENDS are all built. Meaning you *can* do has_version checks,=20 kernel config checks, etc, because the proceeding deps are now=20 satisfied. pkg_pretend: ran before *every* *single* *build* has been ran, meaning=20 the has_version check, the kernel config check, etc, all can invalidly=20 die. Had they been pkg_setup (check after DEPENDs are satisfied), the=20 majority of the checks would pass, but because they're ran prior to=20 DEPENDs satisfied, users will have to wind up breaking what was a=20 single emerge invocation into multiple to satisfy pkg_pretend being=20 wrong. > > The main council push for pkg_pretend was to move use constraint=20 > > checking to pre build. VALID_USE does that cleaner and enabling use=20 > > cycle breaking to be built; as such I'm pushing it up to them unless=20 > > someone can find significant *real* flaws. >=20 > No, VALID_USE addresses a *subset* of the issues. It's not a > replacement for pkg_pretend. Cherry picking the argument again. Main !=3D whole, meaning the=20 majority reason I could see w/in council logs for supporting=20 pkg_pretend was USE constraint validation. As I've said, and as you seem to finally understand, VALID_USE isn't a=20 replacement for pkg_pretend- it just replaces the *main* usage of it. > > > When in the distant future Portage > > > becomes able to deal with cycle breaking, ebuilds can be converted > > > to use something like VALID_USE when they're also updated to export > > > information on which of their flags can safely be toggled. > >=20 > > You're being short sighted. VALID_USE is useful now for representing= =20 > > use states that are allowed; that data itself is useful for use cycle= =20 > > breaking. Added bonus of enabling better functionality via a > > superior solutions, basically. >=20 > Simply adding VALID_USE won't let you do cycle breaking. You also need > extensive lists of which flags for which packages can safely be toggled > and when without breaking the system, and the only way you'll get those > lists is if developers care enough to update their ebuilds to provide > them. That's one view, but sure, I'll run with it. The thing is, *without* VALID_USE you cannot do use cycle breaking=20 *period*. executable vs data for the representation of the=20 constraints (as I've spelled out for you 3 times now). So your arguement against VALID_USE basically comes down to "it may=20 not be able to do USE cycle breaking"- fine, I disagree, but whatever. =20 pkg_pretend however completely disallows even *doing* use cycle=20 breaking. How in the hell is that a better next step? ~harring --Ah9ph+G2cWRpKogL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEARECAAYFAku0UZgACgkQsiLx3HvNzgey7ACfUcO+RAeUZovm4TaFD+/fmYVv i3UAoITnvYqxnRrvAGK74poP6RfNqcu2 =0vcv -----END PGP SIGNATURE----- --Ah9ph+G2cWRpKogL--