Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 30 Jan 2014 22:53:50 +0100
From:      Tijl Coosemans <tijl@FreeBSD.org>
To:        Andrey Chernov <ache@freebsd.org>
Cc:        =?ISO-8859-1?Q?G=E1bor_K=F6vesd=E1n?= <gabor@kovesdan.org>, svn-ports-head@freebsd.org, svn-ports-all@freebsd.org, ports-committers@freebsd.org
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>

next in thread | previous in thread | raw e-mail | index | archive | help
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).



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140130225350.5260dc47>