Re: Bug#374029: Fixing inconsisten and unusefull Build-Depends/Conflicts definition
Thomas Bushnell BSG <email@example.com> writes:
> Stephen Gran <firstname.lastname@example.org> writes:
>> This one time, at band camp, Thomas Bushnell BSG said:
>>> Wouter Verhelst <email@example.com> writes:
>>> > Sbuild explicitely, by design, only looks at build-depends. So in order
>>> > for build-depends to be useful at this time if you want a package to
>>> > build, you need to list mostly everything in build-depends right now
>>> > anyway.
>>> Isn't it sbuild's job to comply with policy, not the other way round?
>> Isn't it policy's job to reflect best current practice, not dictate it?
> Whenever this has been asked in the past, sbuild has simply declared
> "this is how I want to do it." I have no idea why.
> If there is no technical reason for sbuild to behave this way, and if
> it does not in fact conform to policy, how about making it do the
> right thing?
dpkg-buildpackage and sbuild have the option of building all packages
(-b) or just arch packages (-B). The idea was that you don't need
Build-Depends-Indep installed for -B because only arch packages are to
be build and not indep. So that was implemented.
Then reality hit because the build-arch target is not required and
build must be called instead. So all the indep stuff has to be build
too and the Build-Depends[-Indep] usage became what it is now.