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