Context Navigation

Changes between Initial Version and Version 1 of Ticket #66857, comment 17

-                      initial
+                      v1
 > I don't feel that there is any reason why a standard library like libiconv, where we do indeed want all ports that use libiconv to use the MacPorts one, should be moved to a nonstandard location which would require extra effort in all of the ports that use it to continue to use it.
 The idea would be that no ports find a need to ever use it, and we just dump it in the end as a big pain we no longer need…
+The hope would be that no ports find a need to ever use it, and we just mostly stop using it.
 libiconv is an unusually troublesome PITA. If they at least made the incompatible libraries (system vs macports) have different names the wrong one wouldn’t keep getting linked in.
+libiconv is unusually troublesome because the incompatible libraries (system vs macports) have the same  names, so the wrong one is often linked in.
+But no, some joker upstream decided we’d all have to live with this silly mess forever.
+As before, when I listed all the urls I found complaining about the issue, I believe is is the single biggest complaint against macports.
+I realize bugfixes, etc, happen over time but libiconv seems quite static… I’d have to see if and where the system libiconv might truly be inferior to the current one.