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 6639D13877A for ; Mon, 4 Aug 2014 00:41:57 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BDFC2E09CD; Mon, 4 Aug 2014 00:41:52 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id D141BE09C3 for ; Mon, 4 Aug 2014 00:41:49 +0000 (UTC) Received: from [192.168.1.130] (bas1-ottawa09-2925288101.dsl.bell.ca [174.92.90.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: axs) by smtp.gentoo.org (Postfix) with ESMTPSA id D67EA33F8BF for ; Mon, 4 Aug 2014 00:41:48 +0000 (UTC) Message-ID: <53DED6C6.6090506@gentoo.org> Date: Sun, 03 Aug 2014 20:41:42 -0400 From: Ian Stakenvicius User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] The meaning of || ( a:= b:= ) dependencies References: <20140804004450.5aa146ec@pomiot.lan> In-Reply-To: <20140804004450.5aa146ec@pomiot.lan> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 8bit X-Archives-Salt: b21eef19-61c5-489a-9f03-d6140d1e848b X-Archives-Hash: c609f062bde5243d871f88e9d30c080f -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/08/14 06:44 PM, Michał Górny wrote: > Hello, everyone. > > I would like to hear your opinion on what should be the meaning and > use of '|| ( A:= B:= )' dependencies. [ Snip! ] I mentioned this on irc on Friday; as I understand it the following should occur. Preface: A-1.0's SLOT="0/1" A-2.0's SLOT="0/2" B-1.0's SLOT="4" B-2.0's SLOT="5" When the package is built and merged, it's built against SOMETHING that satisfies ||( A:= B:= ); this means A or B or both are installed. In the Portage implementation the slot of dependencies are recorded in VDB, and so whatever is installed on the system at compile/merge time is what gets recorded to VDB. It's not possible for Portage to know which atom in the ||() list, so VDB needs to match the current state. Case 1 - both A and B are installed - if A-1.0 upgrades to A-2.0, or B-1.0 upgrades to B-2.0, then rebuilds need to be triggered. This should be detectable because A:0/1 and B:4 are recorded in VDB. The fact that they are in a ||() block SHOULD NOT allow the not-upgrading B:4 to keep the dep satisfied if A-1.0 upgrades to A-2.0. Likewise, if either A or B are removed, then the package needs to be rebuilt (once again, it is not known which dep might affect how the package is linked). Case 2 - only A is installed - if A-1.0 upgrades to A-2.0 when B isn't installed at all, this should trigger a rebuild. Hopefully this is what is happening now in all cases. If A-1.0 stays around and B is installed, nothing needs to happen because the package is still linked against A-1.0. However, If A is then removed (say it's dropped from @world and then --depclean'ed), THEN a rebuild needs to be triggered so that a proper (slot) dependency is recorded against B. If A is upgraded after B is installed, then a rebuild needs to be triggered and we end up with Case#1. One thing that is a bit unique with case#2 is that, due to the fact that the subslot is recorded in VDB at merge time, we actually know which atom is satisfying the ||() dep, and so the changes and/or state of the other atom doesn't need to have any affect on this package until the atom that we built against is adjusted (upgraded, removed). > > By the PMS-y definition, any-of dependency can be satisfied by > either branch of it, and the provider can be safely switched at > runtime. That is: > > || ( A B ) > > means that either a or b has to be installed. If you built the > package against A, you can install B, uninstall A and everything is > supposed to work without rebuilding. That doesn't really happen > when linking is involved. Hmm.. that "safely switched at runtime" language technicality might be something we should just honour, since with that in mind " || ( A:= [anything] ) " isn't a valid syntax, if it can only be used for runtime-switchable providers. PMS-wise it may be pertinent to use another operator than || (ie ||= as suggested) to specify a run-or-compile-time-switchable set of atoms. Of course, that means we need to wait for a new EAPI and then rewrite all inappropriate uses of || in the tree, since i believe most ||'s are in fact runtime-or-compiletime-switchable, rather than -just- runtime-switchable. > [ Snip! ] Remaining issues: > > a. behavior of || ( A:= B:= C ) -- should C cause complete > provider switching rebuilds? As per my cases above, no I don't think C should have any effect when it's installed. However, if A or B are removed then the removal should trigger a rebuild. > b. do we need ||= ( A B C ) -- i.e. provider switching rebuilds > without subslot rebuilds? Technically, no I don't think we would need provider-switching-rebuilds without subslot-rebuilds, but that only works if everything in the tree migrates to EAPI5 and implements subslots... Since that's unlikely, though, it might be worth considering.. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlPe1sYACgkQ2ugaI38ACPAWiQD/TAilNp7CE5hCaoDikX5ZlSrc GBpx29M6zvmICsS2dqsBALce6lWlMlBFkRjNJ29XykevaRJIjVSHpsExnJiT5c8R =UDaD -----END PGP SIGNATURE-----