[MacPorts] #51516: MacPorts should use a bundled copy of a newer libcurl and SSL library rather than the OS X version

[MacPorts]

#51516: MacPorts should use a bundled copy of a newer libcurl and SSL library
rather than the OS X version
--------------------------+--------------------------------
  Reporter:  ryandesign   |      Owner:  macports-tickets@…
      Type:  enhancement  |     Status:  new
  Priority:  Normal       |  Milestone:  MacPorts Future
 Component:  base         |    Version:
Resolution:               |   Keywords:
      Port:               |
--------------------------+--------------------------------

Comment (by RJVB):

 Replying to [comment:147 kencu]:
 > with two level namespaces, can we just rename Pextlib.dylib to Pextlib-
 updated-curl.dylib and expect it to work like that...?

 I'd say yes, given that loading `Pextlib.dylib.orig` worked. Semantically
 speaking I prefer to rename the old library and install the new one under
 the expected name. It's only a fallback after all.

 > Is there anything that links against Pextlib.dylib?

 Not as far as I can tell. And if the trace functionality is standalone
 enough that it could be moved into the registry library Pextlib also
 wouldn't have to link against libcregistry. (Standalone as in not
 requiring other functions that should remain in Pextlib.)



 Replying to [comment:146 kencu]:
 > I would humbly suggest we just forget about the fancy new build system,
 and just build all of base using it's existing build system (and using the
 base source files downloaded in every macports install, why not?)[...]

 > This seems 100x easier, and has zero maintenance burden, at the cost of
 a trivial amount of building time.

 As you may have guessed I'm also not looking for more work than required.
 If it's OK to build against (header)files from the source bundle rather
 than against the already install files than that makes things a lot
 easier, at the risk of making the Portfile a little more complex.

 It's probably possible too to add a `configure` argument to make the build
 use headers from `$prefix/libexec/macports/include` instead of from
 `vendor/vendor-destroot/$prefix/libexec/macports/include`.

 It won't be necessary to build all of the base install, I think, but I'll
 find out. We definitely shouldn't have to destroot the entire base
 install.

 We will need to look into that `libcregistry` dependency though... can we
 build against the one in the source tree and then use the original one at
 runtime or will we actually need to install newer versions of both. The
 test I ran yesterday suggests we don't but I am not familiar with that
 part of Pextlib so don't really know how to test it.

 (My experience with trace mode from long ago is that it always found
 something it wasn't happy with.)

-- 
Ticket URL: <https://trac.macports.org/ticket/51516#comment:148>
MacPorts <https://www.macports.org/>
Ports system for macOS