tech-pkg archive

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

Re: OpenSSL 3.0.0 compatibility

On Thu, 30 Sept 2021 at 13:36, Greg Troxel <> wrote:
> David Brownlee <> writes:
> > On Thu, 30 Sept 2021 at 08:48, Jonathan Perkin <> wrote:
> >>
> >> * On 2021-09-30 at 01:03 BST, Greg Troxel wrote:
> >>
> >> >  I don't see wip/openssl at 3.0.0, which is how most people would build
> >> >  a not-yet-in-pkgsrc version, together with some variable  to force
> >> >  pkgsrc openssl after it's installed, and a note explaining that, so
> >> >  they too can play the "catch up with API breaks" game.
> >>
> >> Until we move to a proper mk/ there's little point
> >> having a wip/openssl as security/openssl is hardcoded in hundreds of
> >> places.
> >
> > Is it worth someone doing a pass to add mk/ first?
> >
> > That would get a large rototill which _should_ not break any builds
> > out of the way first, then make it easier to test switching openssl
> > versions.
> This really bears on the question of whether openssl3 is optional or
> required.  Right now netbsd 9 has 1.1.1 and that's likely to continue,
> and I don't think it's good to force those systems that to move to 3,
> especially since 3 has at this point been out less than a month.

Adding mk/ now does not require any decision on
whether and when some or all systems switch to openssl3. It does:
- split changes to use mk/ from changes to make
things work under openssl3 (akin to making a refactoring pass to
rename methods as a separate commit to adding functionality :)
- make it reasonable to add security/openssl3 to pkgsrc and to give an
easier way for people to test openssl3 before it's ready for general
- allow more nuance on choosing openssl1 vs 3 on a platform and system basis

The initial commit could be as simple as adding a mk/
which unconditionally includes ../../security/openssl/,
plus an extra check to pkglint


Home | Main Index | Thread Index | Old Index