[gentoo-dev] Creating a USE_EXPAND for ssl providers

[gentoo-dev] Creating a USE_EXPAND for ssl providers

[Anthony G. Basile]

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

Re: [gentoo-dev] Creating a USE_EXPAND for ssl providers

[Peter Stuge]

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

[gentoo-dev] Re: Creating a USE_EXPAND for ssl providers

[Duncan]

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

Re: [gentoo-dev] Re: Creating a USE_EXPAND for ssl providers

[Ian Stakenvicius]

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

[gentoo-dev] Re: Creating a USE_EXPAND for ssl providers

[Duncan]

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

Re: [gentoo-dev] Re: Creating a USE_EXPAND for ssl providers

[Anthony G. Basile]

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

Re: [gentoo-dev] Re: Creating a USE_EXPAND for ssl providers

[Ian Stakenvicius]

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

[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

Re: [gentoo-dev] Re: Creating a USE_EXPAND for ssl providers

[hasufell]

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

[Anthony G. Basile]

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] Creating a USE_EXPAND for ssl providers

[Jeroen Roovers]

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

Re: [gentoo-dev] Creating a USE_EXPAND for ssl providers

[Chí-Thanh Christopher Nguyễn]

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

Re: [gentoo-dev] Creating a USE_EXPAND for ssl providers

[Anthony G. Basile]

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

Re: [gentoo-dev] Creating a USE_EXPAND for ssl providers

[Michał Górny]

[-- 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 --]

Re: [gentoo-dev] Creating a USE_EXPAND for ssl providers

[Chí-Thanh Christopher Nguyễn]

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

Re: [gentoo-dev] Creating a USE_EXPAND for ssl providers

[Michał Górny]

[-- 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 --]

Re: [gentoo-dev] Creating a USE_EXPAND for ssl providers

[Chí-Thanh Christopher Nguyễn]

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