bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Please do not install a charset.alias file under Mac OS X


From: Bruno Haible
Subject: Re: Please do not install a charset.alias file under Mac OS X
Date: Sun, 18 Jan 2009 21:41:37 +0100
User-agent: KMail/1.9.9

Hello Vincent,

You brought up two different issues:
1) The fact that config.charset for MacOS X recognizes only UTF-8 locales.
2) The conflicts when packaging software sees a charset.alias file that
   belongs to different packages.

Ad 1)
Vincent Lefevre wrote:
> > You are better off filing this report against gettext, which is the
> > source of this file, and/or gnulib, which ships the latest version
> > of this file even in packages (such as m4) that have not yet
> > undergone the I18n conversion to use gettext.
> 
> I've just reported a bug against gettext:
> 
>   https://savannah.gnu.org/bugs/index.php?25235

See my response there. In summary, locales with an encoding other than
UTF-8 are not supported by MacOS X because filenames MUST be in UTF-8 on
this platform.

The generated charset is user-editable, though. (That's the very reason
why charset.alias is a separate file.) You can edit it as you like.

Ad 2)
> > The installation process is supposed to modify, not overwrite, the
> > charset.alias file to append the names of additional packages that are
> > using it.
> ...
> With a file that is shared by various software, this system leads
> to conflicts (a file in standard directories can belong to only one
> port). I wonder if there's a standard way to declare a file like
> charset.alias as shared by various software.
> 
> I've seen that a charset.alias file is not installed by utilities
> like m4 under GNU/Linux, so that the above problem cannot appear
> on this system. If the correction of the gettext bug makes the
> charset.alias file also disappear under Mac OS X, then everything
> will be fine.

I hardcoded the contents of charset.alias for glibc systems, so as to
avoid such conflicts for RPM and Debian packaging tools. Shall I do
the same for MacOS X? It will resolve the problem with the conflict,
but users will then not be able to customize the file.

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]