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