* [gentoo-dev] Why (i.e. USE="openssl" instead of USE="ssl")
@ 2010-08-14 11:26 Peter Hjalmarsson
2010-08-14 11:45 ` Chí-Thanh Christopher Nguyễn
2010-08-14 12:14 ` [gentoo-dev] " Samuli Suominen
0 siblings, 2 replies; 11+ messages in thread
From: Peter Hjalmarsson @ 2010-08-14 11:26 UTC (permalink / raw
To: gentoo-dev
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:
local:openssl: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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [gentoo-dev] Why (i.e. USE="openssl" instead of USE="ssl")
2010-08-14 11:26 [gentoo-dev] Why (i.e. USE="openssl" instead of USE="ssl") Peter Hjalmarsson
@ 2010-08-14 11:45 ` Chí-Thanh Christopher Nguyễn
2010-08-14 16:28 ` [gentoo-dev] " Peter Hjalmarsson
2010-08-14 12:14 ` [gentoo-dev] " Samuli Suominen
1 sibling, 1 reply; 11+ messages in thread
From: Chí-Thanh Christopher Nguyễn @ 2010-08-14 11:45 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [gentoo-dev] Why (i.e. USE="openssl" instead of USE="ssl")
2010-08-14 11:26 [gentoo-dev] Why (i.e. USE="openssl" instead of USE="ssl") Peter Hjalmarsson
2010-08-14 11:45 ` Chí-Thanh Christopher Nguyễn
@ 2010-08-14 12:14 ` Samuli Suominen
2010-08-14 16:29 ` [gentoo-dev] " Peter Hjalmarsson
1 sibling, 1 reply; 11+ messages in thread
From: Samuli Suominen @ 2010-08-14 12:14 UTC (permalink / raw
To: gentoo-dev
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:
> local:openssl: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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [gentoo-dev] Re: Why (i.e. USE="openssl" instead of USE="ssl")
2010-08-14 11:45 ` Chí-Thanh Christopher Nguyễn
@ 2010-08-14 16:28 ` Peter Hjalmarsson
2010-08-15 20:35 ` Maciej Mrozowski
0 siblings, 1 reply; 11+ messages in thread
From: Peter Hjalmarsson @ 2010-08-14 16:28 UTC (permalink / raw
To: gentoo-dev
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")?
^ permalink raw reply [flat|nested] 11+ messages in thread
* [gentoo-dev] Re: Why (i.e. USE="openssl" instead of USE="ssl")
2010-08-14 12:14 ` [gentoo-dev] " Samuli Suominen
@ 2010-08-14 16:29 ` Peter Hjalmarsson
2010-08-15 21:48 ` Gilles Dartiguelongue
2010-08-16 12:07 ` Peter Volkov
0 siblings, 2 replies; 11+ messages in thread
From: Peter Hjalmarsson @ 2010-08-14 16:29 UTC (permalink / raw
To: gentoo-dev
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?
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [gentoo-dev] Re: Why (i.e. USE="openssl" instead of USE="ssl")
2010-08-14 16:28 ` [gentoo-dev] " Peter Hjalmarsson
@ 2010-08-15 20:35 ` Maciej Mrozowski
0 siblings, 0 replies; 11+ messages in thread
From: Maciej Mrozowski @ 2010-08-15 20:35 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: Text/Plain, Size: 2149 bytes --]
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="env:pkg:conf:defaults:pkginternal: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
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [gentoo-dev] Re: Why (i.e. USE="openssl" instead of USE="ssl")
2010-08-14 16:29 ` [gentoo-dev] " Peter Hjalmarsson
@ 2010-08-15 21:48 ` Gilles Dartiguelongue
2010-08-16 12:07 ` Peter Volkov
1 sibling, 0 replies; 11+ messages in thread
From: Gilles Dartiguelongue @ 2010-08-15 21:48 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 1010 bytes --]
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
[-- Attachment #2: Ceci est une partie de message numériquement signée --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [gentoo-dev] Re: Why (i.e. USE="openssl" instead of USE="ssl")
2010-08-14 16:29 ` [gentoo-dev] " Peter Hjalmarsson
2010-08-15 21:48 ` Gilles Dartiguelongue
@ 2010-08-16 12:07 ` Peter Volkov
2010-08-16 16:11 ` Gilles Dartiguelongue
1 sibling, 1 reply; 11+ messages in thread
From: Peter Volkov @ 2010-08-16 12:07 UTC (permalink / raw
To: gentoo-dev
В Сбт, 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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [gentoo-dev] Re: Why (i.e. USE="openssl" instead of USE="ssl")
2010-08-16 12:07 ` Peter Volkov
@ 2010-08-16 16:11 ` Gilles Dartiguelongue
2010-08-16 17:45 ` Mike Frysinger
0 siblings, 1 reply; 11+ messages in thread
From: Gilles Dartiguelongue @ 2010-08-16 16:11 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [gentoo-dev] Re: Why (i.e. USE="openssl" instead of USE="ssl")
2010-08-16 16:11 ` Gilles Dartiguelongue
@ 2010-08-16 17:45 ` Mike Frysinger
2010-09-26 17:14 ` Petteri Räty
0 siblings, 1 reply; 11+ messages in thread
From: Mike Frysinger @ 2010-08-16 17:45 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [gentoo-dev] Re: Why (i.e. USE="openssl" instead of USE="ssl")
2010-08-16 17:45 ` Mike Frysinger
@ 2010-09-26 17:14 ` Petteri Räty
0 siblings, 0 replies; 11+ messages in thread
From: Petteri Räty @ 2010-09-26 17:14 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 842 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2010-09-26 17:12 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-08-14 11:26 [gentoo-dev] Why (i.e. USE="openssl" instead of USE="ssl") Peter Hjalmarsson
2010-08-14 11:45 ` Chí-Thanh Christopher Nguyễn
2010-08-14 16:28 ` [gentoo-dev] " Peter Hjalmarsson
2010-08-15 20:35 ` Maciej Mrozowski
2010-08-14 12:14 ` [gentoo-dev] " Samuli Suominen
2010-08-14 16:29 ` [gentoo-dev] " Peter Hjalmarsson
2010-08-15 21:48 ` Gilles Dartiguelongue
2010-08-16 12:07 ` Peter Volkov
2010-08-16 16:11 ` Gilles Dartiguelongue
2010-08-16 17:45 ` Mike Frysinger
2010-09-26 17:14 ` Petteri Räty
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox