From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 175301389F5 for ; Thu, 2 Apr 2015 18:03:05 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 61928E085D; Thu, 2 Apr 2015 18:03:04 +0000 (UTC) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id EAEA5E07F0 for ; Thu, 2 Apr 2015 18:03:03 +0000 (UTC) Received: by igbud6 with SMTP id ud6so83341390igb.1 for ; Thu, 02 Apr 2015 11:03:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=97EW0Vystqv1ShefMcIEdD4CmcG40E5oXDjGnhMIt5E=; b=E/N6RZI2Z79np/LNYWAbhyfYjlYe+gyHM3V1MEYTujZ0X+LRBel4J292z3qCd2UTlR AuSoyuNnDt1xvhGif88jhzkbcHGMR3jrqGlt9OIgPCN9uLHhAEOqnlCbf6bVf1GGTijf 4pnvHxQC5S+jlzGI8pzzjugq9KIHL/h0PTLxp8IGRphixunSqnzwYYeEEferbnRvF6bB 9Lz9QhjDEAUeCNyW4SMJAHNJPVxMyvNt2IY6wCXq8rWYAkPFKpfpKvBdOVPCtF/+FFhO RGGs6hSRF4Od3+EpipckGUrGZY9TYxjPQuNZwxKlthdajjMQPw2zuZKSzSlqfdHT/Geo lmLQ== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-portage-dev@lists.gentoo.org Reply-to: gentoo-portage-dev@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.107.3.167 with SMTP id e39mr32913471ioi.92.1427997783321; Thu, 02 Apr 2015 11:03:03 -0700 (PDT) Received: by 10.64.33.239 with HTTP; Thu, 2 Apr 2015 11:03:03 -0700 (PDT) In-Reply-To: References: Date: Fri, 3 Apr 2015 07:03:03 +1300 Message-ID: Subject: Re: [gentoo-portage-dev] Dynamic USE dependencies From: Kent Fredric To: gentoo-portage-dev@lists.gentoo.org Content-Type: multipart/alternative; boundary=001a113ed4389d74c50512c1a497 X-Archives-Salt: ced8f739-ea73-409f-93e3-297862bca275 X-Archives-Hash: e512e8d8a0c40d29d44134d34c22bd8e --001a113ed4389d74c50512c1a497 Content-Type: text/plain; charset=UTF-8 On 3 April 2015 at 06:32, Rich Freeman wrote: > Why is this necessary? If a USE flag changes, just rebuild the > application. > Isn't the nature of your proposal,( that is, dynamic deps for USE flags ) inherently "Use flags change, _dont_ rebuild the application" ? :) It may help to think in terms of : Any ebuild without IUSE="foo" , once installed, actually has a property of USE_foo=undef Once an ebuild has IUSE="foo", the installed package then can subsequently get USE_foo=y USE_foo=n So under that logic, adding a new IUSE implies "Use flag changes" ( either from state undef to y , or state undef to n ). We have mechanisms for other ebuilds to declare what USE_foo=undef means in dependency defaults: >=X[foo(+)] # Assume USE_foo = undef to mean USE_foo = y >=X[foo(-)] # Assume USE_foo = undef to mean USE_foo = n There's just no mechanism similar to that for an ebuild with CVS revision 02 to declare what USE_foo = undef meant on ebuild with CVS revision 01 Nor is there a way to express what USE_foo=undef meant on X<$PV ( And subsequently, there is no user visible way /in portage/ for portage to express the meaning of a new USE flag becoming visible ) So I'm basically having trouble with groking the logic you're proposing of "add a new use flag" -> "implied change of useflag" -> "rebuild when useflags change" -> "but don't rebuild for this useflag change using some kind of magic" ( Mostly due to the implied-change via addition I can't seem to ignore ) -- Kent *KENTNL* - https://metacpan.org/author/KENTNL --001a113ed4389d74c50512c1a497 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On 3 April 2015 at 06:32, Rich Freeman <rich0@gentoo.org> wro= te:
Why is this necessary?=C2=A0 If a USE f= lag changes, just rebuild the application.


Isn't the nature of your proposal,( that is, dynamic d= eps for USE flags ) inherently "Use flags change, _dont_ rebuild the a= pplication" ? :)

It may help t= o think in terms of : Any ebuild without IUSE=3D"foo" , once inst= alled, actually has a property of USE_foo=3Dundef

Once an ebuild has IUSE=3D"foo", the installed p= ackage then can subsequently get

U= SE_foo=3Dy
USE_foo=3Dn


So under that logic, adding a new IUSE implies = "Use flag changes" ( either from state undef to y , or state unde= f to n ).

We have mechanisms for ot= her ebuilds to declare what USE_foo=3Dundef means in dependency defaults:
=C2=A0=C2=A0=C2=A0 >=3DX[foo(+)]= =C2=A0=C2=A0 # Assume USE_foo =3D undef to mean USE_foo =3D y
=C2=A0=C2= =A0=C2=A0 >=3DX[foo(-)]=C2=A0=C2=A0 # Assume USE_foo =3D undef to mean U= SE_foo =3D n

There's just no me= chanism similar to that for an ebuild with CVS revision 02 to declare what = USE_foo =3D undef meant on ebuild with CVS revision 01


Nor is there a way to express what USE_foo=3Dundef= meant on=C2=A0 X<$PV



( And subsequently, there is no user visible way /in = portage/ for portage to express the meaning of a new USE flag becoming visi= ble )

So I'm basically having t= rouble with groking the logic you're proposing of "add a new use f= lag" -> "implied change of useflag" -> "rebuild w= hen useflags change" -> "but don't rebuild for this usefla= g change using some kind of magic"

( Mostly due to the implied-change via addition I can't seem to i= gnore )


--
Kent=

--001a113ed4389d74c50512c1a497--