This is about my beloved USE="ssl". A bit long and ranty, but if you
want the consensus, just read the last part.


Today a new snapshot of gnash was uploaded where the old USE="ssl" was
renamed to USE="openssl".

So yet another package where if you want ssl support you have to
_personally_ audit what function this useflag has (i.e. does it enable
ssl or tune the ssl implementation?).

So I wanted to figure it out, does gnash provide ssl itself and the
USE="openssl" only tunes how it is implemented or does USE="openssl"
enable ssl?

So what does the flag really do? Their local description does not say
very much:
localpenssl:www-plugins/gnash: Enable directly using OpenSSL

What is even "enabled directly"? Still not much smarter.
Unpacking the source and looking in ./configure --help and the strange
description for the use flag gets an explanation:
--enable-ssl Enable using OpenSSL directly

Still not much smarter...

Looking inside configure.ac makes me smarter tho:

dnl Enable using OpenSSL with libnet.
AC_ARG_ENABLE(ssl,
AC_HELP_STRING([--enable-ssl], [Enable using OpenSSL directly]),
[case "${enableval}" in
yes) build_ssl=yes ;;
no) build_ssl=no ;;
*) AC_MSG_ERROR([bad value ${enableval} for --enable-ssl option]) ;;
esac], build_ssl=no)

So apparently it seems the flag enables ssl support using openssl.

No, I did not review the source to make sure that build_ssl does really
build ssl, but do I really have to to find out what a USE-flag does?

Personally I would still like the description for the useflag to really
describe the flag, like:
global:ssl: Adds support for Secure Socket Layer connections

(and thus in this case the use flag to still be USE="ssl")



And why I post here instead of making a bug is to try to start a
discussion that is still not finished[1]:
What function should useflags bring?

There are some packages (like networkmanager) that does not have a ssl
flag (it is always enabled), and the gnutls/nss useflags are used to
fine tune what implementation to use. If non selected the upstream
preferred (nss) is chosen.

Then there are some packages (like qemu) where there is only one flag
(USE="gnutls") that enables support for encrypten vnc.

Then there are packages like curl where the local description of
USE="ssl" says it all:
local:ssl:net-misc/curl: Enable crypto engine support (via openssl if
USE='-gnutls -nss')





So as a user, if I want to have Secure Socket Layer or Transport Layer
Security, do I really need to learn the name of every implementation
known to man and enable their respective use flag to ensure that my
whole system has support for it, or should I just have to enable
USE="ssl"?
And will I still be sure that those use flag did not disable a (maybe
superior or by maintainer preferred) internal ssl implementation?


[1] Last time I did a bugreport about this, here is the answer:
https://bugs.gentoo.org/show_bug.cgi?id=310681


Regards
Peter Hjalmarsson

On 08/14/2010 02:26 PM, Peter Hjalmarsson wrote:
> This is about my beloved USE="ssl". A bit long and ranty, but if you
> want the consensus, just read the last part.
>
>
> Today a new snapshot of gnash was uploaded where the old USE="ssl" was
> renamed to USE="openssl".
>
> So yet another package where if you want ssl support you have to
> _personally_ audit what function this useflag has (i.e. does it enable
> ssl or tune the ssl implementation?).
>
> So I wanted to figure it out, does gnash provide ssl itself and the
> USE="openssl" only tunes how it is implemented or does USE="openssl"
> enable ssl?
>
> So what does the flag really do? Their local description does not say
> very much:
> localpenssl:www-plugins/gnash: Enable directly using OpenSSL
>
> What is even "enabled directly"? Still not much smarter.
> Unpacking the source and looking in ./configure --help and the strange
> description for the use flag gets an explanation:
> --enable-ssl Enable using OpenSSL directly
>
> Still not much smarter...
>
> Looking inside configure.ac makes me smarter tho:
>
> dnl Enable using OpenSSL with libnet.
> AC_ARG_ENABLE(ssl,
> AC_HELP_STRING([--enable-ssl], [Enable using OpenSSL directly]),
> [case "${enableval}" in
> yes) build_ssl=yes ;;
> no) build_ssl=no ;;
> *) AC_MSG_ERROR([bad value ${enableval} for --enable-ssl option]) ;;
> esac], build_ssl=no)
>
> So apparently it seems the flag enables ssl support using openssl.
>
> No, I did not review the source to make sure that build_ssl does really
> build ssl, but do I really have to to find out what a USE-flag does?
>
> Personally I would still like the description for the useflag to really
> describe the flag, like:
> global:ssl: Adds support for Secure Socket Layer connections
>
> (and thus in this case the use flag to still be USE="ssl")
>
>
>
> And why I post here instead of making a bug is to try to start a
> discussion that is still not finished[1]:
> What function should useflags bring?
>
> There are some packages (like networkmanager) that does not have a ssl
> flag (it is always enabled), and the gnutls/nss useflags are used to
> fine tune what implementation to use. If non selected the upstream
> preferred (nss) is chosen.
>
> Then there are some packages (like qemu) where there is only one flag
> (USE="gnutls") that enables support for encrypten vnc.
>
> Then there are packages like curl where the local description of
> USE="ssl" says it all:
> local:ssl:net-misc/curl: Enable crypto engine support (via openssl if
> USE='-gnutls -nss')
>
>
>
>
>
> So as a user, if I want to have Secure Socket Layer or Transport Layer
> Security, do I really need to learn the name of every implementation
> known to man and enable their respective use flag to ensure that my
> whole system has support for it, or should I just have to enable
> USE="ssl"?
> And will I still be sure that those use flag did not disable a (maybe
> superior or by maintainer preferred) internal ssl implementation?
>
>
> [1] Last time I did a bugreport about this, here is the answer:
> https://bugs.gentoo.org/show_bug.cgi?id=310681

