* Re: [gentoo-dev] USE flag(s) for ssl (always USE ssl)
[not found] <1260864333.29419.59.camel@tablet>
@ 2009-12-15 8:15 ` Ulrich Mueller
2009-12-15 10:27 ` Peter Volkov
2009-12-15 8:48 ` Mike Frysinger
1 sibling, 1 reply; 3+ messages in thread
From: Ulrich Mueller @ 2009-12-15 8:15 UTC (permalink / raw
To: gentoo-dev
>>>>> On Tue, 15 Dec 2009, Peter Volkov wrote:
> If package has ssl support use ssl USE flag for that. In case there
> are alternatives, use openssl/gnutls/nss for upstream _less_
> recommended implementation(s).
Small problem: If a user enables more than one of openssl/gnutls/nss
then he'll get the less recommended implementation.
I'd rather add the USE flag for the upstream recommended
implementation too, and enable it with highest priority in case of
conflicting flags.
Ulrich
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [gentoo-dev] USE flag(s) for ssl (always USE ssl)
[not found] <1260864333.29419.59.camel@tablet>
2009-12-15 8:15 ` [gentoo-dev] USE flag(s) for ssl (always USE ssl) Ulrich Mueller
@ 2009-12-15 8:48 ` Mike Frysinger
1 sibling, 0 replies; 3+ messages in thread
From: Mike Frysinger @ 2009-12-15 8:48 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: Text/Plain, Size: 1099 bytes --]
On Tuesday 15 December 2009 03:05:33 Peter Volkov wrote:
> Hi. How do we choose USE flags in case package supports different ssl
> implementations?
>
> Currently we do this differently: 1. some packages use ssl USE flag and
> additional gnutls (or openssl) to select alternative ssl implementation,
> 2. other packages already started to avoid ssl USE flag completely and
> use only openssl/gnutls/nss.
>
> The latter makes things harder for those who want ssl enabled packages
> on the system and don't care about implementation. Also it is not
> intuitive to have packages without ssl with ssl USE flag enabled system
> wide. So I would like to ban latter solution and suggest the following:
>
>
> If package has ssl support use ssl USE flag for that. In case there are
> alternatives, use openssl/gnutls/nss for upstream _less_ recommended
> implementation(s).
USE=ssl should select *some* implementation. the finer grained
openssl/gnutls/nss can be used to select a specific implementation, but not
respecting USE=ssl is broken. curl is an example of this.
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [gentoo-dev] USE flag(s) for ssl (always USE ssl)
2009-12-15 8:15 ` [gentoo-dev] USE flag(s) for ssl (always USE ssl) Ulrich Mueller
@ 2009-12-15 10:27 ` Peter Volkov
0 siblings, 0 replies; 3+ messages in thread
From: Peter Volkov @ 2009-12-15 10:27 UTC (permalink / raw
To: gentoo-dev
В Втр, 15/12/2009 в 09:15 +0100, Ulrich Mueller пишет:
> >>>>> On Tue, 15 Dec 2009, Peter Volkov wrote:
> > If package has ssl support use ssl USE flag for that. In case there
> > are alternatives, use openssl/gnutls/nss for upstream _less_
> > recommended implementation(s).
>
> Small problem: If a user enables more than one of openssl/gnutls/nss
> then he'll get the less recommended implementation.
This problem is even worse in case there is no ssl USE flag. There will
be no way to ask for best ssl implementation and user will have to think
and select suggested implementation for each package separately.
> I'd rather add the USE flag for the upstream recommended
> implementation too, and enable it with highest priority in case of
> conflicting flags.
In case upstream has hard priorities I think ewarn is enough (or just
drop broken implementations). Adding more conflicting USE flags just
makes situation worse.
--
Peter.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-12-15 12:08 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1260864333.29419.59.camel@tablet>
2009-12-15 8:15 ` [gentoo-dev] USE flag(s) for ssl (always USE ssl) Ulrich Mueller
2009-12-15 10:27 ` Peter Volkov
2009-12-15 8:48 ` Mike Frysinger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox