[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