Long story short:

If package has SSL support, and use "ssl" is ignored or not present in a
ebuild. it's plain broken.

Every ebuild in tree with USE="openssl" is a QA violation, and should be
fixed asap.

lör 2010-08-14 klockan 13:45 +0200 skrev ChÃ*-Thanh Christopher Nguyá»…n:
> Peter Hjalmarsson schrieb:
> > This is about my beloved USE="ssl". A bit long and ranty, but if you
> > want the consensus, just read the last part.
> >
> >
> > Today a new snapshot of gnash was uploaded where the old USE="ssl" was
> > renamed to USE="openssl".
> >
> > So yet another package where if you want ssl support you have to
> > _personally_ audit what function this useflag has (i.e. does it enable
> > ssl or tune the ssl implementation?).
> >
> > So I wanted to figure it out, does gnash provide ssl itself and the
> > USE="openssl" only tunes how it is implemented or does USE="openssl"
> > enable ssl?
> >
>
> The USE flag was renamed after discussion with upstream. Gnash does not
> provide any SSL implementation itself and (when invoked as NPAPI plugin)
> uses the browser's facilities. Possibly I could make more explicit that
> users only interested in the plugin don't need it.
>
>
> Best regards,
> ChÃ*-Thanh Christopher Nguyá»…n
>
>
>

Well if that is the use of the use flag the description is to be honest
really bad.

And still, why openssl instead of ssl? Even if most people are out to
only get the plugin the meaning of use flag for the rest of the package
is still the same. So is there a special reson why upstream do want ssl
disabled for people only out to get the plugin (and why not EAPI=1 and
IUSE="-ssl")?

lör 2010-08-14 klockan 15:14 +0300 skrev Samuli Suominen:
> > [1] Last time I did a bugreport about this, here is the answer:
> > https://bugs.gentoo.org/show_bug.cgi?id=310681
>
> Long story short:
>
> If package has SSL support, and use "ssl" is ignored or not present in a
> ebuild. it's plain broken.
>
> Every ebuild in tree with USE="openssl" is a QA violation, and should be
> fixed asap.
>
>

Is there a policy I can point Doug to in the bug referenced as he asks
for it?

On Saturday 14 of August 2010 18:28:19 Peter Hjalmarsson wrote:
> lör 2010-08-14 klockan 13:45 +0200 skrev ChÃ*-Thanh Christopher Nguyá»…n:
> > Peter Hjalmarsson schrieb:
> > > This is about my beloved USE="ssl". A bit long and ranty, but if you
> > > want the consensus, just read the last part.
> > >
> > >
> > > Today a new snapshot of gnash was uploaded where the old USE="ssl" was
> > > renamed to USE="openssl".
> > >
> > > So yet another package where if you want ssl support you have to
> > > _personally_ audit what function this useflag has (i.e. does it enable
> > > ssl or tune the ssl implementation?).
> > >
> > > So I wanted to figure it out, does gnash provide ssl itself and the
> > > USE="openssl" only tunes how it is implemented or does USE="openssl"
> > > enable ssl?
> >
> > The USE flag was renamed after discussion with upstream. Gnash does not
> > provide any SSL implementation itself and (when invoked as NPAPI plugin)
> > uses the browser's facilities. Possibly I could make more explicit that
> > users only interested in the plugin don't need it.
> >
> >
> > Best regards,
> > ChÃ*-Thanh Christopher Nguyá»…n
>
> Well if that is the use of the use flag the description is to be honest
> really bad.
>
> And still, why openssl instead of ssl? Even if most people are out to
> only get the plugin the meaning of use flag for the rest of the package
> is still the same. So is there a special reson why upstream do want ssl
> disabled for people only out to get the plugin (and why not EAPI=1 and
> IUSE="-ssl")?

