Bug#374029: Fixing inconsisten and unusefull Build-Depends/Conflicts definition

[Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>]

Manoj Srivastava <srivasta@debian.org> writes:

> On 16 Jun 2006, Goswin Brederlow stated:
>
>> the current use and definition of Build-Depends/Conflicts[-Indep] in
>> policy 7.6 don't match. Both use and definition also greatly reduce
>> the usefullness of these fields. This issue has come up again and
>> again over the last few years and nothing has been done about it. I
>> hope this proposal provides a elegant and non disruptive way out so
>> we can finaly do something about it.
>>
>> Currently policy reads:
>
>         SNIP
>
>> This comes down to Build-Depends have to be always
>> installed. Buildds always and only install Build-Depends.
>
>>> Build-Depends-Indep, Build-Conflicts-Indep
>>>
>>> The Build-Depends-Indep and Build-Conflicts-Indep fields must be
>>> satisfied when any of the following targets is invoked: build,
>>> build-indep, binary and binary-indep.  
>
>> But buildds do call the build targets (via dpkg-buildpackage) and
>> don't honor Build-Depends/Conflicts-Indep. And since build calls
>> build-indep that means anything needed to build the architecture
>> independent part needs to be included in Build-Depends. This make
>> the Build-Depends-Indep quite useless.
>
>> Proposal:
>> ---------
>>
>> Two new fields are introduced:
>>
>> Build-Depends-Arch, Build-Conflicts-Arch
>>
>> The Build-Depends-Arch and Build-Conflicts-Arch fields must be
>> satisfied when any of the following targets is invoked:
>> build-arch, binary-arch.
>
>> The existance of either of the two makes build-arch mandatory.
>>
>> The old fields change their meaning:
>>
>> Build-Depends, Build-Conflicts
>>
>> The Build-Depends and Build-Conflicts fields must be satisfied
>> when any target is invoked.
>
>         Does the converse hold as well? Is  Build-Depends a superset
>  of all dependencies until further notice? If not, if I am using an
>  older dpkg-checkbuildeps or an older sbuild, my package may fail to
>  build. 

That could be a requirement for a transitional period, like till etch
becomes stable. Someone wanting to backport to sarge old-stable then
would first have to backport dpkg/sbuild from stable (or copy the perl
script manualy).

Lets ammend the proposal with "Until the stable release supports
Build-Depends-Arch the Build-Depends field must be a superset of
Build-Depends and Build-Depends-Arch and the same goes for
Build-Conflicts." But I don't think this has to be spelled out in
policy.

>         Does this mean a package which conforms to the new proposal
>  would fail if the an old sbuild/dpkg-checkbuilddeps is used? In other
>  words, can someone running Sarge build a package from Etch?

Yes it would fail and not it wouldn't build. But that depends on the
above ammendment.

MfG
        Goswin