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