[MacPorts] #70621: port:gdbm +compat naggles (affecting the Python ports)

[MacPorts]

#70621: port:gdbm +compat naggles (affecting the Python ports)
--------------------+--------------------
 Reporter:  RJVB    |      Owner:  (none)
     Type:  defect  |     Status:  new
 Priority:  Normal  |  Milestone:
Component:  ports   |    Version:
 Keywords:          |       Port:  gdbm
--------------------+--------------------
 I just found out 2 nuisances with port:gdbm's +compat variant:

 1) the build process will pick up and link to the installed
 $prefix/lib/libgdbm.X.dylib ... which will of course disappear when you
 activate the new gdbm version. The `+compat` variant thus needs to be
 bootstrapped by first installing the `-compat` version, OR the user needs
 to be instructed to move `$prefix/lib/libgdbm_compat.dylib` aside during
 the configure+build steps.

 2) if you build any port:pythonXY version it will detect and link to
 libgdbm_compat.X.dylib, e.g.
 {{{
 > otool -L
 /opt/local/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11
 /lib-dynload/_dbm.cpython-311-darwin.so
 /opt/local/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11
 /lib-dynload/_dbm.cpython-311-darwin.so:
         /opt/local/lib/libgdbm_compat.4.dylib (compatibility version
 5.0.0, current version 5.0.0)
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
 version 1197.1.1)
 }}}
 It seems that the Python ports need to declare some kind of build conflict
 with `port:gdbm+compat` unless they want to start declaring a dependency
 on `port:gdbm` (*which they don't ATM*).

 (Actually I ran into `1)` on Linux, but there is no a priori reason why
 the same thing wouldn't happen on Mac.)

-- 
Ticket URL: <https://trac.macports.org/ticket/70621>
MacPorts <https://www.macports.org/>
Ports system for macOS