> From: hasufell
> Sent: Sunday, April 05, 2015 4:34 AM
> 
> However, openntpd still compiles with openssl.

Well, the current stable openntpd in portage compiles with openssl but that's 
not surprising as it is ancient and predates libressl :). The current unstable 
openntpd actually has no ssl dependencies and needs neither openssl nor 
libressl to compile and function. It is the most recent upstream portable 
release that added an optional dependency on libressl for tls constraint 
functionality, that version is not yet in portage. It will work without 
libressl just as well as the current unstable openntpd does, you just won't 
have access to the new feature. So it's not really critical, but at some point 
it would be nice to get it working one way or the other.

> By that you are effectively forking libressl and causing a huge mess
> downstream for both developers and users.

What are the downsides of the approach pkgsrc is tentatively taking, where 
there are no modifications to libressl but the libraries are installed in an 
alternative location? Packages that require libressl can just use the 
appropriate linker options to find those libraries rather than the openssl ones?

> worse. This is something that has to be resolved upstream. If they don't
> cooperate long-term, then their fork will just die out for sure (and for
> good). However, I currently don't see strong signs for that.

I don't think their fork will ever die; even if no one outside of openbsd uses 
the portable version, it is now the official ssl provider for openbsd and I am 
sure will continue to be used by them as well as the portable versions of any 
of their other applications such as openntpd...



Reply via email to