[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
