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 1NxF1w-0002L3-IC for garchives@archives.gentoo.org; Thu, 01 Apr 2010 07:41:32 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EE5A8E0929; Thu, 1 Apr 2010 07:41:29 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 1837DE08C2 for ; Thu, 1 Apr 2010 07:41:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id A7EF91B408C for ; Thu, 1 Apr 2010 07:41:25 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 required=5.5 tests=[AWL=0.000, 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 AlrOLYMPyXdQ for ; Thu, 1 Apr 2010 07:41:19 +0000 (UTC) Received: from mail-bw0-f222.google.com (mail-bw0-f222.google.com [209.85.218.222]) by smtp.gentoo.org (Postfix) with ESMTP id CC1091B4106 for ; Thu, 1 Apr 2010 07:41:18 +0000 (UTC) Received: by bwz22 with SMTP id 22so696687bwz.25 for ; Thu, 01 Apr 2010 00:41:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=ZiS7EzLgWk2I9IBqNLzrZtYZXkZwYu9r3K7GcbB2yXY=; b=P14+p5nuzhMTEt8SF3AZncXi+B1ZoEQLyJqS01Dveh1ot7yJsKoGydy+UG1WMiqfsT 8wC0PcaokWC2yL89uVWJBAhyrQbs6t0XtVa+NCzp/pYnh+HvEAgbJ9wuln/ndXLCGCjf li+Ln+Bi8jGImS1bveazl2IsZvYUVkSL3pO5w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=jgLIe06HLT7dxkM94xjulCCuRboF+sCHm9F4s67J3uApnGNHw6I+rAoZ2PZ2/Jy11F H6Nt6yteBb4UMwO7JFKXl5HOs8q0aDjrAz4iGg/ybGL9QucrXdS8wWdPlLag4vCdm6eQ +K3k83smJ7cKTK1G/MwpuZe7XIy1LLuo5zoNk= Received: by 10.204.135.151 with SMTP id n23mr907116bkt.43.1270107677116; Thu, 01 Apr 2010 00:41:17 -0700 (PDT) Received: from snowmobile ([92.24.222.23]) by mx.google.com with ESMTPS id s17sm64942495bkd.4.2010.04.01.00.41.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 01 Apr 2010 00:41:16 -0700 (PDT) Date: Thu, 1 Apr 2010 08:41:02 +0100 From: Ciaran McCreesh To: Brian Harring Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] pkg_pretend USE validation and VALID_USE alternative Message-ID: <20100401084102.2560f3a3@snowmobile> In-Reply-To: <20100401073109.GI11663@hrair> References: <20100331092035.GA11663@hrair> <20100331174925.GA16267@faith> <20100331194626.GG11663@hrair> <20100331205628.368fb02c@snowmobile> <20100401073109.GI11663@hrair> X-Mailer: Claws Mail 3.7.4 (GTK+ 2.18.5; i686-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: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/2=PSFhrT6XxmqIw8mqsZmRH"; protocol="application/pgp-signature" X-Archives-Salt: 15bf9aab-d3c3-48f2-8bf7-689852820e7d X-Archives-Hash: e6aa85a63c62b5c4d26d300504cb5d98 --Sig_/2=PSFhrT6XxmqIw8mqsZmRH Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 1 Apr 2010 00:31:09 -0700 Brian Harring wrote: > > Cycle breaking requires explicit instructions from the ebuilds in > > question (many of which are system things, which further > > complicates it) along with support from Portage, so it's a distant > > future, lot of work thing. >=20 > Nonsense. Note I said 'use cycle', not the generic 'cycle > breaking'. USE induced cycles don't require explicit instructions > from the ebuild at all- the PM itself can search the solution space > (toggling flags as needed) to search out a way around the cycle. >=20 > Consider user configuration w/ USE=3DX, pkg_a w/ DEPEND "X? ( pkg_b )",=20 > pkg_b w/ DEPEND "pkg_a". To be clear, you're claiming that the=20 > ebuild itself (and only the ebuild) is the the one able to state- >=20 > emerge pkg_a[-X] > emerge pkg_a[X] >=20 > As demonstrated, that cycle is easily broken. A lot of the cycles=20 > users run into originate that way also. Congratulations. You just turned on 'build' and 'bootstrap', and turned off 'acl'. > 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. 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. > 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. No, VALID_USE addresses a *subset* of the issues. It's not a replacement for pkg_pretend. > > 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. 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. --=20 Ciaran McCreesh --Sig_/2=PSFhrT6XxmqIw8mqsZmRH Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAku0ThEACgkQ96zL6DUtXhHmYACfZvr19dg1YjlZNqfKMCenRscc 4rQAnir6ZkPUyQ+t6z78RBwHdv3vVGER =fZaf -----END PGP SIGNATURE----- --Sig_/2=PSFhrT6XxmqIw8mqsZmRH--