tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: openssl-1.0-only packages?

Thomas Klausner <> 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

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

Home | Main Index | Thread Index | Old Index