[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4062a3ab6fdd4235b73a5a5a0428c96eed71d7e8.camel@postmarketos.org>
Date: Wed, 23 Sep 2026 16:42:21 +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 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.
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.
/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.
>
> 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.
