Bug#932795: How to handle FTBFS bugs in release architectures
On Mon, Jul 29, 2019 at 05:23:49PM -0500, Gunnar Wolf wrote:
> without a bug roundtrip plus new upload. But second, and I think most
> important: how many extra fields would this need? Build-CPU,
> Build-RAM, Build-HDD spring to mind... But many other more detailed
> bits could creep their way in if we were to open up to this. And
> anyway, this has to go to the Policy editors anyway.
A clarification has to be made here: The Build-CPU field has never
been a serious proposal but instead a crazy and stupid idea which
tries to highlight the current kafkaesque nature of things.
The paragraph in Debian Policy which I try to follow when reporting
FTBFS bugs is the one saying "It must be possible to build the package
in a system having build-essential and the build-dependencies installed".
My interpretation is that the build must be possible on a system
which, in addition to following certain standards, is also physically
*capable* of building the package [*]. This would already implicitly
include enough RAM and enough disk [**], but not more than one CPU,
because a single-cpu machine should just build the package slower,
not refuse to build the package or fail to build it.
This is really like a weak form of "reproducible builds", as in "every
time I try to build the package in a capable system, the build succeeds".
The issue nobody answered so far is: How do we make the archive
reproducible again (in this weak sense) if we don't introduce the
Build-CPU field *and* we stop enforcing that packages must build from
source regardless of the number of CPUs?
Some people will probably say that this weak form of reproducible
builds is not particularly interesting or desirable, but I think it is
exactly what our users expect, and maybe also a prerequisite for the
reproducible-builds.org effort.
(How could we ever make reproducible builds mandatory in some future if
we are not even able to make the build *reliable* in a stable release?)
[*] For example, my system was perfectly capable of building the p4est
package, because p4est just needed 600 MB of RAM for building. The
build failure was the result of a bug in the package, not the result
of trying the build in a system incapable of building it.
[**] I know how much RAM and disk each package requires, because I
measure it during the build and use the info for the next try. The
proposed Build-RAM or Build-Disk fields could be interesting in the
long run, but they are not the purpose of the present bug.
Thanks.
Reply to: