On Wed, Sep 30, 2015 at 8:10 AM, Kristian Fiskerstrand <k...@gentoo.org> wrote: > > On 09/30/2015 01:51 PM, Rich Freeman wrote: >> >> I think it was fair to pause to see if somebody could come up with >> a better solution that allows co-existence, but absent that I >> don't see any benefit from keeping libressl out of the tree. >> We'll just experience all the downsides of the fork without the >> upsides. > > This is what worries me as well, as it increase workload and > complexity affecting multiple projects without any immediate and > obvious gain.
True, but that is the consequence of the decision to fork openssl in this manner, and a possible future decision of downstream projects to follow the fork or not (which may or may not happen). It isn't actually the result of a decision to allow libressl in the tree or not. That is, if apache decides to stick with openssl but postfix decides to move to libressl, then users who want to use both with ssl support are going to have a really hard time no matter what actions we take as a distro, unless it involves patching the living daylights out of one of the two pairs of software. > > Immediately I would think we'd need namespace isolation inspired by > NixOS etc for this to work, but that isn't something that would easily > be implemented and quite frankly would look scarily similar to Go's > static linking and issues. > I thought a bit about that, but it isn't actually super-clean even if you go sticking uuids on everything. Suppose apache uses libfoo and libbar. Libfoo switches to libressl, and libbar sticks with openssl. That is going to create a mess no matter what you do with isolating their namespaces, because you're forced to bring it all back together and not all software is designed to handle that today (especially when you're not using --as-needed, etc). Flameeyes's blog entry keeps coming up: https://blog.flameeyes.eu/2008/06/a-few-risks-i-see-related-to-the-new-portage-2-2-preserve-libs-behaviour It really seems to me that the proper solution to symbol versioning should be somehow built into the spec and should take into account situations like these. When I look around for solutions it seems like everything comes down to hacks because the original design of C left all of this out. -- Rich
