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 3C22D1381FA for ; Fri, 30 May 2014 14:06:02 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9E27CE088D; Fri, 30 May 2014 14:05:56 +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 98323E0888 for ; Fri, 30 May 2014 14:05:55 +0000 (UTC) Received: from [192.168.1.130] (CPE002401f30b73-CM78cd8ec1b205.cpe.net.cable.rogers.com [99.224.181.112]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: axs) by smtp.gentoo.org (Postfix) with ESMTPSA id 80DC033FDA7 for ; Fri, 30 May 2014 14:05:54 +0000 (UTC) Message-ID: <53889041.9070708@gentoo.org> Date: Fri, 30 May 2014 10:05:53 -0400 From: Ian Stakenvicius User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.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] Re: Creating a USE_EXPAND for ssl providers References: <53877169.3010800@gentoo.org> <9C490A66-E7CF-4E60-AAAA-57DC0165A7ED@gentoo.org> <53887384.3060404@gentoo.org> In-Reply-To: <53887384.3060404@gentoo.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 80660b9e-2bf8-4750-ba63-32ca969524d6 X-Archives-Hash: 34f528fbe3d33b17e4411e65677c6f7d -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 30/05/14 08:03 AM, Anthony G. Basile wrote: > On 05/29/14 23:21, Ian Stakenvicius wrote: >> USE_EXPAND generally works or is meant to work when all >> participating ebuilds are ok with working from the exact same set >> of flags. > > Not at all. There are a several counter examples but one > particularly close to what I'm proposing is LINGUAS. Look at how > it is used in postgresql-base: > > LINGUAS="af cs de en es fa fr hr hu it ko nb pl pt_BR ro ru sk sl > sv tr zh_CN zh_TW" > > for lingua in ${LINGUAS} ; do IUSE+=" linguas_${lingua}" done > > Only a few of the 251 linguas listed in profiles/desc/linguas.desc > are used. > That's a bit of a different case -- if a package doesn't support any of the LINGUAS that a user chooses, then the user just gets the package that would be the same as having LINGUAS unset. And this is perfectly fine, because everything (afaik) provides either 'en' or an unspecified 'C' type locale by default. If a user has i.e. SSL="polarssl" in make.conf and emerges things that don't have polarssl on their list, then those things won't have SSL support at all, right? > > Fallback logic would have to be on a per ebuild basis. It makes > no sense otherwise. Eg. There is no preferred ssl provider for > curl and USE=ssl there simply means "curl will have an ssl layer" > without prejudice as to the backend that will provide that ssl > layer. > I thought the main purpose of this was to avoid a bunch of per-package fallback logic? IE, what's the difference in using the SSL use expand here, or just having packages directly IUSE="+ssl gnutls +openssl nss polarssl" with standardized global use flags? the only consistency that I see the SSL use-expand providing is an enforcement of the flags that will be used to identify a particular implementation, and i'm pretty sure we already have that... > > No. What's wrong with > > REQUIRED_USE=" ssl? ( ^^ ( curl_ssl_axtls curl_ssl_cyassl > curl_ssl_gnutls curl_ssl_openssl curl_ssl_nss curl_ssl_polarssl > curl_ssl_winssl ) )" > Nothing at all, but I don't see a generic global SSL USE_EXPAND adding any particular benefit, either. What are the intended benefits to this, besides aesthetics?? USE_EXPANDs are meant to be globally set; when they need to be dealt with per-package, they get messy and annoying for end users -- that's one of the main issues i've seen from the multilib eclass project, since ABI_X86 et al really aren't meant to be set globally and difficult-to-manage package.use mess arises out of it. I know that USE_EXPANDs are handy in allowing the subset of packages that use them to have an isolated set of use flags, but i'm not sure if there's really a benefit to having a separation of i.e. 'nss' and 'ssl_nss' in an end-user's USE ?? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlOIkEAACgkQ2ugaI38ACPAJowD/d5gJsEhy0T9Y2p7WM1PLW+bE uPrb4QRuNol6yxt3NDEA/R9uD21lYzVcxR6WtPZ2DbCmIl0AIaR/89h/lGLTukDr =a8AD -----END PGP SIGNATURE-----