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 1NxEuQ-0001k0-8B for garchives@archives.gentoo.org; Thu, 01 Apr 2010 07:33:47 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1B034E0B5B; Thu, 1 Apr 2010 07:33:37 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id CB76CE0B53 for ; Thu, 1 Apr 2010 07:33:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 3ECE91B40DF for ; Thu, 1 Apr 2010 07:33:10 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 required=5.5 tests=[AWL=0.480, 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 iBNh8MQe3Ksd for ; Thu, 1 Apr 2010 07:33:03 +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 9F1041B4063 for ; Thu, 1 Apr 2010 07:33:03 +0000 (UTC) Received: by pzk5 with SMTP id 5so267089pzk.0 for ; Thu, 01 Apr 2010 00:33:03 -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=hcbo+/hQHTuYnhCtss59RoIQx2wudXnGHMR+crK6vZY=; b=vfINpMfqOT/ceinOuMocamwQraPD5gOmh1xfDAjMVP3ngdL+iDLmfV50LZM3I4dytT elkFMkBi8BoSJ3f3HFGnm9iswFXjd9gCQ6C5cG4KTHzoGvydqGlJ4vILl77LJ9992Tgz 8RKOHQl7p4ymimQnc58RMMx1IBt/aAmxReqxQ= 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=AUqOAJOw6L/Wrt2MtdiiXid5o2oH6haeg72oUZE1jomDbF4qkbia1qixRVhpKW/Sf4 u1P7aB7XUYppC72RSSm47DcHuTbBQ6KYd8LuNJQO/hZmXWlzFfYEk0SUq1Qonv+4861X TBbDO+buEfMBBakrmZl+vQYdkhd8HX6M60ZdU= Received: by 10.140.255.13 with SMTP id c13mr69258rvi.86.1270107182990; Thu, 01 Apr 2010 00:33: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 22sm1082141pzk.13.2010.04.01.00.33.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 01 Apr 2010 00:33:01 -0700 (PDT) Received: by smtp.gmail.com (sSMTP sendmail emulation); Thu, 01 Apr 2010 00:31:09 -0700 Date: Thu, 1 Apr 2010 00:31:09 -0700 From: Brian Harring To: ciaran.mccreesh@googlemail.com Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] pkg_pretend USE validation and VALID_USE alternative Message-ID: <20100401073109.GI11663@hrair> References: <20100331092035.GA11663@hrair> <20100331174925.GA16267@faith> <20100331194626.GG11663@hrair> <20100331205628.368fb02c@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="FK65GREB+Evh/hTL" Content-Disposition: inline In-Reply-To: <20100331205628.368fb02c@snowmobile> User-Agent: Mutt/1.5.20 (2009-06-14) X-Archives-Salt: 4b14ff0c-471d-4d9e-a725-ba224ad266ab X-Archives-Hash: 10282617f5dd4831192f11df669d75dc --FK65GREB+Evh/hTL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 31, 2010 at 08:56:28PM +0100, Ciaran McCreesh wrote: > On Wed, 31 Mar 2010 12:46:26 -0700 > Brian Harring wrote: > > Actual name I don't hugely care about, I'm more interested in > > ensuring we don't rule out doing use cycle breaking via a bad design > > decision. >=20 > 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. Nonsense. Note I said 'use cycle', not the generic 'cycle breaking'. =20 USE induced cycles don't require explicit instructions from the=20 ebuild at all- the PM itself can search the solution space (toggling=20 flags as needed) to search out a way around the cycle. 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- emerge pkg_a[-X] emerge pkg_a[X] As demonstrated, that cycle is easily broken. A lot of the cycles=20 users run into originate that way also. Reiterating a point you're missing also, any use cycle a user hits is=20 currently requires the *user* to sort it out anyways- what VALID_USE=20 adds is the ability for the package manager to do it itself. As for the "portage is developmentally slow" contribute frankly- per=20 the norm w/ open source, you want something, ultimately you're the one=20 responsible for the work. Less contentious answer, I've already gotten an estimate of 2 weeks=20 out of Luther (the person who has been knocking out EAPI4 features in=20 the last month or so)- I'm not that concerned about it. Actual work=20 is a few days, motivation per the norm is the main time sink. > Since we need pkg_pretend to cover all the things that aren't use flag > related anyway, it makes sense to just go with that rather than > delaying things even further. 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. 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. Soo... as I've described on the bug and here (repeatedly), exempting=20 5-10 cases from the tree, what pkg_pretend enables can either be done=20 better via VALID_USE, or is a degradation due to temporal concerns=20 when you move the code out of pkg_setup. Short version: it's a step backwards. > 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. 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=20 solutions, basically. ~harring --FK65GREB+Evh/hTL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEARECAAYFAku0S70ACgkQsiLx3HvNzgfr7gCdGYg1D4JPekAxxpdMcKm0DEQc FEUAnRrpaWwt9KXjsXs+D0gpoZBruhWo =dj2E -----END PGP SIGNATURE----- --FK65GREB+Evh/hTL--