On Sat, 08 Jun 2024 at 02:14:36 +0900, Simon Richter wrote:
> Reproducibility outside of sterile environments is however a problem for us
> as a distribution, because it affects how well people are able to contribute
> to packages they are not directly maintaining
If our package-building entry point sets up aspects of its desired
normalized (or "sterile") environment itself, surely it's equally easy
for those contributors to build every package in that way, whether they
maintain this particular package or not?
> if my package is not required to work outside
> of a very controlled environment, that is also an impediment to
> co-maintenance
I'm not sure that follows. If the only thing we require is that it works
in a controlled environment, and the controlled environment is documented
and easy to achieve, then surely every prospective co-maintainer is in
an equally good position to be contributing? That seems better, to me, than
having unwritten rules about what environment is "close enough" and what
environment doesn't actually work.
If I want to contribute to (let's say) both GNOME and KDE, but the GNOME
team expects me to be building in one controlled environment, and the KDE
team expects me to be building in a *different* controlled environment,
then sure, that would be a barrier to contribution: I'd have to do that
setup once per team, and maybe they'd be mutually incompatible. But that
isn't going to be the case if we're setting a policy for the whole distro,
which only needs to happen once?
We already do expect maintainers to be building in a specified
environment: Debian unstable (not stable, and not Ubuntu, for example).
I can see that if our policy was something like "must build in a schroot",
then that would be making us vulnerable to a lock-in where we can't
move to Podman or systemd-nspawn or Incus or whatever is the flavour of
the month because our policy says we use schroot, and then we end up
shackled to schroot's particular properties and limitations. (Indeed,
to an extent, we already have that problem by using schroot on official
buildds, and as a result being unable to gain much benefit from work
done on container technologies outside the Debian bubble.)
But that's not what was proposed by this thread: this thread is about
locales. Now that glibc has C.UTF-8 built-in and non-optional, you can
set a normalized or sterile locale regardless of whether you're building
on bare metal, in a VM, in a schroot, in Docker, or whatever, and it's
very easy to do that in a tool (or even an interactive shell) and have
it inherit down through the build? So I'm not sure I see the problem?
If you're making a wider point about use of containers etc. that is
orthogonal to setting the locale, then that would be a valid objection
to someone saying "we should standardize on building in Docker" (and I
would make a similar objection myself), but that's not this thread.
(I also do agree that it is an anti-pattern if we have a specified
environment where tests or QA will be run, and serious consequences for
failures in that environment, without it being reasonably straightforward
for contributors to repeat the testing in a sufficiently similar
controlled environment that they have a decent chance at being able to
reproduce the failure. But, again, that isn't this thread.)
> a lot of the debates we've had in the past years is who gets to
> decide what is in scope
Yes, that's always going to be the case for a community that doesn't
have an authority figure telling us "the scope is what I say it is". We
have debates when we don't all agree, and the scope of our collective
project is one of the foundations for all the other decisions we make,
so it's certainly something that we can't expect to be unanimous. (Insert
wise words from Russ Allbery about the difference between unanimity and
consensus here...)
I hope we can come close enough to a consensus that we're all generally
willing to accept it, though, even if that means sometimes accepting a
narrower or wider scope than I would personally prefer.
> > 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.
>
> Indeed -- however this class of bugs has already been solved because
> reproducible-builds.org have filed bugs wherever this happened, and
> maintainers have added workarounds where it was impossible to fix.
Someone (actually, quite a lot of someones) had to do that testing,
and those fixes or workarounds. Who did it benefit, and would they have
received the same benefit if we had said "building in a locale other than
C.UTF-8 is unsupported", or in some cases "building in a non-UTF-8 locale
is unsupported", and made it straightforward to build in the supported
locales?
I think there is a danger that we sink time and effort into doing work
that we are doing because our (written or unwritten) policy demands it,
even when it isn't clear that there is a real benefit from that work being
done. If that work is a fun and interesting puzzle and someone actively
wants to do it, then great!, but if it's something that a contributor
doesn't actually want to do, and is only doing because there is a rule
that demands it or a sanction that will be applied if it isn't done,
then we do need to consider whether the cost (imposing that work) is
justified by the benefit.
> Turning this workaround into boilerplate code was a mistake already, so the
> answer to the complaint about having to copy boilerplate code that should be
> moved into the framework is "do not copy boilerplate code."
If you don't want package-specific code to be responsible for forcing
a "reasonable" locale where necessary, then what layer do you want to
be responsible for it? dpkg-buildpackage? debhelper? But then you go
on to say that you don't want those layers to set the locale either,
so I'm confused...
smcv
