[MacPorts] #57821: libiconv breaks compatibility with OS-provided

[MacPorts]

#57821: libiconv breaks compatibility with OS-provided
-------------------------+------------------------
  Reporter:  mouse07410  |      Owner:  ryandesign
      Type:  defect      |     Status:  closed
  Priority:  Normal      |  Milestone:
 Component:  ports       |    Version:
Resolution:  invalid     |   Keywords:
      Port:  libiconv    |
-------------------------+------------------------

Comment (by ryandesign):

 Replying to [comment:9 mouse07410]:
 > > I will not add that to the port, because it will cause problems—much
 like the ones you're experiencing now, just in different
 circumstances—which I do not wish to spend time helping users resolve
 >
 > I'm not sure I understand how it could cause problems, especially when
 the majority would use the default that does mangle the function names. I
 wish you'd reconsider adding a port variant.

 If we offered a variant that did not mangle the function names, all of the
 other ports that the user had installed that linked with libiconv would be
 broken, because they expect mangled function names. The user would have to
 uninstall and rebuild all of those ports from source so that they use
 unmangled names. If the user didn't do that, they would receive undefined
 symbol errors, much as you did. MacPorts doesn't contain any feature that
 would make it easy for the user to identify the ports that need to be
 rebuilt, so it would be a manual process. I would not want to be involved
 in assisting the user with that task.

 We have an automated build system that builds and distributes binaries of
 ports to users. Anything built by that system would use libiconv in its
 normal state—with mangled function names. Those binaries would be
 incompatible with a libiconv variant for using unmangled function names
 installed on a user system. The user would have to know this, and would
 have to instruct MacPorts not to use any binaries (i.e. to build from
 source instead). We could inform the user of that by using `notes` in the
 variant, but users often don't read notes, and there's no way to enforce
 that the user has disabled binaries if they use that hypothetical variant.
 For these reasons, we try to avoid adding variants that, when selected,
 cause other ports to build differently.

 Sometimes being a maintainer of a port means knowing when not to offer
 users the opportunity to shoot themselves in the foot, because some users
 inevitably take that opportunity and then either leave MacPorts because
 they perceive it to be broken, or else they ask us for tech support. Some
 of my goals are to reduce the likelihood that a user will need tech
 support or leave us.

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