On Fri, Nov 06, 2026 at 10:42:24AM +0000, Stefano Rivera wrote:
> > The maintainer (Matthias Klose) believes that build failures which
> > happen with DEB_BUILD_OPTIONS=parallel=1 are not bugs, just "nice
> > things to have", and downgraded the bug to wishlist, leaving the issue
> > unfixed for seven months now.
>
> FWIW, that quoted statement is your summary of Matthias' reply, rather than
> a quote of something he said.
The exact quote would be "building sequentially is nice to have, but
not a must" and may be found in the logs for Bug #1081445 against
src:gcc-11-cross, filed seven years ago and still unfixed. I assume
his opinion has not changed since then.
(Note that this is contrary to the "must" that we can find in Policy 4.2).
I tried to make my request as short as possible, so feel free to ask
about any detail like this one which I may have missed or explained
not well enough.
> I think you both have some reasonable points here. If a package doesn't
> build reliably, it's annoying for everyone. If it fails to build in survey
> rebuilds (as you are doing) then you'll assume it's a bug, and file it.
>
> If a package only builds correctly when you hold it exactly the right way,
> that's just fragility. Something that people will trip up on from time to
> time, and waste time over.
>
> If it doesn't fail to build in the cases that actually matter (buildds and
> the maintainers workflows) then in practice the failure is not terribly
> serious. Obviously annoying if it affects you, though.
I specifically requested not to consider the severity or the RC-ness
status, but since you mention it:
I see it differently.
If I try to build the package and it fails, even when using nocheck,
then the source of the package, and more specifically the scripts
controlling the build, could reasonably be said to be incomplete.
I asked one of the authors (José Eugenio Marchesi) about this failure,
and he agrees that the proposed patch is *necessary*. He authorized
me to quote him:
----------------------------------------------------------------
From what I can see, the patch you propose is necessary.
The target install-exec-local happens to run before install-data and
that is why this fails in single proc:
install-am: all-am
@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
install-exec-am: install-binSCRIPTS install-exec-local
With parallel make, install-data-am might be executed before
install-exec-am. The Automake manual is clear in that no specific
ordering can be assummed in the -local rules, therefore we are careful
to make sure $(DESTDIR)$(bindir) exists.
----------------------------------------------------------------
The package is under GPL-3, which says this:
The "Corresponding Source" for a work in object code form means all
the source code *needed* to generate, install, and (for an executable
work) run the object code and to modify the work, including scripts to
control those activities.
Emphasis on *needed* is mine. Note that the last item is a clear
reference to Makefiles and similar stuff.
So, in my opinion, the source for the Debian package is incomplete,
and it could be argued that we are breaking the spirit of the GPL by
distributing such package in its current state.
Thanks.
