Re: Help requested: Packages which FTBFS randomly
- Date: Tue, 21 Feb 2017 22:00:02 +0100
- From: Santiago Vila <sanvila@xxxxxxx>
- Subject: Re: Help requested: Packages which FTBFS randomly
On Tue, Feb 21, 2017 at 09:36:58PM +0100, Vincent Bernat wrote:
> Accomodating for all build environments is a slippery slope. What if I
> use a 128MB host with 64GB of swap? Timing-related tests will start to
> fail. Is it Debian job to fix all the test suites? Should I be able to
> build packages on a system not supporting ACL? On a kernel not
> supporting users? On a grsec kernel? With a low ulimit value for the
> number of opened files or on the stack size? On a chroot on an Android
> phone? On the Windows Subsystem for Linux?
I don't really have a problem with multi-core being the only supported
build setup in some distant future, but if such thing ever happens, it
should be because Debian decides it, either the Release Managers at
the start of a release cycle (not at the end), or the Debian
Developers as a whole by way of a General Resolution.
The current scenario where some maintainers think they have the power
to decide about this on their own for their own packages is not
acceptable at all.
Having said that, there are practical reasons why we should keep
support for single-CPU build systems, for example, you can split the
work better if you have a build farm and you can save real money.
Also, the number of packages that we have to fix to support this is
still extremely small, and most of them have been fixed as they have
been reported. The number of packages in stretch which are not
buildable on a single-CPU system may be counted with the fingers of
just one hand.
Nothing to do with the number of problems that would arise if you use
a 128MB host with 64GB of swap or any of the really weird things you
mention. Really, building with a single CPU is not a sin, and people
should not be punished for doing so.