[gentoo-dev] Re: ssl vs openssl vs libressl vs gnutls USE flag foo

[Ryan Hill]

On Tue, 27 Oct 2015 22:46:35 -0400
Rich Freeman  wrote:

> On Tue, Oct 27, 2015 at 10:06 PM, hasufell  wrote:
> >
> > B) 1 feature flag, 3 strict provider flags
> > * ssl: enable any sort of SSL/TLS support
> > * gnutls: only to enable gnutls provided ssl support in case there
> >   is a choice
> > * openssl: only to enable openssl provided ssl support in case
> >there is a choice (should not be implemented as !gnutls?)
> > * libressl: only to enable libressl provided ssl support in case there
> > is a choice, must conflict with 'openssl' USE flag
> >
> > consequences:
> > * REQUIRED_USE="^^ ( openssl libressl )" is not only allowed, it is
> >   _mandatory_
> > * packages like media-video/ffmpeg _must_ switch the USE flag
> >   openssl->ssl to avoid breaking global USE flags
> > * !gnutls? ( dev-libs/openssl:0 ) will be bad form or even disallowed
> >
> > B will definitely be more work, but ofc is also a lot cleaner and
> > totally unambigous.
> >  
> 
> ++
> 
> The pain is for a short time.  Then we have to live with this for a
> long time.  USE flags should have one meaning.  The fact that this
> isn't the case right now is already a bug.  We don't need to
> perpetuate it.
> 
> Honestly, this just seems like "the right thing" so if there isn't
> opposition then I'd suggest to "just do it" and commit fixes to
> ebuilds that need the fix (ie if maintainer doesn't respond to bug
> quickly just take care of it).  If people object they should speak up
> now, and we can take it up at the next council meeting if necessary
> (which is right around the corner).

Agreed.  If there's one choice then "ssl" should be used.  openssl/libressl/etc
should really be considered sub-flags of ssl.

I really wish we had some way of specifying this to make things clearer to the
user, so they could see exactly how these flags interact with each other.
Something like (emerge -pv):

ssl [ (openssl) libressl gnutls ] 
 - if USE ssl then pick one of, default openssl if none chosen

ssl [[ (openssl) libressl gnutls ]]
 - if USE ssl then one or more of... etc.

But I suppose that's another topic.


-- 
Ryan Hillpsn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


pgp616RCHiArF.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] ssl vs openssl vs libressl vs gnutls USE flag foo

[Gordon Pettey]

Is this not precisely what USE_EXPAND is supposed to be for? Take CURL_SSL
and make it generic...

On Tue, Oct 27, 2015 at 9:46 PM, Rich Freeman  wrote:

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

Re: [gentoo-dev] ssl vs openssl vs libressl vs gnutls USE flag foo

[Rich Freeman]

On Tue, Oct 27, 2015 at 10:06 PM, hasufell  wrote:
>
> B) 1 feature flag, 3 strict provider flags
> * ssl: enable any sort of SSL/TLS support
> * gnutls: only to enable gnutls provided ssl support in case there
>   is a choice
> * openssl: only to enable openssl provided ssl support in case
>there is a choice (should not be implemented as !gnutls?)
> * libressl: only to enable libressl provided ssl support in case there
> is a choice, must conflict with 'openssl' USE flag
>
> consequences:
> * REQUIRED_USE="^^ ( openssl libressl )" is not only allowed, it is
>   _mandatory_
> * packages like media-video/ffmpeg _must_ switch the USE flag
>   openssl->ssl to avoid breaking global USE flags
> * !gnutls? ( dev-libs/openssl:0 ) will be bad form or even disallowed
>
> B will definitely be more work, but ofc is also a lot cleaner and
> totally unambigous.
>

++

The pain is for a short time.  Then we have to live with this for a
long time.  USE flags should have one meaning.  The fact that this
isn't the case right now is already a bug.  We don't need to
perpetuate it.

Honestly, this just seems like "the right thing" so if there isn't
opposition then I'd suggest to "just do it" and commit fixes to
ebuilds that need the fix (ie if maintainer doesn't respond to bug
quickly just take care of it).  If people object they should speak up
now, and we can take it up at the next council meeting if necessary
(which is right around the corner).

-- 
Rich

[gentoo-dev] ssl vs openssl vs libressl vs gnutls USE flag foo

[hasufell]

I've seen a lot of ebuilds lately that use 'openssl' USE flag for the
purpose of enabling ssl features. I think this should be discouraged
since it introduces inconsistency and is especially confusing for
packages like media-video/ffmpeg, where'd you expect to get ssl support
by having the global ssl USE flag enabled.

Furthermore, some packages have started to do things like
REQUIRED_USE="^^ ( openssl libressl )"
which is even more inconsistent now and will make it very hard for
people to switch to libressl without figuring out a lot of blockers,
since we have conflicting meanings of 'openssl' now. One uses it as a
feature flag, the other as a provider flag.


We have two choices here afais to design the USE flag meanings and how
they are used by ebuild authors:

A) 1 feature flag, 2 lax provider flags, 1 strict provider flag
* ssl: enable any sort of SSL/TLS support
* gnutls: primarily to enable gnutls provided ssl support in case
  there is a choice
