[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260923145555.GY23438@brightrain.aerifal.cx>
Date: Wed, 23 Sep 2026 10:55:55 -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 04:42:21PM +0200, Pablo Correa Gomez wrote:
> El Wed, 23-09-2026 a las 10:17 -0400, Rich Felker escribió:
> > 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.
>
> 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.
> 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.
> /etc/resolvconf is one of those historical goodies, but also one that is not
> packaged by default. In our graphical installs, something like NetworkManager
> would usually manage it on the user behalf, but the network configuration is
> generally a lot more complex[1] and user-dependent. None of that complexity
> applies in our use-case. We just want 99.9% of users to use the same path for
> locales, and I would expect that we can package it in a way that is conforming
> to available standards.
>
>
> [1] Case study: we've been years in pmOS fighting with phones leaking mobile
> data while connected to WiFi in situations where WiFi is ipv4 and mobile data
> ipv6, and the resolver gives back an ipv6 as that resolved faster than ipv4. And
> it gets cursed pretty fast when you throw phones in the wild with whatever
> possible conbinations of configurations by their ISPs and mobile operators.
This is not the place to discuss it, but this probably suggests it
would be a good idea to take a more adversarial approach to network
autoconfiguration provided to non-technical end-user devices.
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.
