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

[MacPorts]

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

Comment (by ryandesign):

 Replying to [comment:14 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?

 It's similar, but different because all of the ports that build themselves
 differently because of the x11/quartz distinction are supposed to have x11
 and quartz variants so that the user can indicate which one they want. If
 we were to implement your suggested no-name-mangling variant of the
 libiconv port, we would have to add such a variant to every port that uses
 libiconv. I don't want to do that. There's also no mechanism in MacPorts
 to ensure that the variants of all ports match. Nothing would prevent a
 user from installing libiconv with that variant and then installing [a
 port that uses libiconv] without that variant, and that would make things
 break, and I don't want to provide technical support for that.

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

 You give users too much credit. If there is a way for a user to mess up
 their MacPorts installation, some user will find it, and will then write
 to us asking why it's broken. We need to reduce the number of ways for the
 user to cause problems, not add new ones.

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

 I personally use shellcheck, and have previously used pandoc. Both are in
 MacPorts and require Haskell. I don't care what language a software
 package I want to use is written in; I just want to install and use it. I
 don't want to have to know what cabal and/or stack are or how to use them.
 That's why we put things in MacPorts: so that a user only has to learn one
 way of installing the software they need.

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