Bug#1061468: gloo: attempts to build on unsupported 32 bit systems

[Dan Bungert <daniel.bungert@canonical.com>]

[Paul Wise]
> The right way to do this is to Build-Depend: architecture-is-64-bit

Thanks Paul, I didn't know about that.  Clearly architecture-is-64-bit is the
better solution.

[Petter Reinholdtsen]
> [Dan Bungert]
> > I suggest adjusting the control file to reflect this state so that
> > builds are only attempted on 64 bit systems.
> Why?  Which problem are you trying to solve?  Doing such change will
> fail to automatically discover if gloo start working on other
> architectures, and require extra work to keep the list of architectures
> up to date as Debian evolves.  As far as I can see, the disadvantage of
> trying to build on non-supported architectures is a few wasted CPU
> cycles, while the advantage is less human time spent on package
> maintenance.  Did I miss something?  To me, saving humans time is more
> valuable than saving CPU time.

Saving humans time is a tradeoff I will agree with.  Another angle though is
the time of people looking at problems across an architecture or, like me, who
are temporarily looking at this package and checking why some of the builds
fail.  These "some builds fail" bugs can sometimes indicate a flaky build and
that the rest of the builds can't be considered stable.

Of course that's not the case here - it's a straightforward case of builds
being disabled for 32 bit arches, which is a reasonable decision for upstream
to make.  No problem there.  A bit unfortunate that cmake has this critical
string not at the end of the log file, so the "tail of log" reports at
https://buildd.debian.org/status/package.php?p=gloo are missing this detail,
but that's a cmake issue.

So the tradeoff I'm proposing is making it simpler for others looking at the
package, to remove failed builds that we know will fail.  It indeed has the
downside that if the 32 bit support status changes it will require a change to
reverse.  Do you consider that scenario likely?

There is side benefit here that the CPU time being saved is a bit more rarefied
than amd64.

If the above is uncompelling, you are of course free to decline the change.

-Dan