tech-pkg archive

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

Adding mk/

Would anyone object to me making a pass through the tree to replace

.include "../../security/openssl/"


.include "../../mk/"

and adding a simple mk/ which just includes

This is to
- make it easier to for people to test openssl3 before it's ready for
general switch by just modifying one file
- provide a single point to later modify to select openssl1 vs openss3
on a per platform basis


On Thu, 30 Sept 2021 at 15:29, Greg Troxel <> wrote:
> David Brownlee <> writes:
> >> 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.
> What I meant was that being able to select versions requires adding a
> mk/bl3, not that adding a mk/bl3 forces anything.
> > 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
> > switch
> > - allow more nuance on choosing openssl1 vs 3 on a platform and system basis
> I think that's all good.  It's clear that there are people that want
> openssl3 now and people that want to stay with 1.1.1 for now, as it has
> upstream support and everything works.
> And, netbsd-current is likely going to get openssl3 soon.
> > The initial commit could be as simple as adding a mk/
> > which unconditionally includes ../../security/openssl/,
> > plus an extra check to pkglint
> Having a mk/bl3 and a switch for openssl 1.1.1 vs 3 (one global switch)
> with platform-specific defaults sounds like a reasonable near-term
> approach.
> Barring objections, which I don't expect, if you are inclined to start
> on this, that sounds good.

Home | Main Index | Thread Index | Old Index