[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20260923171633.GA23438@brightrain.aerifal.cx>
Date: Wed, 23 Sep 2026 13:16:34 -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 11:32:59AM -0400, Rich Felker wrote:
> On Wed, Sep 23, 2026 at 05:21:29PM +0200, Pablo Correa Gomez wrote:
> > > > If I understood the proposal correctly, it means that from our perspective
> > > > as
> > > > postmarketOS, as we want localization by default, we would have to package a
> > > > symlink in /etc pointing whereever else the locale files are placed. It's
> > > > widely
> > > > understood that this is a violation of the FHS, as the fact that we package
> > > > it
> > > > in every installation is by definition not "Host-specific system
> > > > configuration",
> > > > which is how the FHS (and LFSH in similar terms) specify /etc.
> > >
> > > OK, so it's the need for a package to drop the symlink there that's a
> > > problem. That makes sense.
> > >
> > > There are a bunch of things dropped there already, but I guess you're
> > > trying to reduce that and treating it either as grandfathered stuff
> > > with strong historical precedent (like /etc/services) or FHS bugs
> > > (like /etc/locales.conf, owned by the freetds package - eeew such bad
> > > naming).
> > >
> > > That seems reasonable and like a good motivation for having a default
> > > compatible with FHS in the absence of configuration, as you want.
> > > Thanks for clarifying.
> >
> > Yes, exactly. History it's what it is, and we can't change that. But it'd be
> > very helpful to not introduce more problematic paths in new code.
>
> OK.
>
> > > > The other paths that you mention:
> > > >
> > > > /etc/ld-musl-$ARCH.path does not exist in my system, so by means of a
> > > > default
> > > > being defined somehow else, it's compliant. If we were doing to do something
> > > > like that, where a default path is defined in code or at build-time, or
> > > > however
> > > > that is defined by default in musl, and /etc/musllocale or similar serves as
> > > > an
> > > > override, that I would be happy with.
> > >
> > > Yeah, there is a default that's probably reasonable for FHS-compliant
> > > systems. But as noted before, this doesn't get baked into static
> > > binaries; it's only the dynamic linker, and it actually finds it
> > > relative to itself, not in absolute /etc but ../etc/
> > >
> > > It's certainly possible that systems using unconventional fs layout
> > > could modify their ldso for this, but I think the recommended approach
> > > would still be for them to ship a .path file.
> >
> > Importing from the other thread:
> >
> > > 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.
> >
> > A default path like "/etc/musl/locale:/usr/share/musl/locale" would be very
> > helpful for our use-case. If there is some other hard-coded way to select the
> > /usr/share path which you find more fitting, like relative to the main binary
> > (generally) under /lib as apk does, that would also fullfill our needs.
>
> I think relative to main binary, aside from being hard to do, is
> probably not a good idea. The locale data is not expected to be
> something people would ship with static binaries, but part of the host
> environment where the user already has installed the locales they need
> for their language/cultural conventions. So it should be looking (in
> this order) in:
>
> - location the user has requested with an environment variable, unless
> it's running with elevated (suid/sgid/caps) privileges that make it
> impossible to trust this.
>
> - location configured by the administrator (who is probably the user
> anyway, but made the config from a privileged login) through
> /etc/musl/locale or whatever name is chosen
>
> - a default FHS-compliant location like /usr/share/musl/locale
>
> If we're going to do this last one, I would probably also put
> /share/musl/locale in the search path to be consistent with how we
> support that variant for timezones.
One orthogonal consideration here: should the above be a sequential
search, or overriding?
Option 1: The whole thing is a sequential search. First all components
of the environment variable are searched, then a default path string
of "/etc/musl/locale:/usr/share/musl/locale:/share/musl/locale" (or
similar) is searched.
Option 2: The environment variable provides an override for the path
search string, and if it's missing, a default path string like the
above is used. This way environment fully replaces default.
Option 3: Both environment and system-wide config replace default.
Environment is used if present. If not, /etc/musl/locale is searched
if it exists. Only if it doesn't exist is a system default searched.
Option 4: The configuration in /etc/musl is not a symlink to a single
dir, but a path string (loaded from a file or readlink). The
environment variable provides the path string if present. If it's
missing, the path string is loaded from /etc/musl. Only if both of
these operations fails is the default one used.
My leaning is probably option 1. It's the easiest to implement and
probably gives the most "right by default" behavior. But it's not as
powerful, e.g. if the user actually wants to suppress default path.
Option 2 lets you suppress from an env var. Options 3 and 4 both let
you suppress default from env var or from global config. But option 3
is a lot more of a pain to get back the default locales if you
suppress them globally; you need to make symlinks to them or
something.
Also, orthogonal to this, we need to determine what conditions allow
fallback during a search. I *think* this should be consistent across
timezone search and library loading search, but at present it's not.
For libraries, ENOENT, ENOTDIR, EACCES, and ENAMETOOLONG make a hit
into a non-hit and allow the search to continue. Everything else is a
hard failure (to prevent transient failures from causing the wrong
thing to get loaded).
Locales and timezones should probably follow the same logic. I think
this works with __map_file since it will preserve all open errors but
also adds mmap errors (which don't overlap with the special 4 above,
so they would halt the search, as desired).
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.
