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
