On Wed, Sep 30, 2015 at 2:35 AM, Paweł Hajdan, Jr. <phajdan...@gentoo.org> wrote: > On 9/29/15 3:32 PM, Rich Freeman wrote: >> The thing is that I think the libressl authors are shooting themselves >> in the feet. When upstreams do this sort of thing they think they're >> making the upgrade path easier by not changing their symbol names. In >> reality, they're making the upgrade path harder by preventing >> side-by-side adoption of the new solution. > > Yeah, it's not that obvious how to handle it best. > > Curious - how would the alternative look like? My reasoning is that if > upstream changes symbols, that makes it easy for a distro to install it > side-by-side. However, for anything to use such modified lib, they'd > need to change all callers to use the alternative function names, > wouldn't they?
Essentially, or somebody has to write a wrapper library. But, once you start changing the APIs everybody has to start tweaking their code anyway to use the modified function prototypes. Of course, they only need to tweak the 10% of functions that changed, and not all of them. Effectively it would mean that the new library would start out with zero users, which is why nobody does it that way. However, I think the end result is worse, unless you maintain strict compatibility. It hasn't been as much of a problem with mariadb because they haven't gone changing all their APIs/protocols/etc. This is the sort of thing that Java was trying to stop with their compatibility requirements, and what a lot of companies try to do with trademark. The problem is that trademark doesn't really extend well into things like symbol names and APIs. Perhaps the in-between solution would be for forking upstreams to preserve the same symbol names as long as the APIs are identical, and change them when they are not. I don't really see that having any more impact on downstream consumers than silently changing the APIs and it would probably get rid of the symbol collision problem. -- Rich
