Re: the path to openssl3

[Tobias Nygren <tnn%NetBSD.org@localhost>]

On Sun, 03 Sep 2023 19:25:41 -0400
Greg Troxel <gdt%lexort.com@localhost> wrote:

>   Another path is adding security/openssl3, namespacing the binaries and
>   adding OPENSSL_VERSIONS_ACCEPTED and OPENSSL_VERSIONS_INCOMPATIBLE as
>   11 30 31.  Each could have a builtin.  This is messy as a program
>   could want to have both indirectly and that's ungood, maybe doubleplus
>   ungood.

I don't like this approach but unfortunately it is necessary. Right now
we have the problem that some abandonware doesn't build with openssl 3.
But a couple of years down the road we will have the opposite problem:
Maintained software will ONLY work with openssl 3, important packages
will start to break on NetBSD <10 and it will be necessary to blanket
require openssl from pkgsrc on that subset of platforms to maintain
some sort of sanity.

I would prefer however if security/openssl can just go to 3 and we
re-import security/openssl11 with alternate libdir/incdir patches.
Similar to how RHEL9 added a compat-openssl11 package to deal with
this problem. The VERSIONS_ACCEPTABLE/VERSIONS_INCOMPATIBLE stuff can
IMHO wait and we just point abandonware packages directly at
openssl11's bl3.mk.

-Tobias