Slight improvement to __get_locale?

Slight improvement to __get_locale?

[A. Wilcox]

[-- Attachment #1.1: Type: text/plain, Size: 1291 bytes --]

Hi muslers,

We have a proposal to make locales work a tiny bit better on musl.
Currently, there is no locale map file (which, there generally will
never be one, until the rest of the locale system is overhauled and made
more..public), and musl will simply let you setlocale(3) to anything.

Our proposal is that __get_locale could determine if any of the
following paths exist:

/usr/share/locale/$foo
/usr/share/locale/${foo/.//}

If one exists, the function succeeds.  Otherwise, it fails.  The builtin
locales would not be affected, so C.UTF-8 and POSIX would always be
available and working.

I seem to recall that a similar discussion was had here many years ago,
but I could not find it in my archives (and Openwall still has no search
functionality).  I would be willing to write the implementation, and we
would be testing it in a wide variety of environments across different
CPU architectures and software packages.

The only drawback we have determined would be that this may not be
compatible with slashpackage.  There may be others, but they were not
immediately evident.  If the musl community does not want this, we are
okay with that as well.

Best,
--arw

-- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Slight improvement to __get_locale?

[u-uy74]

On Mon, Mar 11, 2019 at 01:45:31PM -0500, A. Wilcox wrote:
> Hi muslers,
> 
> We have a proposal to make locales work a tiny bit better on musl.
> Currently, there is no locale map file (which, there generally will
> never be one, until the rest of the locale system is overhauled and made
> more..public), and musl will simply let you setlocale(3) to anything.
> 
> Our proposal is that __get_locale could determine if any of the
> following paths exist:
> 
> /usr/share/locale/$foo
> /usr/share/locale/${foo/.//}

It does not look like there has been any dependency on this path in musl. (?)

Any added hardcoded path makes me uncomfortable. If not otherwise, it adds
a place to check while setting up builds and configurations and creates
uncertainty if there is someone else who can influence the contents
there in the future runtime environment.

Rune

[piggybacking ot: Rich, my off-list letter did not make it past your filters]

Re: Slight improvement to __get_locale?

[Rich Felker]

On Mon, Mar 11, 2019 at 01:45:31PM -0500, A. Wilcox wrote:
> Hi muslers,
> 
> We have a proposal to make locales work a tiny bit better on musl.
> Currently, there is no locale map file (which, there generally will
> never be one, until the rest of the locale system is overhauled and made
> more..public), and musl will simply let you setlocale(3) to anything.
> 
> Our proposal is that __get_locale could determine if any of the
> following paths exist:
> 
> /usr/share/locale/$foo
> /usr/share/locale/${foo/.//}

I don't really like the hard-coded paths, and I think they have false
negatives that would be unfortunate. For example if your base system
in /usr doesn't have any NLS, but locally-installed apps in /usr/local
do, you'd want to see their translations. Even adding
/usr/local/share/locale wouldn't really help, since the package might
have its translation files somewhere else (like
/opt/pkgname/share/locale or something).

> If one exists, the function succeeds.  Otherwise, it fails.  The builtin
> locales would not be affected, so C.UTF-8 and POSIX would always be
> available and working.

I forget if the framework for __get_locale to be able to fail without
breaking UTF-8 is in place yet. I know I started on the work, but
didn't make the final changes that would activate it. This needs to be
checked before we introduce that. Note that the existing (prior to
your email) proposal to introduce it would just drop visibility of any
locale names where musl doesn't itself have a locale file. So in some
sense, even with drawbacks your proposal is "better" in some ways,
just less consistent.

> I seem to recall that a similar discussion was had here many years ago,
> but I could not find it in my archives (and Openwall still has no search
> functionality).  I would be willing to write the implementation, and we
> would be testing it in a wide variety of environments across different
> CPU architectures and software packages.
> 
> The only drawback we have determined would be that this may not be
> compatible with slashpackage.  There may be others, but they were not
> immediately evident.  If the musl community does not want this, we are
> okay with that as well.

I don't want to reject it outright, but I think we really need a "big
picture" plan for how we intend locale to work with musl. It might
make sense to have some sort of meetup (either physical or virtual) of
parties interested in the outcome with a goal of identifying what
everybody's requirements are for this functionality to be useful and
how to achieve them in ways that don't unnecessarily step on toes or
break things.

Rich