[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260923144830.GX23438@brightrain.aerifal.cx>
Date: Wed, 23 Sep 2026 10:48:30 -0400
From: Rich Felker <dalias@...c.org>
To: Pablo Correa Gomez <pabloyoyoista@...tmarketos.org>
Cc: musl@...ts.openwall.com
Subject: Re: Default path search for locale - request for comments
On Wed, Sep 23, 2026 at 10:26:02AM -0400, Rich Felker wrote:
> On Wed, Sep 23, 2026 at 10:17:08AM -0400, Rich Felker wrote:
> > On Wed, Sep 23, 2026 at 04:04:01PM +0200, Pablo Correa Gomez wrote:
> > > 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.
> >
> > I don't understand what you think is not standards-compliant here. We
> > are talking about storing in /etc a configuration for where to look
> > for a particular resource. As I see it this is very much the same
> > thing as having the system-wide library search path stored in
> > /etc/ld-musl-$ARCH.path, having the DNS stored in /etc/resolv.conf,
> > and so on.
> >
> > Can you clarify what you think is nonconforming here? My best guess is
> > that you misunderstood it as actually storing installed locale files
> > there (which would very much be a bad thing, and non-conforming), but
> > if that's not the case I'd like to know so we can figure this out.
>
> I didn't see you'd replied to the other thread when I wrote this. I'll
> take a look and see if that answers my questions and follow up here.
>From the other thread:
On Wed, Sep 23, 2026 at 03:51:38PM +0200, Pablo Correa Gomez wrote:
> The two biggest standards that exist around filesystem hierarchies, the FHS[1]
> and the LFSH[2] define /etc as "Host-specific system configuration" and "System-
> specific configuration" respectively. IMHO, locales and collation rules are not
> system some host-specific or system configuration, but a core part of the C-
> library.
I don't think "part of the C library" is how I would think of them.
The locales shipped with the musl-locales project are intended to be
official, but the locale system as defined in POSIX facilitates use of
both official locales shipped with the implementation and locales that
are defined locally by the administrator/user of the system. And this
makes sense. The contents of the locales don't represent a tightly
specified interface between layers of the machine, but an interface
between the machine and human cultural norms that humans can
legitimately disagree over, or where human users can have needs that
aren't met by the official files.
In this context, I see it very much as a system configuration
question. Just like you might edit /etc/ld-musl-$ARCH.path to reflect
that you want some of your self-built libraries to be found before
package-installed ones, you might want to change the locale search
path to find whatever customizations you've made, without stepping on
the package manager's toes.
I'm aware that on pmOS and Alpine, the expectation will probably be
that most users just leave the default alone and use the shipped
locales, and they will go in a FHS-compliant place. That is very good.
But of course musl is not just for Alpine and pmOS users. musl does
not require a FHS-compliant filesystem layout at all. We only require
a very small, documented set of pathnames, most of which are in /dev,
/etc, and sometimes /proc. Some users are running their own distros
with their own unconventional layouts, and aside from situations where
there was a strong historical precedent not just for "this type of
file goes in this location" but for "this exact pathname contains this
exact data in a format everyone agrees on", we've always avoided
imposing "your filesystem needs to look like this" rules on users.
> So potential alternatives that I believe would fit:
>
> * /usr/share/musl, which would be compliant with both the FHS and LFSH, as
> architecture-independent package or system data
> * Directly under /lib or /lib/musl. Although less compliant with the standards,
> this would avoid the /usr prefix, and would place the localization data right
> next to the library. This is not an uncommon pattern, and something similar to
> what apk-tools does for its database
>
> If sysadmins wish to modify the locales, we could either keep honoring a
> environment variable, or give /etc/musl precedence for searching locales than
> the other path. I personally got no opinion on what is best here.
I'm not strongly opposed to having a default path something like
/etc/musl/locale:/usr/share/musl/locale, if discussing this doesn't
convince you otherwise or if others have good reason it should be this
way.
But I would like to better understand the need if this is what it's
going to be.
This will be the first time we have invented a pathname of our own for
data in our own format, rather than adopting something that's already
widely used and contains data/configuration in an existing well-known
format.
Rich
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.
