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

[Ian Stakenvicius]

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.  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.

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?

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
>
>