FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 12-15-2009, 07:05 AM
Peter Volkov
 
Default USE flag(s) for ssl (always USE ssl)

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).


This way ssl USE flag will work as intended (enable best (upstream
suggested) ssl implementation) but still keeps flexibility to select
preferred implementation for cases where package supports alternatives.
Are there any objections for such general solution?

--
Peter.
 
Old 12-15-2009, 07:15 AM
Ulrich Mueller
 
Default USE flag(s) for ssl (always USE ssl)

>>>>> 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
 
Old 12-15-2009, 07:48 AM
Mike Frysinger
 
Default USE flag(s) for ssl (always USE ssl)

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
 
Old 12-15-2009, 09:27 AM
Peter Volkov
 
Default USE flag(s) for ssl (always USE ssl)

В Втр, 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.
 

Thread Tools




All times are GMT. The time now is 02:51 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org