[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6c4bd5d41b80fee24d64f67765f860dfe605fad4.camel@postmarketos.org>
Date: Wed, 23 Sep 2026 16:04:01 +0200
From: Pablo Correa Gomez <pabloyoyoista@...tmarketos.org>
To: Rich Felker <dalias@...c.org>, musl@...ts.openwall.com
Subject: Re: Default path search for locale - request for comments
Hi Rich,
It seems we just talked over each other in 2 different threads
El Wed, 23-09-2026 a las 09:40 -0400, Rich Felker escribió:
> One goal for the outcome of the locale overhaul making locales
> actually usable was to get rid of the requirement of having the
> MUSL_LOCPATH environment variable set to enable loading, which does
> not work with suid binaries and precluded any support for running them
> in anything but C/C.UTF-8 locale. It was also an impediment even to
> non-suid use, since users in an environment-scrubbed setting might
> find LC_* variables suddenly not working for them.
>
> So, we need to pick a default search path.
>
> Overriding the path will still be an option but limited to the
> libc.secure==0 case (i.e. unavailable to suid binaries) as it is now.
> We may pick a different name for the override variable just to avoid
> clashing with names anyone using the old locale framework with old
> binaries might be using.
>
> I know this is very much a bikeshed topic, so I am laying out some
> contraints below for properties a default path needs to satisfy and
> going over some things that have already been proposed on IRC and
> other channels, grouped by whether they are rejected (with reasons) or
> under consideration. Please read and be aware of these if you want to
> participate in the discussion.
>
>
>
>
> Design constraints for a default path:
>
> - It should not be dependent on configure-time --prefix. Having it
> depend on prefix would make it so static binaries built from a
> toolchain installed in a nonstandard prefix, or on a distro that
> uses an unusual prefix, fail to find locales when run on a standard
> musl-based system.
>
> - It cannot search locations that are expected to be writable by
> (non-root) users.
>
> - It should avoid imposing new rules on filesystem layout beyond
> assumptions we already make on absolute paths.
>
> - It should be configurable by the administrator without the need to
> modify a filesystem that's allowed to be read-only.
>
>
> Based on these constaints, the proposal I've made on IRC is that the
> default path be something under /etc. This is *not* a place you are
> expected to store the actual installed locale files (doing so would
> violate FHS); rather, the expectation is that it would be a symlink
> allowing administrators and integrators to configure where they have
> locales installed to avoid hard-coding any expectation of where the
> distro puts things and to allow an administrator to opt out of using
> the distro-provided files and instead use their own build (where they
> may have different opinions about what cultural conventions their
> locales should reflect).
>
I really dislike the idea to hard-code something that is not standards-
compliant, as anybody following a standard would have to violate it (place a
system-symlink under /etc) just to make it compliant.
Maybe an alternative if /usr/share cannot be used can be something under /lib or
/lib/musl or any other path you want under /lib? Although not fully-compliant
with the standards, it's a lot less broken than using /etc, would avoid $prefix
or /usr, and would place the localization data right next to the library. This
is not a fully unknown pattern, and something similar to what apk-tools does for
its database since apkv3
>
>
>
> Some particular rejected ideas:
>
> /usr/share/locale - This path already belongs to gettext localization
> for applications, and contains ll[_TT]/LC_MESSAGES/$textdomain.mo
> files.
>
> /usr/lib/locale - This is what glibc uses and is probably not
> FHS-compliant but is grandfathered in.
>
> /var/... - The entire /var tree is for runtime-modifiable data/state,
> not configuration (which this is) or read-only tables (which the
> configuation points to).
>
> /locale/... - Not FHS-compliant, seriously overstepping bounds.
>
> $prefix/... - See above.
>
> /usr/share/... (as the only search path) - This does not meet the need
> to be configurable, as it's a path managed by the package manager and
> expected to be read-only.
>
> /etc/locale* - Clashes with too many random/bogus things.
>
>
>
>
> Some non-rejected ideas that have been proposed:
>
> /etc/musl/locale -> [location] - Clearly belongs to musl, unambiguous.
> My only hesitation is that it suggests that it invites inventing other
> things to put in /etc/musl, which we probably should not be doing.
>
> /etc/muslocale -> [location] - Probably not a serious name, but the
> general pattern of "name at the top level of /etc that's chosen to be
> clearly non-clashing" is reasonable.
>
>
>
>
> Borderline ideas:
>
> /usr/share/..., (either as part of a multi-path search, or to use if a
> configured location (via symlink) in /etc doesn't exist) - I'm
> hesitant to do this because as a policy we generally don't invent new
> things that depend on a particlar layout of /usr or other parts of the
> filesystem. The only uses of /usr we have now are for things with
> strong historical precedent for files that are not libc-impl-dependent
> but used by all libcs, like /usr/share/zoneinfo and the default execvp
> search path if $PATH is unset. (Note: default dynamic linker path also
> includes /usr/[local/]lib, but this is not something that is baked
> into static binaries, only the installed ldso.)
/usr/share exists since version 2.3 of the FHS published around 2004 if I am not
mistaken, so the existance of this folder is something that does have a strong
historical precedent.
>
> /etc/musl/locale (or similar) as a "symlink containing data" (like
> openbsd malloc uses) where the symlink contents would be a full
> :-separated search path - This is nice in that it lets you configure a
> full default search path rather than just a link to one directory, but
> it requires more machinery in the locale loading code to read it in.
>
> /etc/musl/locale.conf (or similar) as a file containing a search path
> in the file body - This is "more conventional" than the "symlink
> containing data" approach, but adds considerable syscall overhead at
> startup compared to the symlink or symlink-containing-data approach.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
