[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48c95717c8508497a74c9089e93d36610db55c3f.camel@postmarketos.org>
Date: Wed, 23 Sep 2026 17:21:29 +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:55 -0400, Rich Felker escribió:
> 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.
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.
>
> > 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.
As a side-track, in application code such way of working is standardized in the
UAPI.6 specification. Even if it applies less to libc, as a way of thinking to
solve this new problem in musl, that specification has generally served super
well to avoid the common problem of sysadmins modification and system policies
not colliding with each other and remaining standards-compliant.
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.
