1 |
Is this not precisely what USE_EXPAND is supposed to be for? Take CURL_SSL |
2 |
and make it generic... |
3 |
|
4 |
On Tue, Oct 27, 2015 at 9:46 PM, Rich Freeman <rich0@g.o> wrote: |
5 |
|
6 |
> On Tue, Oct 27, 2015 at 10:06 PM, hasufell <hasufell@g.o> wrote: |
7 |
> > |
8 |
> > B) 1 feature flag, 3 strict provider flags |
9 |
> > * ssl: enable any sort of SSL/TLS support |
10 |
> > * gnutls: only to enable gnutls provided ssl support in case there |
11 |
> > is a choice |
12 |
> > * openssl: only to enable openssl provided ssl support in case |
13 |
> > there is a choice (should not be implemented as !gnutls?) |
14 |
> > * libressl: only to enable libressl provided ssl support in case there |
15 |
> > is a choice, must conflict with 'openssl' USE flag |
16 |
> > |
17 |
> > consequences: |
18 |
> > * REQUIRED_USE="^^ ( openssl libressl )" is not only allowed, it is |
19 |
> > _mandatory_ |
20 |
> > * packages like media-video/ffmpeg _must_ switch the USE flag |
21 |
> > openssl->ssl to avoid breaking global USE flags |
22 |
> > * !gnutls? ( dev-libs/openssl:0 ) will be bad form or even disallowed |
23 |
> > |
24 |
> > B will definitely be more work, but ofc is also a lot cleaner and |
25 |
> > totally unambigous. |
26 |
> > |
27 |
> |
28 |
> ++ |
29 |
> |
30 |
> The pain is for a short time. Then we have to live with this for a |
31 |
> long time. USE flags should have one meaning. The fact that this |
32 |
> isn't the case right now is already a bug. We don't need to |
33 |
> perpetuate it. |
34 |
> |
35 |
> Honestly, this just seems like "the right thing" so if there isn't |
36 |
> opposition then I'd suggest to "just do it" and commit fixes to |
37 |
> ebuilds that need the fix (ie if maintainer doesn't respond to bug |
38 |
> quickly just take care of it). If people object they should speak up |
39 |
> now, and we can take it up at the next council meeting if necessary |
40 |
> (which is right around the corner). |
41 |
> |
42 |
> -- |
43 |
> Rich |
44 |
> |
45 |
> |