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 04AD61387FD for ; Wed, 11 Jun 2014 14:22:05 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 40C2BE0BA7; Wed, 11 Jun 2014 14:22:00 +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 5A311E090F for ; Wed, 11 Jun 2014 14:21:59 +0000 (UTC) Received: from [141.23.112.90] (wlan-141-23-112-90.tubit.tu-berlin.de [141.23.112.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: chithanh) by smtp.gentoo.org (Postfix) with ESMTPSA id 446C033FE1D for ; Wed, 11 Jun 2014 14:21:58 +0000 (UTC) Message-ID: <53986609.1050907@gentoo.org> Date: Wed, 11 Jun 2014 16:22:01 +0200 From: =?UTF-8?B?Q2jDrS1UaGFuaCBDaHJpc3RvcGhlciBOZ3V54buFbg==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26 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] Creating a USE_EXPAND for ssl providers References: <53877169.3010800@gentoo.org> <539839A6.9090509@gentoo.org> <20140611151231.304f1f30@pomiot.lan> <539859F2.3020805@gentoo.org> <20140611154537.010bef0e@pomiot.lan> In-Reply-To: <20140611154537.010bef0e@pomiot.lan> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Archives-Salt: 40af53b3-7cf6-4f82-be97-e83fac13105c X-Archives-Hash: 6fb85b3b4fb9ac37bd2b91c00c016867 Michał Górny schrieb: > Dnia 2014-06-11, o godz. 15:30:26 > Chí-Thanh Christopher Nguyễn napisał(a): > >>> 3. There is no clean way of enforcing SSL provider match between >>> packages. Wasn't this thread initially about curl and rtmpdump >>> requiring matching flags? >> It could be enforced if an eclass does the actual choice of crypto >> provider in a reproducible way. That would be not trivial though. > No, it can't. Let's say package A depends on package B and requires > the same SSL provider. > > A has 'openssl gnutls' > B has 'openssl gnutls polarssl' > > Now let's say the eclass prefers polarssl over the other two. How are > you going to make A dep on B? > It is not trivial, but I don't think it is impossible. I had thought of the following, but have not carefully checked that it covers all cases. crypto-providers.eclass would have a list CRYPTO_PROVIDERS_SUPPORTED sorted descending by priority, and A and B would pass in a variable CRYPTO_PROVIDERS the acceptable providers. The eclass would provide functions which expand into USE dependencies to ensure that no higher-prioritized crypto provider is selected in B. Example: crypto-providers.eclass: CRYPTO_PROVIDERS_SUPPORTED="polarssl openssl gnutls libgcrypt libnettle ..." crypto-providers_only() returns USE dependency on its arguments, and negative USE dependencies for all providers with higher priority, e.g. crypto-providers_only(gnutls) returns "-crypto_providers_polarssl(-) -crypto_providers_openssl(-) crypto_providers_gnutls(-)" crypto-providers_match(packagename) returns priority nested USE conditionals for all CRYPTO_PROVIDERS that can be fed into DEPEND, e.g. crypto_providers_match(B) would return "crypto-providers_openssl? ( B[$(crypto_providers-only(openssl)] ) !crypto-providers_openssl? ( crypto-providers_gnutls? ( B[$(crypto_providers-only(gnutls)] ) )" A.ebuild CRYPTO_PROVIDERS="openssl gnutls" DEPEND="$(crypto-providers_match(B))" B.ebuild CRYPTO_PROVIDERS="openssl gnutls polarssl" Best regards, Chí-Thanh Christopher Nguyễn