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 48CAC1381FA for ; Fri, 30 May 2014 12:00:58 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4B61DE0874; Fri, 30 May 2014 12:00:51 +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 3B8F7E0851 for ; Fri, 30 May 2014 12:00:50 +0000 (UTC) Received: from [192.168.3.7] (cpe-74-77-145-97.buffalo.res.rr.com [74.77.145.97]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: blueness) by smtp.gentoo.org (Postfix) with ESMTPSA id 169B833FABB for ; Fri, 30 May 2014 12:00:48 +0000 (UTC) Message-ID: <53887384.3060404@gentoo.org> Date: Fri, 30 May 2014 08:03:16 -0400 From: "Anthony G. Basile" 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> In-Reply-To: <9C490A66-E7CF-4E60-AAAA-57DC0165A7ED@gentoo.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 981d95a3-ae3c-49c0-8323-49a8f76371b9 X-Archives-Hash: 3b2414903368e3adb81d3ead3589bdff On 05/29/14 23:21, Ian Stakenvicius wrote: > Sorry for the possible HTML email, this is from my phone.. > > >> On May 29, 2014, at 10:20 PM, Duncan <1i5t5.duncan@cox.net> wrote: >> >> Anthony G. Basile posted on Thu, 29 May 2014 13:42:01 -0400 as excerpted: >> >>> With the number of ssl providers growing, like libressl, and with issues >>> like bug #510974, I think its time we consider making this a uniform way >>> of dealing with ssl providers in gentoo. We would proceed something >>> like this: >>> >>> 1. Introduce a new USE_EXPAND called SSL which mirrors CURL_SSL --- >>> becuase CURL_SSL is too provincial a name. >>> >>> 2. migrate curl and all its dependencies to the SSL use expand. >>> >>> 3. Migrate over all consumers of ssl to the new SSL use expand system. >>> >>> What do people think? >> What about an ssl.eclass to handle it? >> >> Obviously Peter's concern about packages that only support some of the >> options would need to be taken into account, with some sort of variable, >> say SSL_SUPPORTED, that would be set before eclass inheritance. Then the >> eclass could formalize the general dependency logic and expose variables >> of its own that could in turn be used to set package specific options. >> >> Or is package handling too individualized for an eclass to work well, >> even with a mechanism to tell the eclass which ssl providers were >> supported and further mechanisms to allow package specific logic where >> required? > 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. Other uses of USE_EXPAND span the spectrum and do not fit neatly into "all participating ebuilds are ok with working from the exact same set of flags." Take a look at ELIBC where most ebuilds that invoke any elibc_* just make use of one or another elibc_* for some exceptional sitatuation, usually related to elibc_FreeBSD or elibc_uclibc. Most of these package would not even build under, for example, elibc_Winnt. Yet other USE_EXPANDS are localized in the tree like XTABLES_ADDONS which is only used in net-firewall/xtables-addons and little possibility of generalization to other packages. I don't know what you mean by "working" in "working from the exact same set of flags" but there are lots of examples where ebuild simply ignore a portion of all the possible use flags in the USE_EXPAND set because they can't/don't use them. The idea I have of a USE_EXPAND is a namespace of use flags which, like any plain global use flag, can be shared between several ebuilds. Not that all of the use flags in that namespace need to be useable by every participating ebuild, but the namespace is meaningful to every participating ebuild. All ebuilds that provide an ssl layer can participate in the SSL use_expand even though a package might only build against some subset of the ssl providers listed in the USE_EXPAND. > The only case I can think of otherwise right now is PYTHON_TARGETS, and even then it is generally considered that all packages can support at least a small subset of the flags. Even then, we have a second var (PYTHON_SINGLE_TARGET) for special case packages. > > If that is the case here, we should be ok with a similar concept as that brought by python-r1.eclass. However I fear that packages are still going to need to have fallback logic or preference-based flag ordering if we are going to avoid the need for a bunch of package.use entries on end user systems. 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. > > Or is the plan to essentially do that anyways, ie, expect the SSL use_expand to only set one global default, and any deviations from that would be taken care of via package.use entries? 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 ) )" > > I don't suppose PMS allows the order of the list of flags in a var to be relied upon? That could make this easier: > > SSL="polarssl openssl" > > ... would use polarssl first and foremost but use OpenSSL iff polarssl isn't supported by the package (assuming OpenSSL is); the eclass would handle the preference logic that would make the secondary flags be ignored in favour of the primary one. > > Thoughts? > > >> -- >> Duncan - List replies preferred. No HTML msgs. >> "Every nonfree program has a lord, a master -- >> and if you use the program, he is your master." Richard Stallman >> >> -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail : blueness@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA