Solution: Packages that will compile against either one get "|| (openssl libressl)". Packages that require a specific one will just have that one listed. Openssl will block Libressl and vice versa.
The result of this arrangement is that systems that require few packages will probably be able to have libressl installed, so long as all their ssl-using apps are okay with libressl. Systems that require openssl-only packages won't get libressl. Then, overtime, upstreams and patch writers will gradually fill in the gaps, and eventually most packages will support both. This is the reasonable evolutionary approach. And it'll provide a good ground for gradually rolling out libressl support. On Apr 5, 2015 10:35 PM, "hasufell" <hasuf...@gentoo.org> wrote: > On 04/05/2015 08:59 PM, Rich Freeman wrote: > > On Sun, Apr 5, 2015 at 2:35 PM, hasufell <hasuf...@gentoo.org> wrote: > >> > >> You are ranting at the wrong place. If you want to make a difference, > >> take this to the openbsd mailing lists. > >> > > > > It seems unlikely that this would make much of a difference. > > It doesn't make one here. > > > I think > > that allowing this package to create another ffmpeg vs libav mess is a > > mistake. > > > > If you want to do some crazy downstream hackery, you'll have to do that > yourself and count me out. It's not even clear what you want to fix. > > It was known from the start that we do not have ABI-compatibility. > > The only "problem" right now are libressl-exclusive features. These are > currently optional codepaths afais, so packages still compile with openssl. > > Everything else is future prediction. That's why libressl is still in an > overlay. > >
