[FreeBSD port]: devel/glib20

[Andrew W. Nosenko]

On Thu, Feb 26, 2009 at 4:18 PM, Stanislav Sedov <stas at freebsd.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wed, 25 Feb 2009 16:50:15 -0500
> Joe Marcus Clarke <marcus at marcuscom.com> mentioned:
>
>> On Tue, 2009-02-24 at 02:10 +0300, Stanislav Sedov wrote:
>> > -----BEGIN PGP SIGNED MESSAGE-----
>> > Hash: SHA1
>> >
>> > Hi!
>> >
>> > glib20 has a known filename encoding problem with non-utf8
>> > locales, because it doesn't perform names conversion from
>> > internal UTF8 to current locale by default (it used to do
>> > that some time ago). The patch included changes glib20
>> > behaviour to always do the conversion (this will work
>> > for all non-UTF8 locales and will have no effect fot UTF8
>> > ones). This is effectively the same redhat & co does in
>> > their deistributions.
>> >
>> > Comments?
>>
>> I have no objection, but I don't typically run into problems with
>> non-UTF-8 locales.  I think it would be safer if you made this into an
>> OPTION, and added this as an extra patch if the OPTION is enabled.
>>
>
> Doesn't running gtk/glib (e.g. sylpheed, gimp) apps with non-UTF locale
> break filenames for you? From looking into the code it's always the case
> for non-UTF locales (well, if you running ISO8859-1 you shouldn't have
> problems too). On the other hand enabling LANG-based locale detection should
> not hurt prefromance much (I think the overhead of parsing LANG is neglible).
> Sure, we can OPTIONfy this, but I belive the options should be enabled by
> default in this case (otherwise, people will continue to step onto this
> bug). Major Linux distributions also have this option turned on by default
> to match the behavior of older version of glib where the locale detection
> code was always enabled.
>

Why you want to patch Glib for turn this behavior on by default
instead of just install file in the /usr/local/etc/profile.d ?

profile.d approrach is reversible (I can unset enviroment variable),
while patching Glib for remove patch ...  slightly ugly at least,
IMHO.

-- 
Andrew W. Nosenko <andrew.w.nosenko at gmail.com>