[MacPorts] #69490: libressl cannot be installed when it depends on a clang port because it conflicts with openssl

[MacPorts]

#69490: libressl cannot be installed when it depends on a clang port because it
conflicts with openssl
-------------------------+----------------------
  Reporter:  ryandesign  |      Owner:  artkiver
      Type:  defect      |     Status:  assigned
  Priority:  Normal      |  Milestone:
 Component:  ports       |    Version:
Resolution:              |   Keywords:
      Port:  libressl    |
-------------------------+----------------------

Comment (by artkiver):

 Respectfully, this doesn't track.

 I don't know where you got the impression that anyone insinuated that
 LibreSSL is a "drop in replacement" for OpenSSL. LibreSSL forked from
 OpenSSL, a decade ago (specifically, April 22nd, 2014) and has taken a
 different trajectory over the ensuing years, even if it was initially
 intended to be relatively compatible (which is a given, since it was a
 fork) the LibreSSL and OpenSSL codebases have, and continue to diverge.
 So, while maybe in 2014, it was relatively easy to substitute OpenSSL with
 LibreSSL, doing so now might be a bit more challenging?

 The good news is: many projects, like macOS, have long since done the
 heavy lifting of having migrated to LibreSSL.

 MacPorts, is a different beast though and I am guessing there are reasons
 jeremyhu left 54744 unaddressed for years before he went AWOL?

 Moreover, your suggestion here: https://github.com/macports/macports-
 ports/pull/23716#issuecomment-2078328088 suggesting that one can simply
 add

 {{{
 port:libretls
 }}}

 As a dependency, doesn't really function.

 e.g. if done to the Got Portfile, one will encounter this sort of error
 when attempting to install it:

 {{{
  got # port -v install
 --->  Computing dependencies for got...
 Error: Can't install openssl because conflicting ports are active:
 libressl
 Error: Follow https://guide.macports.org/#project.tickets if you believe
 there
 is a bug.
 Error: Processing of port got failed
 }}}

 If you examine the Portfile for devel/libretls you'll see:

 {{{
 depends_lib         port:openssl
 }}}

 Indeed, libtls is ''already'' supplied by libressl, as mentioned in the
 port description, from looking at e.g.
 https://ports.macports.org/port/libressl/

 You'll see (apologies for the strange formatting, italics added for
 emphasis):

 {{{
 LibreSSL SSL/TLS cryptography library

 LibreSSL is composed of four parts: The openssl(1) utility, which provides
 tools for managing keys, certificates, etc. libcrypto: a library of
 cryptography fundamentals libssl: a TLS library, backwards-compatible with
 OpenSSL
 }}}
 '' libtls: a new TLS library, designed to make it easier to write
 foolproof applications''
 {{{
 This port tracks the stable releases, for development releases please use
 libressl-devel.
 }}}

 In other words, the entire point of libretls /devel/libretls is to provide
 libtls functionality, to OpenSSL. LibreSSL, already has libtls as a given.

 But, for the sake of argument, I went ahead and modify the /devel/libretls
 Portfile manually to have

 {{{
 depends_lib         path:lib/libssl.dylib:openssl \
 }}}

 Instead of:

 {{{
 depends_lib         port:openssl
 }}}

 Attempting to install that locally, fails with the following:

 {{{
 Error: Failed to activate libretls: Image error: /opt/local/include/tls.h
 is being used by the active libressl port.  Please deactivate this port
 first, or use 'port -f activate libretls' to force the activation.
     while executing
 "throw registry::image-error $msg"
     ("foreach" body line 47)
     invoked from within
 "foreach file $imagefiles {
                 set srcfile "${extracted_dir}${file}"

                 # To be able to install links, we test if we can lst..."
     invoked from within
 "registry::write {
             foreach file $imagefiles {
                 set srcfile "${extracted_dir}${file}"

                 # To be able to instal..."
 Error: See
 /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_libretls/libretls/main.log
 for details.
 Error: Follow https://guide.macports.org/#project.tickets if you believe
 there
 is a bug.
 Error: Processing of port libretls failed
 }}}

 Candidly, it would probably save everyone some headaches if devel/libretls
 also had conflicts statements with libressl and libressl-devel.

 Having written as much, there's an OpenSSL PortGroup too, which some
 Portfiles reference instead of any of the previously mentioned
 methodologies for linking a particular TLS library. So, while I don't
 disagree that it's quite a bit of effort to migrate your estimate of 800
 some odd MacPorts to something that has better affinity with libressl,
 which seems possible in theory, that doesn't change the reality that most
 definitely, something changed within MacPorts and the GitHub Actions CI as
 well since some of these MacPorts (e.g. libressl, got) were last updated
 that is resulting in more breakage, whereas previously

 {{{
 depends_lib         path:lib/libssl.dylib:openssl \
 }}}

 Was seemingly sufficient to facilitate user choice in which TLS library
 was in use without throwing errors or causing undue breakage that is more
 recently observable.

 I could certainly benefit for more help, but retreading old suggestions
 and old tickets that predate any of the time with when I began to
 contribute to MacPorts doesn't seem particularly helpful; especially given
 that https://trac.macports.org/ticket/54744 makes reference to boringssl
 which near as I can discern, does not exist within MacPorts at all, and if
 it did previously, I have no idea when it was deprecated.

 Replying to [comment:4 ryandesign]:
 > Replying to [comment:3 artkiver]:
 > > I think I might be seeing this issue rear its ugly head here as well:
 > >
 > > https://github.com/macports/macports-ports/pull/23716
 >
 > I don't believe that's related. That's about libretls; this ticket is
 about libressl.
 >
 > > Albeit, I am sort of wondering if this Trac issue is assigned
 correctly, since I haven't touched any of the buildbot code
 >
 > It's assigned to the libressl maintainers because it occurs due to a
 design decision of the libressl port: pretending that it is a drop-in
 replacement for openssl. I'm not suggesting that you should modify
 buildbot or GitHub Actions or mpbb to work around this or set up a local
 environment for either of those; I'm suggesting that the design of the
 libressl port should be changed per #54744.

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