Sorry for the possible HTML email, this is from my phone..
> On May 29, 2014, at 10:20 PM, Duncan <1i5t5.dun...@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. 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 > >
