[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 mouse07410):

 > 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...


 I see your points. But is this really different from {{{+quartz -x11}}}
 vs. {{{+x11 -quartz}}} issue?


 > 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...

 My assumption is that if a user chooses a variant over the default - he
 knows why he does it, and realizes the consequences (especially those
 listed in the port description ;).

 > For these reasons, we try to avoid adding variants that, when selected,
 cause other ports to build differently...

 True, and agreed. But sometimes it is not possible to avoid such variants
 (see my example above). I'd agree that this is probably not such a case.

 > Sometimes being a maintainer of a port means knowing when not to offer
 users the opportunity to shoot themselves in the foot...

 I take your point.

 Essentially, the correct solution was to use a rebuilt GHC. A pity that
 Macports cannot provide a good GHC, but:

 > Please communicate with the MacPorts maintainer of ghc about this...

 That's what I'm doing, and after this post will continue the discussion
 there: #48899


 > > drop attempts to manage Haskell packages via Macports - cabal and
 stack will remain better at that job anyway. It is trying to do too much,
 which IMHO is why its maintainers find it so hard to keep current.
 >
 > If we did that, we would also have to remove all the ports that have
 dependencies on Haskell packages, and all the ports that depend on them,
 and so on

 And I'd call it a Good Riddance. Currently a huge number of 48 ports, of
 which about one third are semi-independent binaries (aka not something
 managed by cabal). In any case, users would be better off managing the
 majority of those directly via cabal and/or stack.

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