Re: [gentoo-dev] Re: Creating a USE_EXPAND for ssl providers

[Anthony G. Basile]

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@×××.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@g.o
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA