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