Date: Sun, 17 Nov 2013 11:42:23 +0900 From: Tomoaki AOKI <junchoon@dec.sakura.ne.jp> To: freebsd-stable@freebsd.org Subject: Please revert r258230 in stable/10 Message-ID: <20131117114223.9af2adf49a93b5dd7f77f472@dec.sakura.ne.jp>
next in thread | raw e-mail | index | archive | help
As some port requires libiconv.so.3 and currently converters/libiconv refuses to install if base iconv exists, WITH_LIBICONV_COMPAT option and related codes are still mandatory (preferrebly, default for 10.x). Please revert r258230 until any workaround is provided. If a PR is needed to revert, I'll do it. At least, japanese/mozc-tools (I and maybe many Japanese desktop users strongly need japanese/mozc-* ports, and it unconditionally requires libiconv.so.3) didn't build in head after r257583, which is MFC'ed this time. I think more and more ports would be affected. At that time, it was only in head, and no MFC date is targetted, so I didn't mention as I thought we users would have 2+ years to wait for base and ports to be finished by developers, or same time for discussion of proceeding or restoring WITH_LIBICONV_COMPAT knob. IMHO, as converters/libiconv refuses to be installed if /usr/include/iconv.h exists, namespace spoofing to ports libiconv stated in original commit message can't occur in fresh installation, isn't it? This case, using same namespace and individual names would be mandatory to fake port libiconv consumers (if not, meaning incompatible). No harm can exist this case. Am I missing something? As stable/10 and upcoming 10-RELEASE are the first version that base iconv libraries are default, and converters/libiconv does not want coexisting (at least, using current and plain ports tree to build) with base iconv, special care is needed for now. Possible workarounds I can imagine currently are: *Of course, reverting r258230 for 10.x lifetime for transition. *Merge now-removed base Citrus libiconv codes into converters/libiconv and conditionally build real gnu libiconv or Citrus based libiconv by checking existence of /usr/include/iconv.h. But I can't imagine actual how-to. I guess the latter can cause license management issue, but creating a new port for this shouldn't be an option to avoid dependency hell. Or can it be handled using some USES code? I'm not enough familiar to ports framework. -- Tomoaki AOKI junchoon@dec.sakura.ne.jp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131117114223.9af2adf49a93b5dd7f77f472>