[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260923153259.GZ23438@brightrain.aerifal.cx>
Date: Wed, 23 Sep 2026 11:32:59 -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 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.
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.
