Re: [gentoo-dev] Re: Creating a USE_EXPAND for ssl providers
On 05/30/14 10:05, Ian Stakenvicius wrote: Nothing at all, but I don't see a generic global SSL USE_EXPAND adding any particular benefit, either. What are the intended benefits to this, besides aesthetics?? Take a look at bug #510974. Because USE=ssl means different things on different packages. -- Anthony G. Basile, Ph. D. Chair of Information Technology D'Youville College Buffalo, NY 14201 (716) 829-8197
Re: [gentoo-dev] Re: Creating a USE_EXPAND for ssl providers
Peter Stuge: > Ian Stakenvicius wrote: >> If a user has i.e. SSL="polarssl" in make.conf and emerges things that >> don't have polarssl on their list, then those things won't have SSL >> support at all, right? > > Wrong; I would expect emerge to throw an error at me and exit, rather > than to fail (build the package without respecting my SSL choice) > silently. > > >> what's the difference in using the SSL use expand here, or just >> having packages directly IUSE="+ssl gnutls +openssl nss polarssl" > > The way I see it, the difference is that USE=ssl goes away, and > that setting SSL could then imply +ssl, and SSL=foossl would > correctly fail to build any IUSE=barssl package. > > > //Peter > On a note: polarssl support is still missing from a lot of packages, so if you really do set it as your ssl provider, you WILL have to micro-manage stuff.
Re: [gentoo-dev] Re: Creating a USE_EXPAND for ssl providers
Ian Stakenvicius wrote: > If a user has i.e. SSL="polarssl" in make.conf and emerges things that > don't have polarssl on their list, then those things won't have SSL > support at all, right? Wrong; I would expect emerge to throw an error at me and exit, rather than to fail (build the package without respecting my SSL choice) silently. > what's the difference in using the SSL use expand here, or just > having packages directly IUSE="+ssl gnutls +openssl nss polarssl" The way I see it, the difference is that USE=ssl goes away, and that setting SSL could then imply +ssl, and SSL=foossl would correctly fail to build any IUSE=barssl package. //Peter
Re: [gentoo-dev] Re: Creating a USE_EXPAND for ssl providers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 30/05/14 08:03 AM, Anthony G. Basile wrote:
> On 05/29/14 23:21, Ian Stakenvicius wrote:
>> 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.
>
That's a bit of a different case -- if a package doesn't support any
of the LINGUAS that a user chooses, then the user just gets the
package that would be the same as having LINGUAS unset. And this is
perfectly fine, because everything (afaik) provides either 'en' or an
unspecified 'C' type locale by default.
If a user has i.e. SSL="polarssl" in make.conf and emerges things that
don't have polarssl on their list, then those things won't have SSL
support at all, right?
>
> 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.
>
I thought the main purpose of this was to avoid a bunch of per-package
fallback logic? IE, what's the difference in using the SSL use expand
here, or just having packages directly IUSE="+ssl gnutls +openssl nss
polarssl" with standardized global use flags? the only consistency
that I see the SSL use-expand providing is an enforcement of the flags
that will be used to identify a particular implementation, and i'm
pretty sure we already have that...
>
> 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 ) )"
>
Nothing at all, but I don't see a generic global SSL USE_EXPAND adding
any particular benefit, either. What are the intended benefits to
this, besides aesthetics??
USE_EXPANDs are meant to be globally set; when they need to be dealt
with per-package, they get messy and annoying for end users -- that's
one of the main issues i've seen from the multilib eclass project,
since ABI_X86 et al really aren't meant to be set globally and
difficult-to-manage package.use mess arises out of it.
I know that USE_EXPANDs are handy in allowing the subset of packages
that use them to have an isolated set of use flags, but i'm not sure
if there's really a benefit to having a separation of i.e. 'nss' and
'ssl_nss' in an end-user's USE ??
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
iF4EAREIAAYFAlOIkEAACgkQ2ugaI38ACPAJowD/d5gJsEhy0T9Y2p7WM1PLW+bE
uPrb4QRuNol6yxt3NDEA/R9uD21lYzVcxR6WtPZ2DbCmIl0AIaR/89h/lGLTukDr
=a8AD
-END PGP SIGNATURE-
Re: [gentoo-dev] Re: Creating a USE_EXPAND for ssl providers
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.
Re: [gentoo-dev] Re: Creating a USE_EXPAND for ssl providers
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 > >
