Bug#374029: Fixing inconsisten and unusefull Build-Depends/Conflicts definition
Peter Eisentraut <email@example.com> writes:
> One question to ask is perhaps whether splitting the build dependencies
> into several sets is useful at all, considering that the current state
> of having effectively only one useful set has persistent for such a
> long time.
> Not a lot of people really understand the current definition, and this
> proposal introduces even more ways of getting things wrong. Not a lot
The current description is confusing and does not reflect actual use
so people get it wrong. No wonder.
> of people practice local architecture-only rebuilds or some of the
> other corner cases that would be induced by this proposal. I'm afraid
Every buildd does architecture-only builds so that will be well
tested. The only other existing case is a full build which the
uploader will test if he/she uses pbuilder or a chroot or such (and we
all know everyone should do that). In the last 2 years more and more
often someone has gone and rebuild the full archive from scratch, both
with and without architecture indep packages given it even more
testing. So what corner cases do you talk about?
> that this will just introduce more hard-to-detect bugs, and all the
> upload and rebuild time caused thereby will probably outweigh the
> download time saved by the buildds.
A real bug in the Build-Depends (one missing completly) will be
detected very quickly either by the buildd or by the next rebuild with
A minor bug, such as having a package in Build-Depends instead of
Build-Depends-Arch/indep, while being wastefull, is not harmfull. Same
as having one in there that isn't needed at all. Sometimes people do
notice and if not the waste can't be that big. I don't think that
should worry us too much.
As with Build-Depends[-Indep] detecting a useless dependency or one in
the wrong place stays just as hard to detect as before and detecting a
missing one just as simple so where should the extra bugs come from?
On the other hand the savings can be huge. Think about how many
packages install latex and fonts and generate the documentation
needlessly during build. Installing and purging latex as well as all
the initex runs and font generation takes up a awfull lot of time on