From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 83F2C1382C5 for ; Tue, 20 Feb 2018 02:46:07 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EC067E0DCC; Tue, 20 Feb 2018 02:46:01 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (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 8F1A5E0B15 for ; Tue, 20 Feb 2018 02:46:01 +0000 (UTC) Received: from [10.40.36.23] (unknown [69.42.190.222]) (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 638E4335C0C for ; Tue, 20 Feb 2018 02:45:58 +0000 (UTC) Subject: Re: [gentoo-dev] EAPI 7 in Portage needs YOU! To: gentoo-dev@lists.gentoo.org References: <6A1DC1CD-A6F2-4094-BAD9-7D3F413EE769@gentoo.org> <529f4885-9044-db40-6471-a747bf0ac131@laposte.net> <23179.2743.643298.244147@a1i15.kph.uni-mainz.de> <1519068755.31483.0.camel@gentoo.org> <1519069121.1104.9.camel@gentoo.org> From: Ian Stakenvicius Openpgp: id=A2C4D5C5A3D795BF11CB1838DAE81A237F0008F0 Message-ID: Date: Mon, 19 Feb 2018 21:45:41 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.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 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dNxd8MWvnoSiXoXNhP4VvV00arR1quQHC" X-Archives-Salt: fc723ffb-27c7-4302-b8f1-b86965dba853 X-Archives-Hash: 5b84147af025ad1d1fafcb8c9de824be This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dNxd8MWvnoSiXoXNhP4VvV00arR1quQHC Content-Type: multipart/mixed; boundary="8q4y3d1ct1jsNcQ5sPbId7lTIsyNGaXs9"; protected-headers="v1" From: Ian Stakenvicius To: gentoo-dev@lists.gentoo.org Message-ID: Subject: Re: [gentoo-dev] EAPI 7 in Portage needs YOU! References: <6A1DC1CD-A6F2-4094-BAD9-7D3F413EE769@gentoo.org> <529f4885-9044-db40-6471-a747bf0ac131@laposte.net> <23179.2743.643298.244147@a1i15.kph.uni-mainz.de> <1519068755.31483.0.camel@gentoo.org> <1519069121.1104.9.camel@gentoo.org> In-Reply-To: --8q4y3d1ct1jsNcQ5sPbId7lTIsyNGaXs9 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 2018-02-19 07:19 PM, Michael Lienhardt wrote: >=20 >=20 > Il 19/02/2018 20:38, Micha=C5=82 G=C3=B3rny ha scritto: >> W dniu pon, 19.02.2018 o godzinie 21=E2=88=B632=E2=80=89+0200, u=C5=BC= ytkownik Mart Raudsepp >> napisa=C5=82: >>> On Mon, 2018-02-19 at 18:34 +0100, Ulrich Mueller wrote: >>>> It is explained in section 8.2.4: >>>> https://dev.gentoo.org/~ulm/pms/7-draft/pms.html#x1-800008.2.4 >>> >>> Maybe I missed this, but a real world use case example would be nice,= >>> maybe someone feels a harder itch to scratch then :) >>> >> >> The original use case was for providers-like thingies, e.g.: >> >> =C2=A0=C2=A0 ||=3D ( ffmpeg:0=3D libav:0=3D ) >> >> That said, I'd personally prefer doing that with proper USE_EXPAND >> and REQUIRED_USE enforcing but this has been rejected. >> >=20 > So, if I understand correctly, the ||=3D group is an "or" that must be > resolved in the same way in the DEPEND and RDEPEND dependencies, right?= >=20 > The documentation does not specify how this group interacts between > different ebuilds. > I guess there is no interaction, but just to be sure, let consider the > following corner-case example: > =C2=A0- a package A has RDEPEND=3D||=3D ( ffmpeg:0=3D libav:0=3D ) whil= e another > package B has DEPEND=3Dffmpeg > =C2=A0- the solver choose libav to solve the dependency of the first > package and ffmpeg to solve the second, removing ffmpeg afterward > =C2=A0- will package A break? >=20 > Michael Lienhardt I don't think interaction with other ebuilds is necessarily important, or at least, not any different as what occurs with a package manager decides to do something with the bound atom. Using your example of pkg-A built with libav:0=3D bound: 1- ffmpeg is merged (lets ignore that ffmpeg blocks libav for now) -- this wouldn't change anything regarding pkg-A as it is currently merged, but if pkg-A is re-emerged for whatever reason then I believe the package manager needs to decide according to the rules to build against ffmpeg. 2- libav is unmerged -- pkg-A is broken. It's likely up to the PM implementation what to do here. In the case of portage, and the libav-unmerge being a soft-blocker, I believe the behaviour would be to trigger a re-emerge of pkg-A which would then through standard dependency resolution decide that it will now depend on ffmpeg. An alternative would be to upgrade the soft-blocker to a hard-blocker since pkg-A is bound to libav:0=3D and so it can't be resolved automatically. A manual unmerge likely should trigger something about pkg-A too but even in portage's case the user can do that and break dependencies, so it's not obvious to me what would be done. Now, since ffmpeg and libav do block eachother, the switch from one to another would trigger both of these cases which IMO would mean portage would therefore rebuild pkg-A after ffmpeg is emerged (and libav would be unmerged before ffmpeg is merged). And the multi-ebuild interaction that you speak of would simply force ffmpeg as a hard dependency in resolution, triggering the soft-block and therefore the rebuild. EAPI7 is TL;DR for me right now but I assume that it doesn't specify a required action for "package broken"? --8q4y3d1ct1jsNcQ5sPbId7lTIsyNGaXs9-- --dNxd8MWvnoSiXoXNhP4VvV00arR1quQHC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iIUEAREIAC0WIQSixNXFo9eVvxHLGDja6BojfwAI8AUCWouL1Q8cYXhzQGdlbnRv by5vcmcACgkQ2ugaI38ACPCxdQD+JRvo7d+oznB1BlC1kmjUwBgMx/cThin6sNuM NTDUka4BAKXMKwZpVvw86rUpiyDZkyaQZ9oluhEfR/JI/CgOXUct =x7QD -----END PGP SIGNATURE----- --dNxd8MWvnoSiXoXNhP4VvV00arR1quQHC--