Ansgar <ans...@debian.org> writes: > Adrian Bunk writes: >> - An environment with at least 16 GB RAM is supported. >> >> Not sure about the exact number, but since many packages have >> workarounds for gcc or ld running into the 4 GB address space >> limit on i386 it is clear that several packages wouldn't build >> in an amd64 vm with only 8 GB RAM.
> Aren't there even packages that will not build on i386 with a i386 > kernel (non-PAE) as they require the full 4 GB address space to be > buildable? > Even more, from the "32 bit archs in Debian" BoF at DebConf15 I remember > the suggestion that one might have to switch to 64-bit compilers even on > 32-bit architectures in the future... So building packages would in > general require a 64-bit kernel, multi-arch and 4+ GB RAM. Weighing in here as a Policy Editor, I think we do have a rough consensus in the project about what sorts of resources a package may or may not require in order to build, in that we've made firm decisions both directions (dropping architectures that can no longer build large packages in a reasonable length of time, for example, but also rejecting packages that cannot be built reasonably on our buildds). But they're largely-undocumented "tribal knowledge." I would be in favor of writing down those guidelines, as have been discussed on this thread, and publishing them as part of Policy, since I think it would provide useful guide rails for developers to know how many resources they can reasonably require for the package build, and what sort of build environments they need to support (and therefore should at least consider simulating to ensure that they do support them). We could then align our archive-wide rebuild testing with the documented minimum requirements for package builds, and all be consistently testing the same thing, which would prevent some surprises. I do think, as this thread has made clear, that we do have some minimum requirements and don't expect packages to build in smaller environments. Minimum available memory is a really obvious one; I'm sure many of our packages won't build in 128MB of RAM, for example. 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. It's possible that we may have to have a couple of levels of requirements: base minimum requirements below which we don't expect any maintainer to worry about, and a higher tier of requirements for larger packages. For instance, I'm not sure that we want to say that we don't support building *any* Debian package on a host that can't build Firefox (particularly given our support for embedded devices); coreutils probably should build on a lighter-weight machine than Firefox requires. And it's possible that multi-core may be a reasonable requirement for that "heavy package" tier. If we do go down that path, though, it would be nice to add a metadata field so that maintainers can flag their packages as being "heavy" so that our users know to expect them to not build on commodity VMs. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>