Re: openssl-1.0-only packages?

[Thomas Klausner <tk%giga.or.at@localhost>]

On Mon, Feb 19, 2018 at 09:10:50AM -0500, Greg Troxel wrote:
> 
> Thomas Klausner <tk%giga.or.at@localhost> writes:
> 
> > Since openssl changed their API from 1.0 to 1.1, many programs need
> > patches to work; however, they don't seem to exist (yet) or upstream
> > decided not to support 1.1. For example, this seems to be the case for
> > python-3.4.x (3.5+ is ok), ruby-2.2 (ruby 2.4+ is ok, 2.3 is
> > patchable), php-5.6 (php-7+ is ok), ffmpeg2 (ffmpeg3 is fine), and
> > some other smaller packages.
> >
> > Some distributions also provide openssl-1.0 packages, installed into a
> > separate sub-prefix (${PREFIX}/include/openssl-1.0 or so).
> >
> > Do we want to go that way as well?
> >
> > For leaf packages, I think that would be an appropriate solution, but
> > I worry for other packages that you might end up with a mix of
> > openssl-1.1 and openssl-1.0 libraries in the same binary.
> 
> This is a really good argument for openssl not changing their API :-)
> 
> I realize this is brought on by -current, but a related issue is when
> it's appropriate to switch pkgsrc to 1.1.  It feels like not yet, as I
> don't think we really understand the consequences and if it's a net win.
> 
> I think moving pkgsrc openssl to 1.1 is out of the question before
> 2018Q1.
> 
> I suspect we're going to need the sub-prefix 1.0 as we update to 1.1, in
> order to avoid breaking half of pkgsrc.   Despite the troubles, it seems
> worthwhile as part of making the most of a bad situation.
> 
> Are you suggesting some way for packages to build against pkgsrc 1.0
> while system is at 1.1, as a first step, before pkgsrc is updated?

I'm not really sure about the solution, but I'm thinking of something
like adding an openssl-1.0 package with its own prefix, switching the
packages that need that version to it, and updating openssl to 1.1.
 Thomas