[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:151 neverpanic]:
 > Note that I don't think this port should modify any of the files
 installed by base (things might end up breaking when base is updated, or
 the port is updated). Instead, just modify the `pkgIndex.tcl` shipped by
 base to opportunistically load the library from `$prefix` if it is
 installed.

 We could call the new Pextlib `Pextlib.dylib.new` or some variation on
 that, rather than renaming the old version but I don't think there's any
 difference from the point of view of pkgIndex.tcl. Just the content of a
 variable that changes; the old version will always be loaded as a fallback
 if the new version fails to load, in the scheme I propose.

 The only difference where installing the new library under a new name
 might make a practical difference is that there would not be a dangling,
 old Pextlib.dylib.orig . That seems cleaner, but I am not yet convinced
 that it is the better option since I was planning to use its presence and
 timestamp as a state variable to determine whether pkgIndex.tcl needed to
 be rewritten. Maybe we can do without that, I'll see.

 Either way, reinstalling "base" will also reinstall pkgIndex.tcl and thus
 undo the changes made by `port:MacPorts-pextlib`. I would expect that in
 case of an "upgrade reinstall" there would also be an accompanying upgrade
 to `port:MacPorts-pextlib` to restore use of `port:MacPorts-libcurl`. The
 user reinstalling "base" for some other reason is another can of worms; no
 clever ideas how to re-activate `port:MacPorts-pextlib` reliably and
 without modifying "base" come to mind. (We could install a copy of the
 modified pkgIndex.tcl and check for differences between the 2 loaders).

 I do think it's better if the new version of the library is installed in
 the designated directory (libexec/macports/lib/pextlib1.0) rather than in
 a more common location.

 > That would also give us the option to not blow up things should
 `Pextlib.dylib` ever change ABI, because it could then introduce a version
 number (e.g., `Pextlib.2.dylib`), and installing that base update would
 automatically attempt to load `Pextlib.2.dylib` from `$prefix`, instead of
 loading the old one and potentially crashing.

 I was already proposing to rewrite pkgIndex.tcl to load the new Pextlib
 and fall back to loading the original version in case of failure, so I
 think I already had this covered.
 Wouldn't a v2.0 ABI Pextlib install to `lib/pextlib2.0/Pextlib.dylib`, so
 that the Tcl syntax could also be changed to `package require Pextlib
 2.0`?
 But ... changing the ABI of a plugin, isn't that a little bit farfetched
 or if not, shouldn't it already have changed a few releases back when
 `vercmp` was added? ;)

 > As a consequence, I don't think you need any kind of compatibility for
 older base releases.

 Good, that makes things easier. Not that it seems to be a big problem
 anyway; the Pextlib from MacPorts 2.9.3 seems to work just fine in a
 2.7.1.x install (but I haven't yet done any port install or
 de/activation).

 I still think it could be wise to drop the dependency on the registry
 dylib by moving the function(s) that need it into that library itself.
 Would that be an option?

 (PS: Trac is getting on my nerve when writing longer replies like this
 because it shifts the edit box out of view when refreshing the preview.
 Frequently but not systematically and I haven't yet figured out when it
 does and when it doesn't. Is there something I can do about that from my
 end?)

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