1 |
Solution: |
2 |
|
3 |
Packages that will compile against either one get "|| (openssl libressl)". |
4 |
Packages that require a specific one will just have that one listed. |
5 |
Openssl will block Libressl and vice versa. |
6 |
|
7 |
The result of this arrangement is that systems that require few packages |
8 |
will probably be able to have libressl installed, so long as all their |
9 |
ssl-using apps are okay with libressl. Systems that require openssl-only |
10 |
packages won't get libressl. Then, overtime, upstreams and patch writers |
11 |
will gradually fill in the gaps, and eventually most packages will support |
12 |
both. |
13 |
|
14 |
This is the reasonable evolutionary approach. And it'll provide a good |
15 |
ground for gradually rolling out libressl support. |
16 |
On Apr 5, 2015 10:35 PM, "hasufell" <hasufell@g.o> wrote: |
17 |
|
18 |
> On 04/05/2015 08:59 PM, Rich Freeman wrote: |
19 |
> > On Sun, Apr 5, 2015 at 2:35 PM, hasufell <hasufell@g.o> wrote: |
20 |
> >> |
21 |
> >> You are ranting at the wrong place. If you want to make a difference, |
22 |
> >> take this to the openbsd mailing lists. |
23 |
> >> |
24 |
> > |
25 |
> > It seems unlikely that this would make much of a difference. |
26 |
> |
27 |
> It doesn't make one here. |
28 |
> |
29 |
> > I think |
30 |
> > that allowing this package to create another ffmpeg vs libav mess is a |
31 |
> > mistake. |
32 |
> > |
33 |
> |
34 |
> If you want to do some crazy downstream hackery, you'll have to do that |
35 |
> yourself and count me out. It's not even clear what you want to fix. |
36 |
> |
37 |
> It was known from the start that we do not have ABI-compatibility. |
38 |
> |
39 |
> The only "problem" right now are libressl-exclusive features. These are |
40 |
> currently optional codepaths afais, so packages still compile with openssl. |
41 |
> |
42 |
> Everything else is future prediction. That's why libressl is still in an |
43 |
> overlay. |
44 |
> |
45 |
> |