* openssl: primarily to enable openssl provided ssl support in case
   there is a choice (might be implemented as !gnutls? instead)
* libressl: switch the openssl provider to libressl _without_
conflicting with openssl, so any alternative usage of
'openssl' USE flag will not break the libressl dep-graph

consequences:
* REQUIRED_USE="^^ ( openssl libressl )" is _disallowed_
* packages like media-video/ffmpeg should switch the USE flag
  openssl->ssl to avoid confusing global user configuration, but it's
  not strictly disallowed


B) 1 feature flag, 3 strict provider flags
* ssl: enable any sort of SSL/TLS support
* gnutls: only to enable gnutls provided ssl support in case there
  is a choice
* openssl: only to enable openssl provided ssl support in case
   there is a choice (should not be implemented as !gnutls?)
* libressl: only to enable libressl provided ssl support in case there
is a choice, must conflict with 'openssl' USE flag

consequences:
* REQUIRED_USE="^^ ( openssl libressl )" is not only allowed, it is
  _mandatory_
* packages like media-video/ffmpeg _must_ switch the USE flag
  openssl->ssl to avoid breaking global USE flags
* !gnutls? ( dev-libs/openssl:0 ) will be bad form or even disallowed


A is not that difficult. Most uses of 'openssl' can just be replaced
with 'ssl', others probably with '!gnutls?' even. A few exotic ones
might stay and we will have to advice users to set USE="openssl
libressl" instead of USE="-openssl libressl".
B will definitely be more work, but ofc is also a lot cleaner and
totally unambigous.

I hope I didn't confuse anything here.

[gentoo-dev] Re: gnatbuild.eclass refactoring: new/transitory eclass?

[Michael Haubenwallner]

Hi George,

On 09/03/2015 04:00 PM, George Shapovalov wrote:
> I am about to start a long-overdue refactoring of the gnat (Ada compilers) 
> build system, governed by the gnatbuild.eclass. Given that nature of the 
> packages concerned and, for quite some time, I was the only person brave 
> enough to even touch this beast this probably does not concern too many 
> people. However, since I am likely to produce some observable effects, such 
> as 
> introduction of a (possibly transitory) new eclass, I am giving a requisite 
> heads-up here.
> 
> First a short but necessary introduction:
> gnatbuild.eclass is a complex and ancient beast controlling the build of the 
> two Ada compilers we have in the tree - gnat-gcc (by FSF) and gnat-gpl (by 
> AdaCore). It has been created some 10 years ago, following the 
> toolchain.eclas 
> of then, long before even functions like src_prepare were envisioned and the 
> term pms existed only in medical terminology. Correspondingly, it is composed 
> of big blocks of code, not very modular and can benefit greatly of new 
> practices.
> 
> The catch is that all the gnat-xxx ebuilds depend on it and replacing the 
> eclass would require modifying all of the ebuilds at the same time. Given the 
> typical adjustmentsto address gcc backend gets bumps and the differences 
> between two implementations, doing a big, all-in-one change like that is a 
> perfect recipe for disaster that would likely lead to total breakage of gnat 
> build system and the project that is never complete at the same time. 
> Therefore I am thinking to do it in a more usual and gradual manner: 

Just wondering whether you are aware of https://bugs.gentoo.org/547358 already:

Although I'm not an Ada dev, as gcc upstream committer I've need to bootstrap
the Ada parts within gcc as well, but faced that neither AdaCore nor gnat-xxx
ebuilds provide a C,C++,Ada compiler. Given that AdaCore seems to not provide
anything up-to-date at all any more, my idea was to provide the recent FSF Ada
compiler via toolchain.eclass only.

Thanks!
/haubi/

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: profiles/

[Michał Górny]

On Tue, 27 Oct 2015 02:58:08 + (UTC)
"Ian Delaney"  wrote:

> commit: cdd8a3b690b12af2a4fc0b78a3787b969d0b7f47
> Author: Ian Delaney  gentoo  org>
> AuthorDate: Tue Oct 27 02:51:40 2015 +
> Commit: Ian Delaney  gentoo  org>
> CommitDate: Tue Oct 27 02:56:43 2015 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cdd8a3b6
> 
> profiles/package.mask pmask asdf-3.1.6
> 
>  profiles/package.mask | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/profiles/package.mask b/profiles/package.mask
> index 5aee23e..d27a309 100644
> --- a/profiles/package.mask
> +++ b/profiles/package.mask
> @@ -30,6 +30,10 @@
>  
>  #--- END OF EXAMPLES ---
>  
> +# Ian Delaney  (27 Oct 2015)
> +# fails to build dev-lisp/sbcl-1.2.16 #563812
> +=dev-lisp/asdf-3.1.6
> +
>  # Justin Lecher  (23 Oct 2015)
>  # Breaking changes #563540
>  =app-text/ghostscript-gpl-9.18

Please check reverse dependencies before masking or removing ebuilds.
Now you introduced depgraph breakage on all arches:

https://qa-reports.gentoo.org/output/gentoo-ci/44407dc/15.html#l1801

I'm going to fix it for you this time.

-- 
Best regards,
Michał Górny



pgppKKUsPsEqz.pgp
Description: OpenPGP digital signature