[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
Sat Jun 8 19:09:42 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):

 Some more thinking aloud, sorry.

 If we want `port:MacPorts-libcurl` to follow the latest curl release at
 some distance or with some delay, we will in fact not be able to do
 without having both a runtime version (installing
 `$prefix/libexec/macports/lib/pextlib1.0/libcurl-mp.dylib`) and a "-dev"
 port that installs all the rest in an appropriately hidden location (also
 under `libexec/macports`?) but with its `libcurl-mp.4.8.dylib` or whatever
 turned into a symlink into the pextlib directory.

 Rationale: people need to be to install the dependent `port:MacPorts-
 pextlib` from source even if `port:curl` is at a newer version, and for
 that we'll need to be able to declare a build dependency on a developers'
 install of `port:MacPorts-libcurl`.

 This overhead can be prevented if we synchronise `port:MacPorts-libcurl`
 with `port:curl` (`port:MacPorts-pextlib` would `depends_build port:curl`
 and `depends_lib port:MacPorts-libcurl`) but that will mean testing if
 `port:MacPorts-pextlib` needs a revbump every time a curl update is
 pushed.

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


More information about the macports-tickets mailing list