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 AA25C13877A for ; Sun, 3 Aug 2014 22:44:42 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 827D1E08C6; Sun, 3 Aug 2014 22:44:35 +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 7F87DE085D for ; Sun, 3 Aug 2014 22:44:34 +0000 (UTC) Received: from pomiot.lan (77-253-194-255.adsl.inetia.pl [77.253.194.255]) (using SSLv3 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 3D0E333FFF7; Sun, 3 Aug 2014 22:44:32 +0000 (UTC) Date: Mon, 4 Aug 2014 00:44:50 +0200 From: =?ISO-8859-2?B?TWljaGGzIEfzcm55?= To: gentoo-dev@lists.gentoo.org Cc: pms-bugs@gentoo.org, dev-portage@gentoo.org Subject: [gentoo-dev] The meaning of || ( a:= b:= ) dependencies Message-ID: <20140804004450.5aa146ec@pomiot.lan> Organization: Gentoo X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.24; x86_64-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-sha512; boundary="Sig_/y9ZlJjG/aPYw=+S6G+OieEL"; protocol="application/pgp-signature" X-Archives-Salt: 3411b57b-26fa-4e8f-a885-4a145d767ee3 X-Archives-Hash: 81a4e1a1f5767e20009628ecd33da8d4 --Sig_/y9ZlJjG/aPYw=+S6G+OieEL Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Hello, everyone. I would like to hear your opinion on what should be the meaning and use of '|| ( A:=3D B:=3D )' dependencies. 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. With help of subslots and virtuals we were able to partially solve the issue. For example, look at virtual/libudev. It binds subslot of the virtual to matching subslots of provider libraries. This way, you can safely switch providers as long as they have matching ABI; and if you want to upgrade the provider to another ABI version, you need to upgrade the virtual as well, and therefore rebuild the revdeps. Sadly, virtuals like this can only work when you can expect providers to have matching ABIs. This won't happen e.g. in krb5 providers (the two have incompatible ABIs) or libav* providers (ABIs of some of the libraries differ from version to version). At the moment, some developers already started mixing subslot and any-of operator syntax: || ( A:=3D B:=3D ) However, this breeds a really weird behavior in Portage. With static dependency model, it's partially understandable. ':=3D' atoms are expanded into specific subslots when matching package is installed, otherwise left unspecified. 'Unspecified' here means that any subslot satisfies the dependency -- like it was plain 'A' or 'B'. So, if during the build only A was installed, further upgrades to A can cause subslot rebuilds. If only B was installed, rebuilds are caused by B likewise. However, if afterwards the other package is installed, it satisfies the other branch of the dependency without subslot, so package doesn't get rebuild on any upgrades of A or B (since the unspecific dep always matches). This happens until the package is manually rebuild and gets the other subslot written. Even more curious behavior is caused if both A and B are installed at build time. In this case, subslots for both packages are expanded. And since || means that either of the branches must match, the subslots of both packages must change for the package to trigger subslot rebuild. In other words, || ( A:=3D B:=3D ) means that subslot rebuilds happen only if you consistently use a single provider. Provider switching or having both providers installed break it. Dynamic deps partially fix it. Since the current :=3D support code is very dumb, it doesn't notice the '||' and respects all expanded subslots found in vardb. The main difference is that installing the other dependency doesn't prevent subslot rebuilds from the first one from happening. For example, if you built the package against A and install B afterwards, upgrade of A will still force rebuild of the package (because dynamic-deps code accidentally moves the A:0/1=3D dep out of || ()). The code also makes the behavior with both providers installed saner. Since both subslots are expanded, both are copied and rebuild of either would cause the rebuild of package. However, in practice it usually causes emerge to fail with slot conflict :). It should be also noted that the dyndeps behavior makes it impossible to uninstall either A or B when both were installed at the reverse dependency build time (since both are added to depgraph). The question would be -- which behavior is desired? I'm pretty sure Ciaran will say that the static dep behavior is correct per definitions but I don't think it's really useful to have slot operator dependencies which work only randomly. Instead, we may decide to redefine it into something useful in a future EAPI. In particular, I was thinking we could reuse this syntax: || ( A:=3D B:=3D ) to express any-of dependencies that do not support runtime switching of providers -- since that is pretty much what :=3D does to slots. This would save us from creating a new syntax like '||=3D ()' [1]. [1]:https://bugs.gentoo.org/show_bug.cgi?id=3D489458 If we go this way, we also need to decide whether the order in such block would matter or not. In other words, whether the application can be expected to link to the first installed package in the list, or can link to any of them. If the order would matter, the package would need to be rebuilt when: 1. first satisfied dependency changes subslot, 2. [optionally] package preceding the first currently satisfied dependency is installed, 3. first currently satisfied dependency is uninstalled (but another is installed). If the order wouldn't matter, the package would need to be rebuilt when: 1. any of satisfied dependencies changes subslot (since we don't know which one package links to), 2. [optionally] any of the remaining packages is installed, 3. any of satisfied dependencies is uninstalled. The first option seems more refined, and causes less rebuilds. However, it diverges further from the basic || () definition. The second tries to fit || () and :=3D with minimal changes. Remaining issues: a. behavior of || ( A:=3D B:=3D C ) -- should C cause complete provider switching rebuilds? b. do we need ||=3D ( A B C ) -- i.e. provider switching rebuilds without subslot rebuilds? What do you think? --=20 Best regards, Micha=B3 G=F3rny --Sig_/y9ZlJjG/aPYw=+S6G+OieEL Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJT3rtmXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2REJCMDdDQzRGMERBRDA2RUEwQUZFNDFC MDdBMUFFQUVGQjQ0NjRFAAoJELB6GurvtEZODr0P/0TuJpipoIkwjrGis0bUw3Vv oaJuIC/CWbqwS0PwUQGWZEYKI1Ovi65w+S2QN+0FoX3ZOhEgIv0hzxoRTqtZls1f /Yprvw5iuZ2Jj7JifbAeX9Jrp+o14uy1Szq1v8ek3JA9BM3DC6J0gjRHYICboGv8 BBpuYBnM6R81SiN1MPRpJ9DA58Cv7Qff4XNdp1PAeRW0mRwhvKfmTqmEwtErVNPD F06smtEpccA5hiPNjTUsz6QyB1WSOBCtYi0/AvI4X287kNnX2rw6IyfmohDDTiju tdQVDeukWfDQIZTP1OoBHShc+wKPk8Hlr9YA/55gegBcePlRW+kTVTKobEJOhDTN 3Fb0yBKxQHqXPSYGNRcfFo1q+caZbqEf3oHCGebPe+X/EGGmnoD8/gyl6/BN9gUf nm27dlbzh1r1/FYXnv7aK/571rutJ/1ixmdgQvDicpq50wb48H6137MCNFJhdQoK GsUpxKN7Vqw6PVLQNQXHl6MqitD8ZD3niGXrq8FsJBV6Ui7sn7xONq69evBd8bKS obKNuL+tLUqDoMnr0w2C4wuvqkPZDaF7TsrGezwX5SbpsusExHKf+Xf75Sh0gNRQ j9QwNrBW88l+bfug5iEHJaVCdBdPCQo9aED52IeN4IDgFOHqHVEbqC+i9i/UsZkM 1n+r+ttmp3Oa+0fkOjn8 =KhPq -----END PGP SIGNATURE----- --Sig_/y9ZlJjG/aPYw=+S6G+OieEL--