From owner-freebsd-stable@FreeBSD.ORG Sun Nov 17 02:42:32 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3210E3FC for ; Sun, 17 Nov 2013 02:42:32 +0000 (UTC) Received: from dec.sakura.ne.jp (dec.sakura.ne.jp [210.188.226.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C6A5C224F for ; Sun, 17 Nov 2013 02:42:31 +0000 (UTC) Received: from fortune.joker.local (180-198-98-49.nagoya1.commufa.jp [180.198.98.49]) (authenticated bits=0) by dec.sakura.ne.jp (8.14.2/8.14.2/[SAKURA-WEB]/20080708) with ESMTP id rAH2gNWA070900 for ; Sun, 17 Nov 2013 11:42:24 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sun, 17 Nov 2013 11:42:23 +0900 From: Tomoaki AOKI To: freebsd-stable@freebsd.org Subject: Please revert r258230 in stable/10 Message-Id: <20131117114223.9af2adf49a93b5dd7f77f472@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.19; amd64-portbld-freebsd9.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2013 02:42:32 -0000 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