Because it won't work. Take a look at make.conf(5) manual page -
USE_ORDER="envkg:conf:defaultskginternal:env.d " - USE defaults in profile
will override pkginternal (IUSE defaults in ebuild).
That being said IUSE="-foo" is no-op.

Otherwise I agree with you wrt naming inconsistencies.

I would also like to see some USE defaults from make.defaults moved to
package.use, and some package.use defaults moved to IUSE defaults (and some
make.defaults dropped completely, like freaking python and perl USE flags -
bug 250179)

--
regards
MM

Le samedi 14 août 2010 à 18:29 +0200, Peter Hjalmarsson a écrit :
> lör 2010-08-14 klockan 15:14 +0300 skrev Samuli Suominen:
> > > [1] Last time I did a bugreport about this, here is the answer:
> > > https://bugs.gentoo.org/show_bug.cgi?id=310681
> >
> > Long story short:
> >
> > If package has SSL support, and use "ssl" is ignored or not present in a
> > ebuild. it's plain broken.
> >
> > Every ebuild in tree with USE="openssl" is a QA violation, and should be
> > fixed asap.
> >
> >
>
> Is there a policy I can point Doug to in the bug referenced as he asks
> for it?

I remember someone opening such bug for some gnome component (for gnutls
USE iirc) and I answered the same. The problem is that we don't have
such policy written down. It's some "in the air" policy that everyone
should know about, yet no one can point to. Please write something down
so we can go forward and remove frustration for everyone.


--
Gilles Dartiguelongue <eva@gentoo.org>
Gentoo

В Сбт, 14/08/2010 в 18:29 +0200, Peter Hjalmarsson пишет:
> lör 2010-08-14 klockan 15:14 +0300 skrev Samuli Suominen:
> > > [1] Last time I did a bugreport about this, here is the answer:
> > > https://bugs.gentoo.org/show_bug.cgi?id=310681
> >
> > Long story short:
> >
> > If package has SSL support, and use "ssl" is ignored or not present in a
> > ebuild. it's plain broken.
> >
> > Every ebuild in tree with USE="openssl" is a QA violation, and should be
> > fixed asap.

> Is there a policy I can point Doug to in the bug referenced as he asks
> for it?

This was discussed many times here and since every time we had same
consensus the policy is in place. It's just not written in devmanual or
gentoo.org/doc.

--
Peter.

Le lundi 16 août 2010 à 16:07 +0400, Peter Volkov a écrit :
> This was discussed many times here and since every time we had same
> consensus the policy is in place. It's just not written in devmanual
> or
> gentoo.org/doc.

Preceeding didn't seem to make it through (yet), so here it goes:
please write that down. A policy that is not written down is not
something you can expect people to know and follow, even if it seems
"falls under common sense" from your or QA's point of view.

The number of times this was brought up alone should convince you that
it is needed.

--
Gilles Dartiguelongue <eva@gentoo.org>
Gentoo

On Mon, Aug 16, 2010 at 12:11 PM, Gilles Dartiguelongue wrote:
> Le lundi 16 août 2010 à 16:07 +0400, Peter Volkov a écrit :
>> This was discussed many times here and since every time we had same
>> consensus the policy is in place. It's just not written in devmanual
>> or
>> gentoo.org/doc.
>
> Preceeding didn't seem to make it through (yet), so here it goes:
> please write that down. A policy that is not written down is not
> something you can expect people to know and follow, even if it seems
> "falls under common sense" from your or QA's point of view.

true, but that doesnt mean the current situation cannot be fixed
-mike

On 08/16/2010 08:45 PM, Mike Frysinger wrote:
> On Mon, Aug 16, 2010 at 12:11 PM, Gilles Dartiguelongue wrote:
>> Le lundi 16 août 2010 à 16:07 +0400, Peter Volkov a écrit :
>>> This was discussed many times here and since every time we had same
>>> consensus the policy is in place. It's just not written in devmanual
>>> or
>>> gentoo.org/doc.
>>
>> Preceeding didn't seem to make it through (yet), so here it goes:
>> please write that down. A policy that is not written down is not
>> something you can expect people to know and follow, even if it seems
>> "falls under common sense" from your or QA's point of view.
>
> true, but that doesnt mean the current situation cannot be fixed
> -mike
>

There's an open repoman bug about this:
http://bugs.gentoo.org/show_bug.cgi?id=311629

Patches welcome,
Petteri