[MacPorts] #70767: python312 @3.12.6 cannot compile against libressl

[MacPorts]

#70767: python312 @3.12.6 cannot compile against libressl
------------------------+----------------------
  Reporter:  SaintBol   |      Owner:  jmroot
      Type:  defect     |     Status:  assigned
  Priority:  Normal     |  Milestone:
 Component:  ports      |    Version:  2.10.1
Resolution:             |   Keywords:
      Port:  python312  |
------------------------+----------------------

Comment (by artkiver):

 Replying to [comment:9 jmroot]:
 > As far as python312 is concerned, I guess the dependency just needs to
 be `port:openssl` if it doesn't work with libressl.

 I think, generally speaking, Portfiles would benefit from something such
 as:

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

 Referencing the dylib facilitates a port to be more TLS library agnostic.

 With regards to ldns, that was from a PR here:
 https://github.com/macports/macports-ports/pull/17568

 As suggested by the commit message, the "extra smarts" were inspired by
 modifications made to the rpki-client Portfile, from suggestions provided
 by @neverpanic (at the moment I am not even sure why it is not CCing
 Clemens Lang, did I forget how to use Trac? I swear there used to be a
 means to provide a drop down username select.)

 Lamentably, I have attempted, unsuccessfully, to try to apply similar
 "smarts" to the Got Portfile, but while I documented some of my failed
 attempts here: https://trac.macports.org/ticket/69827 I never came up with
 a satisfactory refactoring which functioned as intended.

 It's my personal observation, maybe something changed with how TLS is
 being handled by MacPorts, not just the Portfiles? It's plausible that
 rpki-client also does not function with those similar "smarts" as it did
 when it was originally tested and committed.

 Anyway, while a smarter approach might be beneficial, I never was able to
 make it generically consistent and maybe something changed since that ldns
 PR was merged (which most certainly was thoroughly tested locally, as was
 the rpki-client change prior to being merged).

 However, this kind of stuff would sincerely benefit from more attention
 than I can personally provide at present given my limited resources. I do
 not even have mpbb running locally despite multiple attempts at following
 those instructions, they haven't gelled.

 I would also posit that rather than defaulting to OpenSSL, defaulting to
 LibreSSL, given that macOS has used that as its reference TLS library for
 approximately a decade at this point, might be a wiser strategy? IIRC that
 may touch over 800 Portfiles though and is more than a one person job, to
 understate it.

 If MacPorts ever gets around to holding hackathons again, it's the sort of
 thing which could probably use its own. I know Bob Beck (one of the
 LibreSSL developers) personally and maybe could inspire him to visit too,
 but last I checked the last MacPorts in person gathering was before COVID
 and in Europe. I am in California, Bob Beck is in Canada and Clemens I
 think is in Germany?

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