| 1 |
On Mon, Oct 5, 2015 at 11:28 AM, Jason A. Donenfeld <zx2c4@g.o> wrote: |
| 2 |
> I assume there are developers hard |
| 3 |
> at work adding the flag to each and every package. |
| 4 |
|
| 5 |
Keep in mind that it isn't always a drop-in replacement. If it were |
| 6 |
we'd just make a virtual for libssl and you wouldn't need to mess with |
| 7 |
flags at all. |
| 8 |
|
| 9 |
Some upstreams may support libressl quickly, some might support it |
| 10 |
more slowly, and some may or may not ever support it. So, I suspect |
| 11 |
that this will look a lot like trying to switch over to libav - you |
| 12 |
might have to change what applications you're using in some cases if |
| 13 |
you really want to do it. As with libav you may see one library or |
| 14 |
the other "win" in the end which should make things simpler, but I |
| 15 |
suspect that in the meantime there may be a lot of bundling/etc. |
| 16 |
|
| 17 |
When changes require patches and upstream hasn't committed to merging |
| 18 |
them, that creates a potential maintenance burden and if package |
| 19 |
maintainers aren't willing to undertake this then we should probably |
| 20 |
figure out how that is going to work, unless we just plan to ignore |
| 21 |
these packages for now. |
| 22 |
|
| 23 |
If it is just a matter of sticking a simple sed in an ebuild and the |
| 24 |
libressl team doesn't mind dealing with rare breakage that is probably |
| 25 |
less of an issue. |
| 26 |
|
| 27 |
-- |
| 28 |
Rich |
Archives