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?
Attachment:
signature.asc
Description: PGP signature