ports/146038: make.conf variable WITH_OPENSSL_BASE is useless

[Pascal Stumpf]

On Tuesday 27 April 2010 06:47:22 dinoex at freebsd.org wrote:
> Synopsis: make.conf variable WITH_OPENSSL_BASE is 
useless
> 
> State-Changed-From-To: open->feedback
> State-Changed-By: dinoex
> State-Changed-When: Tue Apr 27 06:41:56 CEST 2010
> State-Changed-Why:
> 
> This port wants the OpenSSL library from the FreeBSD base 
system. You
> can't build against it, while a newer Version is installed by a 
port.
> Please deinstall the port or undefine WITH_OPENSSL_BASE.
> 
> This is not a bug.
> The linker would pick up the new libssl.so for ports
> and your application would crash.
> 
> so you either have to build it clean (Maybe a jail)
> or have it use the port.
> 
> Ports that don't build with the openssl port can be fixed.
> 
> For full backward comatibility, you may build the openssl port
> WITH_MD2=yes
> 
> 
> http://www.freebsd.org/cgi/query-pr.cgi?pr=146038
> 
Well, this is true in praxis, but shouldn’t WITH_OPENSSL_BASE= 
cause the linker to pick up base OpenSSL _instead_ of ports? 
People should be able to selectively link against ports of base 
OpenSSL using WITH_OPENSSL_(BASE|PORT)=, otherwise 
there’s no point in having these in the first place. 

For instance, I was forced to install the openssl port because 
base openssl breaks renegotiation, which security/tor relies on. 
Now, all other ports depending on openssl pick up the one 
from ports. If at some point in the future either tor no longer 
needs reneg or the base openssl gets fixed/updated, I no 
longer need the openssl port. But to get rid of the port, I have 
to reinstall _all_ ports depending on openssl. Meh. This 
wouldn’t have happened if one could specify in make.conf to 
only have tor linked against ports, but all others linked against 
base openssl.

So, I think the solution should be to temporarily adjust 
ldconfig(8) path when building a port WITH_OPENSSL_BASE=.