[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260923141708.GV23438@brightrain.aerifal.cx>
Date: Wed, 23 Sep 2026 10:17:08 -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: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.
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.
