On Fri, 07 Jun 2024 at 23:22:46 +0900, Simon Richter wrote:
> On 6/7/24 22:40, Alexandre Detiste wrote:
> > Maybe a compromise would be to at least mandate some UTF-8 locale.
>
> Having an UTF-8 locale available would be a good thing, but allowing
> packages to rely on the active locale to be UTF-8 based reduces our testing
> scope.
I'm not sure I follow. Are you suggesting that we should build each
package *n* times (in a UTF-8 locale, in a legacy locale, in locales
known to have unique quirks like Turkish and Japanese, ...), just for
its side-effect of *potentially* passing through those locales to the
upstream test suite?
If we want to run the test suite in each of those locales, then I think
instead we should do just that: run the test suite (and only the test
suite!) in each of those locales. dh_auto_test could grow a way to do
that, if there's demand. Repeating the whole compilation seems like a
sufficiently large waste of time and resources that, in practice, we
are not going to be able to do this routinely for more than a couple
of locales.
Or, better, we should provide packages with a way to guarantee that
certain locales are available[1], and then tests that are known to be
testing locale-sensitive things should explicitly switch into the locales
of interest, to make sure that they are tested every time, not just if
the builder's locale happens to be the interesting one. For example,
glib2.0's test suite temporarily switches to a Japanese locale in order to
test its handling of formatting dates with an era (Japanese is one of the
few locales where that concept exists), and it does this even when built
by a non-Japanese-speaking developer like me. If it relied on the current
locale for its test coverage, then we would never have discovered #1060735
unless it was coincidentally built by a Japanese developer who is using
a big-endian machine, which seems quite unlikely to happen by chance!
Or, when you say "testing", do you really mean "doing the build, for
the side-effect of seeing whether it succeeds or fails"? (That's not
really the same thing as running a test suite.)
Realistically, several important tools require a UTF-8 locale and will
not work reliably otherwise. Meson either is one of these, or was in
the past, as a result of Python's Unicode behaviour; so debhelper sets
LC_ALL=C.UTF-8 when it invokes Meson, ignoring any preference that might
have been expressed by the caller of dpkg-buildpackage.
[1] Build-Depends: locales-all does this, but is rather heavy.
debian/tests/run-with-locales in e.g. src:glib2.0 is another
implementation, but a more centralized version of this would probably
be better.
> Basically, we need to define the severity of locale bugs
More than that, we need to define what is a locale bug and what is a
non-bug - ideally based on what is genuinely useful, rather than on
"this is something that could theoretically work". We should try to
solve bugs, because that benefits our users and Free Software, but we
should put zero effort into solving non-bugs.
What we say is a bug, and what we say is not a bug, is a policy decision
about our scope: we support some things and we do not support others.
There's nothing magical or set-in-stone about the set of things that we
do and don't support, and it can be varied if there is something close to
consensus that it ought to be. When we're deciding what is in-scope and
what is out-of-scope, we should make that decision based on comparing the
costs and benefits of a wider/narrower scope: "this is in-scope because
I say so" or "this is in-scope because we have traditionally said it is"
are considerably weaker arguments than "this is in-scope because otherwise
we can't access this benefit".
As an analogy: we have chosen to define in Policy that /bin/sh is anything
that supports the POSIX shell language, plus a few designated extensions
like `echo -n`. A consequence of that is that "foobar fails to build when
/bin/sh is bash" is considered to be a bug (which, in an ideal world,
we would solve), because bash is a POSIX shell; but "foobar fails to
build when /bin/sh is csh" is a non-bug (which we wouldn't even leave
open as wontfix, we would just close it), because csh isn't a POSIX shell.
In a different parallel universe, we might reasonably have declared
that /bin/sh is required to be bash (like it is in e.g. Fedora), which
would result in some things that are currently bugs becoming non-bugs -
that's a narrower scope than then one that Debian-in-this-universe has,
resulting in it being easier to maintain but less flexible.
Or, conversely, in a different parallel universe, we might have said that
/bin/sh can be literally any POSIX shell, which is a wider scope than
Debian-in-this-universe: "FTBFS when /bin/sh doesn't support echo -n"
is currently a non-bug, but in that hypothetical distribution it would
be a bug, making the distribution harder to maintain but more flexible.
I am, personally, a fan of setting a scope that makes some of our more
obscure or theoretical bugs into non-bugs, because that would let us
concentrate our attention on the remaining bugs (the ones that are more
likely to indicate a genuine problem for our users).
What Giole proposed at the beginning of this thread can be rephrased as
declaring that "FTBFS when locale is not C.UTF-8" and "non-reproducible
when locale is varied" are non-bugs, and therefore they are not only
wontfix, but they should be closed altogether as being out-of-scope.
Of course, if we chose to have this be our policy, then it would be best
if dpkg-buildpackage and/or debhelper would force the C.UTF-8 locale, so
that builds with different locales simply can't happen - instead of
allowing the build to continue, but considering it to be not-a-bug for
it to fail or give different results. Fortunately, forcing a C.UTF-8
locale is very easy (set some environment variables before forking each
subprocess).
Or, Alexandre's "weaker" suggestion, to which you are replying, could
be rephrased as declaring that things like "FTBFS when locale is not
UTF-8" and "non-reproducible when one of the two builds is non-UTF-8" are
non-bugs, but "FTBFS when locale is ja_JP.UTF-8" and "non-reproducible
when the two builds are different UTF-8 locales" would still be bugs
under Alexandre's suggestion. Similarly, if we chose to have *this* be
our policy, then it would be best if dpkg-buildpackage and/or debhelper
would either detect a non-UTF-8 locale and error out early, or detect a
non-UTF-8 locale and quietly replace it with some UTF-8 locale (perhaps
C.UTF-8, or perhaps the closest equivalent UTF-8 locale, like replacing
ja_JP.EUC-JP with ja_JP.UTF-8).
I can remember several conversations in the past about potentially
dropping support for legacy non-UTF-8 locales like en_GB.ISO-8859-15
*completely* (not just de-supporting them for package builds, but
de-supporting their use on Debian under any circumstances), and
Alexandre's suggestion is a subset of that: leaving them available for
users who might still need them for whatever reason, but declaring that
they are not something we support at package-build time.
> Besides locales, there are other things that might affect outcomes, and we
> need to find some reasonable position between "packages should be
> reproducible even if built from the maintainer's user account on their
> personal machine" and "anything that is not a sterile systemd-nspawn
> container with exactly the requested Build-Depends and no Recommended
> packages causes undefined behaviour."
Yes. I think there is room for a more nuanced approach to this general
design principle: we can define some sources of variation as "possible
but not recommended", set them to a known value for official buildds,
make it as easy as possible to set them to a known value for local
test-builds, and consider FTBFS or non-reproducibility under those
variations to be a *low-severity* bug.
For instance, if a package is non-reproducible depending on whether I
happen to have libreally-obscure-dev installed, of course ideally that
should be fixed, but I would say that it's a much lower severity than
the package being non-reproducible depending on whether I have a
more commonly-required package like libglib2.0-dev which might be
difficult to remove non-disruptively.
Similarly, if a package FTBFS when built on a Tuesday, I'd say that's RC;
if it FTBFS when my locale is en_GB.UTF-8, under our current policies I'd
personally say that's annoying but non-RC (because if I'm debugging
the package, I could always grumble and work around that issue by
LC_ALL=C.UTF-8); and if it FTBFS when built on a machine where the
/nonexistent directory does, in fact, exist, then I would say that's
a non-bug.
(A concrete example of the latter: I'm pretty sure glib2.0 will fail
its test suite if /nonexistent exists, but if someone reported that as
a bug, I would be inclined to reply "/nonexistent shouldn't exist, the
clue's in the name" and close it.)
For locales and other facets of the execution environment that are
similarly easy to clear/reset/sanitize/normalize, we don't necessarily
need to be saying "if you do a build in this situation, you are doing
it wrong", because we could equally well be saying "if you do a build in
this situation, the build toolchain will automatically fix it for you" -
much more friendly towards anyone who is building packages interactively,
which seems to be the use-case that you're primarily interested in.
> Personally my preference would be as close as possible to
> [not needing a special build environment],
> because if I ever need to work on someone else's package, the chance is high
> that I will need incremental builds and a graphical debugger, and both of
> these are a major hassle in containers.
I don't think this is an either/or, but more like a spectrum: the more
your build environment diverges from what we might consider to be our
reference build environment, the more likely it is that a package will
FTBFS, fail tests, be non-reproducible or otherwise misbehave. It's
up to us, as a project, where to draw the line for "this divergence is
completely normal so the bug is RC" and, conversely, "this divergence
is so strange that it's a non-bug".
For something like the locale, it's very easy: if we decide that certain
locales are out-of-scope, then the build toolchain (dpkg-buildpackage or
similar) could just not allow the out-of-scope situations, because it's
straightforward (and doesn't require privileges) to force the build into
an in-scope situation and continue from there.
smcv
