Manoj Srivastava <[EMAIL PROTECTED]> 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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
