On Tue, Jul 23, 2019 at 01:30:58PM +0100, Ian Jackson wrote: > I suggest the following approach: > > - Introduce the words "supported" and "reasonable". So > > Packages must build from source in any supported environment; > they should build from source in any reasonable environment. > > - Provide a place to answer these questions: > > What is a supported, or a reasonable, environment, is not > completely defined, but here are some examples: > > - An environment with only one cpu available is supported. > - An environment with a working but non-default compiler > is reasonable but not supported.
I believe this is more complex than required, and will not necessarily solve the problem. Suppose we write clearly in Debian Policy that build environments with one CPU are fully supported, and yet there are people who claim that because buildds have several cores, it is wrong to report such bugs as serious. We would be back at square one. This is why I've described this problem as kafkaesque. > On the point at issue, do these packages build in a cheap single-vcpu > vm from some kind of cloud vm service ? ISTM that this is a much > better argument than the one you made, if the premise is true. Sorry, I'm a little bit lost here. What do you refer exactly by "these packages"? All packages in Debian build ok in a single CPU system, except the few ones I've already reported in the last months/years and maybe a few ones I have not reported yet because of lack of time. I estimate there must be only a handful of packages with bugs like this one. Whether single-cpu machines are cheap or not depend mainly on the amount of RAM, but contrary to what some people insinuate, my goal is not and never has been to build packages in "cheap" machines, nor I am complaining that packages do not build ok in "cheap" machines. My complain is that some packages do not build ok in machines which are perfectly capable of building them, and yet we seem to be trying to shift the blame and the responsability to the end user for not having a clone of buildd.debian.org. Russ Allbery wrote: > I'm rather dubious that it makes sense to *require* multiple cores to > build a package for exactly the reason that Santiago gave: single-core VMs > are very common and a not-very-exotic environment in which someone may > reasonably want to make changes to a package and rebuild it. But maybe > I'm missing something that would make that restriction make sense. Thanks a lot for this. No, I don't think you are missing anything. > And it's possible that multi-core may be a reasonable requirement > for that "heavy package" tier. How would that become a requirement? Big packages (as in "packages requiring a lot of RAM or a lot of disk") do not really need more than one CPU to build because of they being "big". In theory, using more than one CPU should just make the build to go faster, that's all. Ideally, it should be up to the end user to decide if they want the package to build faster or not, I don't see it as something that needs to be regulated by Policy. A funny example which could be seen as a counter-example but it is not in my opinion: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924325 This is a Makefile bug in gcc-8-cross, a package which would qualify as "big". Maintainer did not initially believe it was a real bug, maybe because he built the package a lot of times in the past and the bug never happened to him. See what the maintainer did afterwards: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928424 Would we say in this case that the package "requires" more than one CPU to build? To me it seems like a bug which may happen to anybody, and the fact that it did not happen in buildd.debian.org yet is due to pure chance. It must be noted that many of the bugs I found while building on single-CPU systems are really like the one in gcc-8-cross, and not like the one in p4est. A few more examples: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906623 heimdal, FTBFS because of Makefile bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923476 webkit2gtk, FTBFS because of Makefile bug Thanks.
