[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <c33df760ad676cd1e95bf1165803e8313e725b7d.camel@postmarketos.org>
Date: Thu, 24 Sep 2026 09:44:33 +0200
From: Pablo Correa Gomez <pabloyoyoista@...tmarketos.org>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: Default path search for locale - request for comments
El Wed, 23-09-2026 a las 13:16 -0400, Rich Felker escribió:
> 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.
Fair!
>
> 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.
>
I would lean on what's easiest to implement. In option 1, would it be possible
to supress a default locale by having some kind of empty value as part of the
user-selected search path? If so, then there's a solution for the drawback, and
you can just implement the easiest solution.
>
>
> 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.
