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