Re: GNOME 3.6 Blocker Report (T-16d)

[Jürg Billeter <j bitron ch>]

On Tue, 2012-09-11 at 09:40 +0100, Martyn Russell wrote:
> On 11/09/12 08:38, Mikkel Kamstrup Erlandsen wrote:
> > As for performance issues with libicu that has never been a problem
> > for our use cases. There might be faster alternatives, but the speed
> > is a non-issue for the stuff that I've been doing, and the features
> > gained vastly outweighs the perf loss.
> 
> The options here really are:
> 
> - Re-work Jürg's initial fix in order to handle these new cases with
>    libunistring. Maybe providing a custom collation method which would
>    treat 0x10fffd always as the last char and calling libunistring's
>    collator internally.

As strcoll() doesn't appear to conform to the Unicode collation rules, I
don't see how we could properly fix this in Tracker.

> - Default to libicu instead of libunistring. However, there have been
>    bugs reported with use of libicu which are mentioned in the bug
>    report above. So we could just be replacing one problem with another.

I'd be in favor of this for the time being. Alexandre Rostovtsev
attached a patch to the ICU bug you mentioned and it's in master for a
couple months now.

> - We fix strcoll() which we believe is what libunistring is using. This
>    is discussed by the libunistring community:
> 
>    http://lists.gnu.org/archive/html/bug-libunistring/2010-11/msg00008.html

I would certainly like strcoll() fixed at some point, however, I'm not
familiar with the code or reasons for the current behavior, and I don't
have time to look into this myself.

In any case, this will likely take a lot more time to get fixed (if
ever) and pushed to distributions given that strcoll() is in glibc and
there may be backward compatibility concerns or the violation of the
Unicode standard may even have been deliberate.

Writing a new Unicode collator for libunistring seems more likely,
however, I'm not following the development of libunistring at all.

Regards,
Jürg