Re: Mandatory LC_ALL=C.UTF-8 during package building

[Adrian Bunk <bunk@debian.org>]

Sorry for being late to this discussion, but there are a few points 
and a suggestion I'd like to make:


1. Reproducibility is not a big concern

Quoting policy:

  Packages should build reproducibly, which for the purposes of this 
  document means that given
  ...
  - a set of environment variable values;
  ...
  repeatedly building the source package
  ...
  with ... exactly those environment variable values set 
  will produce bit-for-bit identical binary packages.

There is also the practical side that our buildds already set LC_ALL=C.UTF-8,
in main one can already assume that every package in a release has been 
built with in this environment.


2. RC is what does FTBFS on the buildds

Usually a FTBFS is RC only when it happens on the buildds.

FTBFS with non-C.UTF-8 locales itself is not RC,
just like FTBFS on single-core machines is not RC.

These are of course still bugs, especially if a different UTF-8 locale 
results in test failures that indicate runtime issues.


3. Importance of build-time diversity

Less than 3 years ago, having build-arch/build-indep targets in 
debian/rules was a usecase important enought for some people that a MBF 
with hundreds of RC bugs was done and many people (including myself) 
spent time fixing this usecase by adding build-arch/build-indep targets 
to packages.

Calling the clean target manually is something I frequently do.

Doing a build test or autopkgtest with an Estonian or Turkish locale 
is hard/impossible when something (no matter whether debian/rules or
debhelper or dpkg-buildpackage) enforces C.UTF-8.


4. C.UTF-8 or *some* UTF-8 locale?

The main problems are with non-UTF-8 locales, it might be 
uncontroversial to declare building with a non-UTF-8 locale 
unsupported and make dpkg-buildpackage reject this with a message like:

  Building with a non-UTF-8 locale is no longer supported, please do
    LC_ALL=C.UTF-8 dpkg-buildpackage

This should be sufficient to address the root cause of all/most of the 
current manual and tooling settings of C.UTF-8, and could actually 
enable useful testbuilds for finding problems for Turkish users.


cu
Adrian