Santiago Vila dijo [Thu, Jul 25, 2019 at 01:22:42PM +0200]: > > Or are you asking the TC for advice, or are you asking us to use a > > different one of the TC's powers? > > Advice first. OK, good this is made explicit. Thanks. > > There are many aspects of a build environment that might be considered > > reasonable and might not, and they are generally evaluated on a > > case-by-case basis. A working build environment needs "enough" RAM (a > > lot more for gcc or WebKit than for hello); it needs "enough" disk space > > (likewise); it needs a writeable /tmp; it needs a correctly-installed > > Debian toolchain (I hope you wouldn't argue that it's RC if a package > > FTFBS with a patched gcc in /usr/local/bin); it needs to be on a > > case-sensitive filesystem (I hope you wouldn't argue that FTBFS on > > FAT/NTFS/SMB would be release-critical); it needs to not have weird > > LD_PRELOAD hacks subverting its expectations; and so on. > > Ok, my build environment: > (...) > The only thing it did not have was more than one CPU, but AFAIK that's > not something that may be considered as a misconfiguration. I agree with this. It might be considered too little by some people, but it's not documented. > > For the specific question of whether a single CPU core is a "reasonable" > > build environment, my answer at the moment is "I don't know". > > That's basically the first question I'd like to have answered by > the TC, yes. I would express it this way: > > Does "build-essential" imply multi-core? _My_ take is that, as it currently stands, it should not be implied. > I believe there is a wide consensus that a package which does not > build with one CPU is a bug (I'm *not* talking about severity here). Right. Nobody said the bug was worth closing - it was only downgraded. But this "only" had important practical implications. > Even if we ever wanted to allow packages to "need" more than one CPU > for building, I'd like to believe that we would do so by introducing a > new control field for that, say, Build-CPU, instead of making > multi-core mandatory for all packages. > > The great paradox of all this is that we would be better by having > this stupid Build-CPU field and enforcing it than not having anything > at all. Fixing a Makefile bug may take time and effort, but it may not > be argued that adding a "Build-CPU: 2" line to debian/control would be > an unbearable burden for maintainers. I am not sure about this - First of all, the issue needs to be identified (not always the case, if nobody is building packages on single-core systems), so most probably it would not be introduced 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. > At least that way Debian Policy would say the truth again. It will be > possible again to build a package on a system having build-essential, > the build-dependencies and the number of CPUs in the Build-CPU field. My opinion, based on what we talked about this bug during DebConf and the people I talked with, is that we should provide an advice following roughly: - The Release Team are empowered to set the base requirements to build packages for a given release (starting with Bullseye, I don't think there's any reason to change qualifications for Buster) - Get this documented, quite probably in the RT delegation. Of course, we have to get this moving within the TC, but I hope we can do this before our next meeting (August 21).
Attachment:
signature.asc
Description: PGP signature