[MacPorts] #63309: Dependency libidn could be replaced by libidn2

[MacPorts]

#63309: Dependency libidn could be replaced by libidn2
-------------------------------------------------+-------------------------
  Reporter:  ednl                                |      Owner:  (none)
      Type:  update                              |     Status:  new
  Priority:  Normal                              |  Milestone:
 Component:  ports                               |    Version:  2.7.1
Resolution:                                      |   Keywords:
      Port:  cpuminer echoping elinks-devel      |
  FileZilla finch ghostscript gloox html-xml-    |
  utils hydra Io jabber jabberd knot kopete      |
  libgsasl libpurple libVLC2 loudmouth lynx      |
  maildrop monotone monotone-devel mutt p5-net-  |
  libidn pidgin podofo prosody psi skipfish tin  |
  VLC2                                           |
-------------------------------------------------+-------------------------

Comment (by ryandesign):

 Replying to [comment:9 RJVB]:
 > Not intending to start a debate here, so long story short, the same
 could be said about the backport of OpenSSL 1.1 support to Qt4, or even
 the whole `port:legacy-support`. Or indeed to patching the code to use
 libidn2 instead of libidn ;)

 qt4 is presumably dead, its developers having moved on to qt5 and qt6. If
 the maintainer of the qt4 port chose to backport openssl 1.1 support to
 keep it working, that's great. An alternative to keeping it working might
 have been to use the openssl10 port. Keeping the qt4 port working is great
 for all those other old ports that use qt4 and cannot use qt5 or later.

 legacy-support gives us an easy way to enable a whole host of newer
 software to build on older OS versions that don't have certain features.
 The alternative is filing individual bug reports with each software
 developer, asking them to add compatibility functions, which often they
 are unwilling to do due to the age of the OS version in question.

 libidn2 on the other hand is actively-developed software. If they've
 consciously chosen not to implement a feature that was offered in the
 original libidn, I don't consider it our job to second-guess them about
 that. It looks like Homebrew embarked on a similar goal of migrating
 everything from libidn to libidn2 4 years ago and they asked the
 developers of libidn2 regarding the `stringprep` problem
 [https://gitlab.com/libidn/libidn2/-/issues/28 here]. There is some
 discussion there, including the proposal to split the `stringprep`
 functionality out of libidn into a new "libstringprep" library, but it
 seems to be thought that this is not useful, since the functionality
 already exists in libidn and can be used from there.

 So the verdict is libidn must remain for those old programs that use
 libidn's coincidental `stringprep` functions for things not related to IDN
 processing.

 Since libidn's IDN processing is based on the obsolete IDN2003 standard,
 and libidn2 exists to cover the newer IDN2008 standard, there is still
 value in us moving software that is capable of doing so to libidn2, and
 there is value in us reporting bugs to projects that don't yet have
 libidn2 support asking them to add it.

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