* [gentoo-dev] Creating a USE_EXPAND for ssl providers
@ 2014-05-29 17:42 Anthony G. Basile
2014-05-29 17:45 ` Peter Stuge
` (3 more replies)
0 siblings, 4 replies; 17+ messages in thread
From: Anthony G. Basile @ 2014-05-29 17:42 UTC (permalink / raw
To: Gentoo Development
Hi everyone,
Back in Jun 2012 I added a CURL_SSL to the USE_EXPAND to represent the
different ssl providers for curl. This was to get away from the old ssl
USE flag logic which you still see in packages like
media-video/rtmpdump. Quoting from there so you don't have to go find it
yourself (and removing extraneous stuff) we have:
IUSE="gnutls polarssl ssl"
DEPEND="ssl? (
gnutls? ( net-libs/gnutls )
polarssl? ( !gnutls? ( >=net-libs/polarssl-0.14.0 ) )
!gnutls? ( !polarssl? ( dev-libs/openssl ) )
)"
pkg_setup() {
if ! use ssl && ( use gnutls || use polarssl ) ; then
ewarn "USE='gnutls polarssl' are ignored without USE='ssl'."
ewarn "Please review the local USE flags for this package."
fi
}
The idea is that if you say USE=ssl but nothing more, you default to
openssl. This is asymmetrical and doesn't scale well. So I made the
leap in curl to the following (modulo extra stuff):
IUSE="${IUSE} curl_ssl_axtls curl_ssl_cyassl curl_ssl_gnutls
curl_ssl_nss +curl_ssl_openssl curl_ssl_polarssl curl_ssl_winssl"
RDEPEND="
ssl? (
curl_ssl_axtls? ( net-libs/axtls app-misc/ca-certificates )
curl_ssl_cyassl? ( net-libs/cyassl app-misc/ca-certificates )
curl_ssl_gnutls? (
|| (
( >=net-libs/gnutls-3[static-libs?] dev-libs/nettle )
( =net-libs/gnutls-2.12*[nettle,static-libs?]
dev-libs/nettle )
( =net-libs/gnutls-2.12*[-nettle,static-libs?]
dev-libs/libgcrypt[static-libs?] )
)
app-misc/ca-certificates
)
curl_ssl_openssl? ( dev-libs/openssl[static-libs?] )
curl_ssl_nss? ( dev-libs/nss app-misc/ca-certificates )
curl_ssl_polarssl? ( net-libs/polarssl:= app-misc/ca-certificates )
)
REQUIRED_USE="
curl_ssl_winssl? ( elibc_Winnt )
ssl? (
^^ (
curl_ssl_axtls
curl_ssl_cyassl
curl_ssl_gnutls
curl_ssl_openssl
curl_ssl_nss
curl_ssl_polarssl
curl_ssl_winssl
)
)"
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?
--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : blueness@gentoo.org
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [gentoo-dev] Creating a USE_EXPAND for ssl providers
2014-05-29 17:42 [gentoo-dev] Creating a USE_EXPAND for ssl providers Anthony G. Basile
@ 2014-05-29 17:45 ` Peter Stuge
2014-05-30 2:20 ` [gentoo-dev] " Duncan
` (2 subsequent siblings)
3 siblings, 0 replies; 17+ messages in thread
From: Peter Stuge @ 2014-05-29 17:45 UTC (permalink / raw
To: gentoo-dev
Anthony G. Basile wrote:
> 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.
As long as consumers can support only a few of the expansions that
just seems to tidy things up, which is a good thing.
//Peter
^ permalink raw reply [flat|nested] 17+ messages in thread
* [gentoo-dev] Re: Creating a USE_EXPAND for ssl providers
2014-05-29 17:42 [gentoo-dev] Creating a USE_EXPAND for ssl providers Anthony G. Basile
2014-05-29 17:45 ` Peter Stuge
@ 2014-05-30 2:20 ` Duncan
2014-05-30 3:21 ` Ian Stakenvicius
2014-05-30 10:18 ` [gentoo-dev] " Jeroen Roovers
2014-06-11 11:12 ` Chí-Thanh Christopher Nguyễn
3 siblings, 1 reply; 17+ messages in thread
From: Duncan @ 2014-05-30 2:20 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [gentoo-dev] Re: Creating a USE_EXPAND for ssl providers
2014-05-30 2:20 ` [gentoo-dev] " Duncan
@ 2014-05-30 3:21 ` Ian Stakenvicius
2014-05-30 6:44 ` Duncan
2014-05-30 12:03 ` Anthony G. Basile
0 siblings, 2 replies; 17+ messages in thread
From: Ian Stakenvicius @ 2014-05-30 3:21 UTC (permalink / raw
To: gentoo-dev@lists.gentoo.org
Sorry for the possible HTML email, this is from my phone..
> On May 29, 2014, at 10:20 PM, Duncan <1i5t5.duncan@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
>
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* [gentoo-dev] Re: Creating a USE_EXPAND for ssl providers
2014-05-30 3:21 ` Ian Stakenvicius
@ 2014-05-30 6:44 ` Duncan
2014-05-30 12:03 ` Anthony G. Basile
1 sibling, 0 replies; 17+ messages in thread
From: Duncan @ 2014-05-30 6:44 UTC (permalink / raw
To: gentoo-dev
Ian Stakenvicius posted on Thu, 29 May 2014 23:21:47 -0400 as excerpted:
> 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?
That's essentially what I've ended up having to do with python. I have
PYTHON_TARGETS="python3_3 python2_7" and PYTHON_SINGLE_TARGET=python3_3 ,
with a bunch of package.env file settings pointing at a single
python.starget.27 file, that sets PYTHON_SINGLE_TARGET=python2_7 , for
those packages that don't support python3 yet.
And for ssl, I already have package.use files that toggle USE flags
appropriately for individual packages. Similarly for gles and opengl,
since I have them both on by default, but sometimes they interfere with
each other so I have to turn one off.
So I expect that some amount of package.use or package.env settings will
have to be maintained for certain packages that don't fit the normal
order of things, no matter what.
But with an SSL USE_EXPAND and in particular, if an eclass is setup to
coordinate and centralize handling, I expect that at minimum, the number
of exceptions I have to deal with as a user won't go up, and likely,
they'll go down, since handling will be centralized and hopefully mostly
standardized.
--
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [gentoo-dev] Creating a USE_EXPAND for ssl providers
2014-05-29 17:42 [gentoo-dev] Creating a USE_EXPAND for ssl providers Anthony G. Basile
2014-05-29 17:45 ` Peter Stuge
2014-05-30 2:20 ` [gentoo-dev] " Duncan
@ 2014-05-30 10:18 ` Jeroen Roovers
2014-06-11 11:12 ` Chí-Thanh Christopher Nguyễn
3 siblings, 0 replies; 17+ messages in thread
From: Jeroen Roovers @ 2014-05-30 10:18 UTC (permalink / raw
To: gentoo-dev
On Thu, 29 May 2014 13:42:01 -0400
"Anthony G. Basile" <blueness@gentoo.org> wrote:
> Back in Jun 2012 I added a CURL_SSL to the USE_EXPAND to represent
You could start by fixing boring old bugs instead of working on
exciting new features. See bug 510580, née 499398, which stops everyone
from stabilising because you have the USE defaults / REQUIRED_USE wrong.
jer
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [gentoo-dev] Re: Creating a USE_EXPAND for ssl providers
2014-05-30 3:21 ` Ian Stakenvicius
2014-05-30 6:44 ` Duncan
@ 2014-05-30 12:03 ` Anthony G. Basile
2014-05-30 14:05 ` Ian Stakenvicius
1 sibling, 1 reply; 17+ messages in thread
From: Anthony G. Basile @ 2014-05-30 12:03 UTC (permalink / raw
To: gentoo-dev
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.duncan@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 : blueness@gentoo.org
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [gentoo-dev] Re: Creating a USE_EXPAND for ssl providers
2014-05-30 12:03 ` Anthony G. Basile
@ 2014-05-30 14:05 ` Ian Stakenvicius
2014-05-31 0:50 ` Peter Stuge
2014-06-01 10:46 ` Anthony G. Basile
0 siblings, 2 replies; 17+ messages in thread
From: Ian Stakenvicius @ 2014-05-30 14:05 UTC (permalink / raw
To: gentoo-dev
-----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-----
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [gentoo-dev] Re: Creating a USE_EXPAND for ssl providers
2014-05-30 14:05 ` Ian Stakenvicius
@ 2014-05-31 0:50 ` Peter Stuge
2014-05-31 1:08 ` hasufell
2014-06-01 10:46 ` Anthony G. Basile
1 sibling, 1 reply; 17+ messages in thread
From: Peter Stuge @ 2014-05-31 0:50 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [gentoo-dev] Re: Creating a USE_EXPAND for ssl providers
2014-05-31 0:50 ` Peter Stuge
@ 2014-05-31 1:08 ` hasufell
0 siblings, 0 replies; 17+ messages in thread
From: hasufell @ 2014-05-31 1:08 UTC (permalink / raw
To: gentoo-dev
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [gentoo-dev] Re: Creating a USE_EXPAND for ssl providers
2014-05-30 14:05 ` Ian Stakenvicius
2014-05-31 0:50 ` Peter Stuge
@ 2014-06-01 10:46 ` Anthony G. Basile
1 sibling, 0 replies; 17+ messages in thread
From: Anthony G. Basile @ 2014-06-01 10:46 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [gentoo-dev] Creating a USE_EXPAND for ssl providers
2014-05-29 17:42 [gentoo-dev] Creating a USE_EXPAND for ssl providers Anthony G. Basile
` (2 preceding siblings ...)
2014-05-30 10:18 ` [gentoo-dev] " Jeroen Roovers
@ 2014-06-11 11:12 ` Chí-Thanh Christopher Nguyễn
2014-06-11 11:32 ` Anthony G. Basile
2014-06-11 13:12 ` Michał Górny
3 siblings, 2 replies; 17+ messages in thread
From: Chí-Thanh Christopher Nguyễn @ 2014-06-11 11:12 UTC (permalink / raw
To: gentoo-dev
Dear all,
I'm a bit late to the party, but here is my $0.02:
> REQUIRED_USE="
> curl_ssl_winssl? ( elibc_Winnt )
> ssl? (
> ^^ (
> [...]
> )
> )"
I don't like this. If the user specifies several SSL providers in
make.conf, it should mean that any of these is fine and the ebuild can
choose an arbitrary one. The exactly-one-of operator would cause emerge
to complain in this case and possibly force the user to have complex
package.use setups.
> 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?
I think a better name for the USE_EXPAND would be CRYPTO_PROVIDER (or
similar) instead of just SSL, as the libraries are not strictly used for
SSL but also for other forms of crypto (e.g. [1]).
Best regards,
Chí-Thanh Christopher Nguyễn
[1] https://bugs.gentoo.org/show_bug.cgi?id=512664
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [gentoo-dev] Creating a USE_EXPAND for ssl providers
2014-06-11 11:12 ` Chí-Thanh Christopher Nguyễn
@ 2014-06-11 11:32 ` Anthony G. Basile
2014-06-11 13:12 ` Michał Górny
1 sibling, 0 replies; 17+ messages in thread
From: Anthony G. Basile @ 2014-06-11 11:32 UTC (permalink / raw
To: gentoo-dev
On 06/11/14 07:12, Chí-Thanh Christopher Nguyễn wrote:
> Dear all,
>
> I'm a bit late to the party, but here is my $0.02:
>
>> REQUIRED_USE="
>> curl_ssl_winssl? ( elibc_Winnt )
>> ssl? (
>> ^^ (
>> [...]
>> )
>> )"
> I don't like this. If the user specifies several SSL providers in
> make.conf, it should mean that any of these is fine and the ebuild can
> choose an arbitrary one. The exactly-one-of operator would cause emerge
> to complain in this case and possibly force the user to have complex
> package.use setups.
That's a good point and not one that I wasn't aware of. But how would
we better design this? The only thing I can thing of (suggested
earlier) is an eclass with some intelligence. I'm not sure of the most
userfriendly way of doing this.
>
>> 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?
> I think a better name for the USE_EXPAND would be CRYPTO_PROVIDER (or
> similar) instead of just SSL, as the libraries are not strictly used for
> SSL but also for other forms of crypto (e.g. [1]).
Agreed.
>
>
> Best regards,
> Chí-Thanh Christopher Nguyễn
>
>
> [1] https://bugs.gentoo.org/show_bug.cgi?id=512664
>
--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : blueness@gentoo.org
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [gentoo-dev] Creating a USE_EXPAND for ssl providers
2014-06-11 11:12 ` Chí-Thanh Christopher Nguyễn
2014-06-11 11:32 ` Anthony G. Basile
@ 2014-06-11 13:12 ` Michał Górny
2014-06-11 13:30 ` Chí-Thanh Christopher Nguyễn
1 sibling, 1 reply; 17+ messages in thread
From: Michał Górny @ 2014-06-11 13:12 UTC (permalink / raw
To: gentoo-dev; +Cc: chithanh
[-- Attachment #1: Type: text/plain, Size: 1138 bytes --]
Dnia 2014-06-11, o godz. 13:12:38
Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> napisał(a):
> > REQUIRED_USE="
> > curl_ssl_winssl? ( elibc_Winnt )
> > ssl? (
> > ^^ (
> > [...]
> > )
> > )"
>
> I don't like this. If the user specifies several SSL providers in
> make.conf, it should mean that any of these is fine and the ebuild can
> choose an arbitrary one. The exactly-one-of operator would cause emerge
> to complain in this case and possibly force the user to have complex
> package.use setups.
Your idea comes with three significant drawbacks:
1. USE flag setups become unclear -- user sees five different SSL
providers turned on and has no clue which one is actually used.
2. You create 2^n-1 valid USE flag combinations which map to n
different file sets. This means that there are 2^n-n-1 useless USE flag
combination which make matching binary packages a PITA.
3. There is no clean way of enforcing SSL provider match between
packages. Wasn't this thread initially about curl and rtmpdump
requiring matching flags?
--
Best regards,
Michał Górny
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 949 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [gentoo-dev] Creating a USE_EXPAND for ssl providers
2014-06-11 13:12 ` Michał Górny
@ 2014-06-11 13:30 ` Chí-Thanh Christopher Nguyễn
2014-06-11 13:45 ` Michał Górny
0 siblings, 1 reply; 17+ messages in thread
From: Chí-Thanh Christopher Nguyễn @ 2014-06-11 13:30 UTC (permalink / raw
To: gentoo-dev
Michał Górny schrieb:
>>
>> I don't like this. If the user specifies several SSL providers in
>> make.conf, it should mean that any of these is fine and the ebuild can
>> choose an arbitrary one. The exactly-one-of operator would cause emerge
>> to complain in this case and possibly force the user to have complex
>> package.use setups.
> Your idea comes with three significant drawbacks:
>
> 1. USE flag setups become unclear -- user sees five different SSL
> providers turned on and has no clue which one is actually used.
Does that really matter? What I got from bug 512664 comment 0 is the
desire to ensure that a certain crypto provider (in this case, openssl)
is *not* used.
> 2. You create 2^n-1 valid USE flag combinations which map to n
> different file sets. This means that there are 2^n-n-1 useless USE flag
> combination which make matching binary packages a PITA.
This is indeed a problem, if producer and consumer of the binpkg are different entities. It could be mitigated by pre-populating the default list of crypto providers so that most users will not need to change it.
> 3. There is no clean way of enforcing SSL provider match between
> packages. Wasn't this thread initially about curl and rtmpdump
> requiring matching flags?
It could be enforced if an eclass does the actual choice of crypto
provider in a reproducible way. That would be not trivial though.
Best regards,
Chí-Thanh Christopher Nguyễn
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [gentoo-dev] Creating a USE_EXPAND for ssl providers
2014-06-11 13:30 ` Chí-Thanh Christopher Nguyễn
@ 2014-06-11 13:45 ` Michał Górny
2014-06-11 14:22 ` Chí-Thanh Christopher Nguyễn
0 siblings, 1 reply; 17+ messages in thread
From: Michał Górny @ 2014-06-11 13:45 UTC (permalink / raw
To: gentoo-dev; +Cc: chithanh
[-- Attachment #1: Type: text/plain, Size: 713 bytes --]
Dnia 2014-06-11, o godz. 15:30:26
Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> napisał(a):
> > 3. There is no clean way of enforcing SSL provider match between
> > packages. Wasn't this thread initially about curl and rtmpdump
> > requiring matching flags?
>
> It could be enforced if an eclass does the actual choice of crypto
> provider in a reproducible way. That would be not trivial though.
No, it can't. Let's say package A depends on package B and requires
the same SSL provider.
A has 'openssl gnutls'
B has 'openssl gnutls polarssl'
Now let's say the eclass prefers polarssl over the other two. How are
you going to make A dep on B?
--
Best regards,
Michał Górny
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 949 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [gentoo-dev] Creating a USE_EXPAND for ssl providers
2014-06-11 13:45 ` Michał Górny
@ 2014-06-11 14:22 ` Chí-Thanh Christopher Nguyễn
0 siblings, 0 replies; 17+ messages in thread
From: Chí-Thanh Christopher Nguyễn @ 2014-06-11 14:22 UTC (permalink / raw
To: gentoo-dev
Michał Górny schrieb:
> Dnia 2014-06-11, o godz. 15:30:26
> Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> napisał(a):
>
>>> 3. There is no clean way of enforcing SSL provider match between
>>> packages. Wasn't this thread initially about curl and rtmpdump
>>> requiring matching flags?
>> It could be enforced if an eclass does the actual choice of crypto
>> provider in a reproducible way. That would be not trivial though.
> No, it can't. Let's say package A depends on package B and requires
> the same SSL provider.
>
> A has 'openssl gnutls'
> B has 'openssl gnutls polarssl'
>
> Now let's say the eclass prefers polarssl over the other two. How are
> you going to make A dep on B?
>
It is not trivial, but I don't think it is impossible. I had thought of
the following, but have not carefully checked that it covers all cases.
crypto-providers.eclass would have a list CRYPTO_PROVIDERS_SUPPORTED
sorted descending by priority, and A and B would pass in a variable
CRYPTO_PROVIDERS the acceptable providers. The eclass would provide
functions which expand into USE dependencies to ensure that no
higher-prioritized crypto provider is selected in B.
Example:
crypto-providers.eclass:
CRYPTO_PROVIDERS_SUPPORTED="polarssl openssl gnutls libgcrypt libnettle ..."
crypto-providers_only() returns USE dependency on its arguments, and
negative USE dependencies for all providers with higher priority, e.g.
crypto-providers_only(gnutls) returns "-crypto_providers_polarssl(-)
-crypto_providers_openssl(-) crypto_providers_gnutls(-)"
crypto-providers_match(packagename) returns priority nested USE
conditionals for all CRYPTO_PROVIDERS that can be fed into DEPEND, e.g.
crypto_providers_match(B) would return "crypto-providers_openssl? (
B[$(crypto_providers-only(openssl)] )
!crypto-providers_openssl? ( crypto-providers_gnutls? (
B[$(crypto_providers-only(gnutls)] ) )"
A.ebuild
CRYPTO_PROVIDERS="openssl gnutls"
DEPEND="$(crypto-providers_match(B))"
B.ebuild
CRYPTO_PROVIDERS="openssl gnutls polarssl"
Best regards,
Chí-Thanh Christopher Nguyễn
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2014-06-11 14:22 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-05-29 17:42 [gentoo-dev] Creating a USE_EXPAND for ssl providers Anthony G. Basile
2014-05-29 17:45 ` Peter Stuge
2014-05-30 2:20 ` [gentoo-dev] " Duncan
2014-05-30 3:21 ` Ian Stakenvicius
2014-05-30 6:44 ` Duncan
2014-05-30 12:03 ` Anthony G. Basile
2014-05-30 14:05 ` Ian Stakenvicius
2014-05-31 0:50 ` Peter Stuge
2014-05-31 1:08 ` hasufell
2014-06-01 10:46 ` Anthony G. Basile
2014-05-30 10:18 ` [gentoo-dev] " Jeroen Roovers
2014-06-11 11:12 ` Chí-Thanh Christopher Nguyễn
2014-06-11 11:32 ` Anthony G. Basile
2014-06-11 13:12 ` Michał Górny
2014-06-11 13:30 ` Chí-Thanh Christopher Nguyễn
2014-06-11 13:45 ` Michał Górny
2014-06-11 14:22 ` Chí-Thanh Christopher Nguyễn
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox