On Sun, Apr 5, 2015 at 8:23 AM, Diego Elio Pettenò <flamee...@flameeyes.eu> wrote: > > Since as you point out the two packages are vastly API compatible, it makes > them ABI incompatible and conflicting.
++ If they really want to improve the security of function calls that they consider inherently secure, they should just introduce new functions and deprecate the old ones, or make old ones wrappers around new ones if that is appropriate. If they go with the deprecation route then they need to avoid using the same SONAMEs, and if they go the wrapper route they need to make sure that they're compatible across SONAMEs. Of course, any re-implementation could have bugs, but the key is that upstream has to recognize these incompatibilities as being valid bugs that they intend to fix. Right now if something designed to link against openssl breaks against libressl there is a good chance that libressl will just say it is intentional, which then leaves us in the position of having to deal with the mess. I agree that renaming things isn't a great solution either, and that this really needs to be fixed upstream. However, I don't really like it going into the tree the way it is, because sooner or later we're going to end up with blockers or bugs. Either you can't install foo with barssl, or you can, and it just might break but nobody really keeps track of that. It really doesn't matter which is the better implementation - this is just a really messy way to do a transition. -- Rich
