| 1 |
On Wed, Sep 30, 2015 at 8:10 AM, Kristian Fiskerstrand <k_f@g.o> wrote: |
| 2 |
> |
| 3 |
> On 09/30/2015 01:51 PM, Rich Freeman wrote: |
| 4 |
>> |
| 5 |
>> I think it was fair to pause to see if somebody could come up with |
| 6 |
>> a better solution that allows co-existence, but absent that I |
| 7 |
>> don't see any benefit from keeping libressl out of the tree. |
| 8 |
>> We'll just experience all the downsides of the fork without the |
| 9 |
>> upsides. |
| 10 |
> |
| 11 |
> This is what worries me as well, as it increase workload and |
| 12 |
> complexity affecting multiple projects without any immediate and |
| 13 |
> obvious gain. |
| 14 |
|
| 15 |
True, but that is the consequence of the decision to fork openssl in |
| 16 |
this manner, and a possible future decision of downstream projects to |
| 17 |
follow the fork or not (which may or may not happen). It isn't |
| 18 |
actually the result of a decision to allow libressl in the tree or |
| 19 |
not. |
| 20 |
|
| 21 |
That is, if apache decides to stick with openssl but postfix decides |
| 22 |
to move to libressl, then users who want to use both with ssl support |
| 23 |
are going to have a really hard time no matter what actions we take as |
| 24 |
a distro, unless it involves patching the living daylights out of one |
| 25 |
of the two pairs of software. |
| 26 |
|
| 27 |
> |
| 28 |
> Immediately I would think we'd need namespace isolation inspired by |
| 29 |
> NixOS etc for this to work, but that isn't something that would easily |
| 30 |
> be implemented and quite frankly would look scarily similar to Go's |
| 31 |
> static linking and issues. |
| 32 |
> |
| 33 |
|
| 34 |
I thought a bit about that, but it isn't actually super-clean even if |
| 35 |
you go sticking uuids on everything. |
| 36 |
|
| 37 |
Suppose apache uses libfoo and libbar. Libfoo switches to libressl, |
| 38 |
and libbar sticks with openssl. That is going to create a mess no |
| 39 |
matter what you do with isolating their namespaces, because you're |
| 40 |
forced to bring it all back together and not all software is designed |
| 41 |
to handle that today (especially when you're not using --as-needed, |
| 42 |
etc). Flameeyes's blog entry keeps coming up: |
| 43 |
https://blog.flameeyes.eu/2008/06/a-few-risks-i-see-related-to-the-new-portage-2-2-preserve-libs-behaviour |
| 44 |
|
| 45 |
It really seems to me that the proper solution to symbol versioning |
| 46 |
should be somehow built into the spec and should take into account |
| 47 |
situations like these. When I look around for solutions it seems like |
| 48 |
everything comes down to hacks because the original design of C left |
| 49 |
all of this out. |
| 50 |
|
| 51 |
-- |
| 52 |
Rich |
Archives