From owner-svn-ports-head@FreeBSD.ORG Thu Jan 30 21:53:56 2014 Return-Path: Delivered-To: svn-ports-head@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 26CA7D0E; Thu, 30 Jan 2014 21:53:56 +0000 (UTC) Received: from mailrelay007.isp.belgacom.be (mailrelay007.isp.belgacom.be [195.238.6.173]) by mx1.freebsd.org (Postfix) with ESMTP id 404A819F1; Thu, 30 Jan 2014 21:53:54 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlYGAAbJ6lJR8apO/2dsb2JhbABZgwyBA7orgwiBDBd0giUBAQEEOhweBRALDgoJJQ8qHgaIHAHMbBePAgeEOASYJ5Iggy47 Received: from 78.170-241-81.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([81.241.170.78]) by relay.skynet.be with ESMTP; 30 Jan 2014 22:53:52 +0100 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.7/8.14.7) with ESMTP id s0ULrphY086017; Thu, 30 Jan 2014 22:53:51 +0100 (CET) (envelope-from tijl@FreeBSD.org) Date: Thu, 30 Jan 2014 22:53:50 +0100 From: Tijl Coosemans To: Andrey Chernov Subject: Re: svn commit: r341775 - in head: Mk/Uses converters/libiconv devel/gettext Message-ID: <20140130225350.5260dc47@kalimero.tijl.coosemans.org> In-Reply-To: <52EA862C.30201@freebsd.org> References: <201401292024.s0TKOomF031237@svn.freebsd.org> <52E97640.5020703@freebsd.org> <52EA297E.6030607@kovesdan.org> <20140130132652.5d945d44@kalimero.tijl.coosemans.org> <52EA862C.30201@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?G=E1bor_K=F6vesd=E1n?= , svn-ports-head@freebsd.org, svn-ports-all@freebsd.org, ports-committers@freebsd.org X-BeenThere: svn-ports-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the ports tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 21:53:56 -0000 On Thu, 30 Jan 2014 21:04:44 +0400 Andrey Chernov wrote: > On 30.01.2014 16:26, Tijl Coosemans wrote: >>>> At this stage looks more logical to implement them in the system >>>> iconv, rather than to return gnu one back. >> >> That's not an option for users on 10.0 release. > > Well, exact steps for 10-release: > 1) Fully restore GNU iconv for ports, not partial restore as now. There > is no sense to wait for user reports that something is broken when the > possible bug source is clearly identified. Users not always able to > track it down. > 2) Implement GNU compatible //TRANSLIT, //IGNORE and WCHAR_T in system > iconv. > 3) Delete GNU one again in the future 10.x release. > > Even in case 2) and 3) will never happens, step 1) is required. Well, if others also think this is necessary I won't object. Libiconv is a small dependency after all. But at the moment I don't think it's necessary. System iconv works in the large majority of cases now and any remaining bugs will only be discovered if we continue to use it by default. About //TRANSLIT, //IGNORE and WCHAR_T, as far as I can tell they aren't that common so I think tagging ports with :translit or :wchar_t is simple and manageable. For WCHAR_T system iconv returns an error so applications fail in obvious ways and I expect we'll find these cases rather quickly. This problem turned up shortly after the switch to system iconv by the way and in all these months only 3 ports have been found to use it. At this rate it seems overkill to switch all ports back to libiconv. //IGNORE I've never encountered yet and I don't know why anyone would want to use it. And lack of //TRANSLIT isn't as bad as I initially thought it was because system iconv does transliteration by default. It's just that the output is not as good as with libiconv. The examples so far only involve ASCII and ISO-8859-1. I do seem to get good transliteration with ISO-8859-15. :translit has been added to converters/php*-iconv now and it's probably a good idea to add it to similar ports like py-iconv and ruby-iconv but that's still a low number of ports so again, I don't see the need to switch everything back to libiconv (just yet).