On 04/05/2015 01:17 PM, Rich Freeman wrote: > If you're going to fork a library, and don't intend to keep the > packages API-compatible, then change the filenames. What is so hard > about this? LIbressl was even an outside fork, so it didn't come with > any of the baggage of "we're the real libssl team" or whatever.
Libressl is (widely) API compatible with openssl. As said numerous times before: they broke the API when they thought it is security relevant. This is about the fact that they _added_ features which are not present in openssl. However, openntpd still compiles with openssl. > > Sure, we can do the USE=libressl route like we did with libav, but > since this is still new would it make more sense to just rename the > libressl files so that they can still go in /usr/lib but without being > called libssl? Then any package that wants to use them will need to > have their build logic changed accordingly. They aren't drop-in > replacements for each other anyway, as much as people would wish they > were, so we should resist the urge to pretend that they are. > By that you are effectively forking libressl and causing a huge mess downstream for both developers and users. It may even cause cross-distro breakage. I can name several examples of this happening due to debian going it's own way. Last of which affected openclonk (upstream merged a patch from a debian dev who expected any distro does the same hacks they do). So please, have a little sense for QA. Those ideas are just making it 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.
