1 |
On Tue, Sep 29, 2015 at 8:22 AM, hasufell <hasufell@g.o> wrote: |
2 |
> No useful comments, so I will proceed as outlined in the transition plan. |
3 |
> |
4 |
|
5 |
I don't think your attitude is going to win you a lot of friends, and |
6 |
I don't think that we're better off for it. |
7 |
|
8 |
That said, I've yet to hear a workable alternative, and I don't have |
9 |
one to offer myself. I don't really like what has happened with |
10 |
kerberos and ffmpeg and mysql, and I'm not looking forward to what is |
11 |
going to happen with libressl. I fear that as with the other |
12 |
situations we'll end up with one solution used by 99% of systems, and |
13 |
another solution used by 1% of systems, and no happy compromise that |
14 |
lets people mix and match software that relies on either. That really |
15 |
doesn't strike me as the Gentoo way. |
16 |
|
17 |
However, unless people stop promoting and/or using competing solutions |
18 |
that share the same namespaces we're going to have these problems, and |
19 |
we have to live with reality and not pretend that it doesn't exist. |
20 |
|
21 |
If somebody can come up with a better solution, I'm all ears. What |
22 |
hasufell proposes isn't any worse than what we already have. It just |
23 |
fails to be any better. |
24 |
|
25 |
As was pointed out there are some fundamental issues with just trying |
26 |
to slot something like this unless you go patching the living |
27 |
daylights out of the library and everything that uses it. |
28 |
|
29 |
The thing is that I think the libressl authors are shooting themselves |
30 |
in the feet. When upstreams do this sort of thing they think they're |
31 |
making the upgrade path easier by not changing their symbol names. In |
32 |
reality, they're making the upgrade path harder by preventing |
33 |
side-by-side adoption of the new solution. |
34 |
|
35 |
-- |
36 |
Rich |