Bug#374029: Fixing inconsisten and unusefull Build-Depends/Conflicts definition
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.
> 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-indep, binary-indep.
>
> The existance of either of the two makes build-indep mandatory.
>
> The use of Build-Depends/Conflicts-Arch/Indep is optional but should
> be used in architecture "all/any" mixed packages. If any of them is
> omitted the respective Build-Depends/Conflicts field must be
> suffient already.
>
> ### End of Proposal ###
> - Simple to implement.
> + Trivial change in dpkg for the new field.
> + dpkg-checkbuilddeps has to parse 3 fields (2 with -B option)
> instead of 2 (1).
> + sbuild, same change
> + Simple change for 'apt-get build-dep'
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?
manoj
--
Linux: because a PC is a terrible thing to waste ksh@cis.ufl.edu put
this on Tshirts in '93
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: