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

MacPorts noreply at macports.org
Tue Jun 4 11:47:34 UTC 2024


#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:137 kencu]:
 > well the focus at the moment is not really who can come up with the
 leanest minimalcurl port, or even which ssl backend has the fewest deps.

 True. I just jumped on it because I like the idea of using a backend that
 uses a library that's OpenSSL-compatible but otherwise independent of
 OpenSSL. The only nuisance is the fact that currently the entire
 `port:openssl` has to be deactivated to build curl against a co-
 installable LibreSSL. That's curl's fault, but given what `port:openssl`
 is nowadays it should be trivial to split it up into runtime and a
 builders'-only subports.
 >
 > it really is : can the idea work?

 I'm currently getting a longer-term answer if it can work with my usual
 hack of a relinked Pextlib.so but I already have sufficient practical
 proof that that approach worked with a previous version of libcurl (using
 GnuTLS).

 > Can we build and insert a new Pextlib into base (this part should be
 easy enough) ?

 Yes. Building the library could probably even be handled with a hand-
 written `Makefile.something` if a dependency on another build system is
 not desirable

 > Can we rewrite the TCL code in base to use the new library, if it
 exists, in a way that works reliably and Josh can accept (this is the
 million dollar question)?

 From what I've seen this could be as simple as rewriting `pkgIndex.tcl`
 from an appropriate phase of the hypothetical `port:MacPorts-pextlib`.
 That's the actual loader for the `package require Pextlib 1.0` syntax from
 what I understand. It is (presumably) generated when MacPorts is being
 built so rewriting the installed version should be safe enough. I've
 already done this to preload my curl glue library, and that worked so this
 should too:

 {{{
 # Tcl package index file, version 1.1
 # This file is generated by the "pkg_mkIndex" command
 # and sourced either when an application starts up or
 # by a "package unknown" script.  It invokes the
 # "package ifneeded" command to set up package-related
 # information so that packages will be loaded automatically
 # in response to "package require" commands.  When this
 # script is sourced, the variable $dir must contain the
 # full path name of this file's directory.

 if {![file exists ${dir}/Pextlib.dylib]} {
       set PEXTLIB ${dir}/Pextlib.dylib.orig
 } else {
       set PEXTLIB ${dir}/Pextlib.dylib
 }
 package ifneeded Pextlib 1.0 [list load [file join $dir ${PEXTLIB}]]
 }}}

 In case it isn't clear ;), this presumes that `port:MacPorts-pextlib`
 installs `${prefix}/libexec/macports/pextlib1.0/Pextlib.${os.shext}`,
 renaming the original library first. The loader script then falls back to
 loading the renamed library if the new one isn't there, allowing to
 deactivate `port:MacPorts-pextlib` in case there's a reason to trouble-
 shoot it, or to maintain "base" functionality if ever an update glitches
 for some reason.

 `port:MacPorts-pextlib`  would have a pre-activate :

 {{{
 proc rewrite_pkgIndex {} {
 # add a fallback to pkgIndex.tcl
 }

 pre-activate {
     # move the original library out of the way if not already done
     if {![file exists
 ${prefix}/libexec/macports/pextlib1.0/Pextlib.${os.shext}.orig]} {
         file rename
 ${prefix}/libexec/macports/pextlib1.0/Pextlib.${os.shext} \
             ${prefix}/libexec/macports/pextlib1.0/Pextlib.${os.shext}.orig
         rewrite_pkgIndex
     } else {
         # just in case!
         file delete -force
 ${prefix}/libexec/macports/pextlib1.0/Pextlib.${os.shext}
     }
 }
 }}}

 I use a pre-activate to avoid an activation conflict, and the presence or
 not of the backed-up library as a condition for rewriting the pkgIndex
 loader. This will break after updating "base"; it would be better to use
 the content of the loader script to determine whether a
 `Pextlib.dylib.orig` from a previous MacPorts version needs to be replaced
 with the current `Pextlib.dylib` and `pkgIndex.tcl` rewritten again. That
 was just a bit too cumbersome to type into this editor :)

 (BTW: it would be really handy if an `os.shext` or similar variable were
 defined by "base"!)

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


More information about the macports-tickets mailing list