Bug#374029: Fixing inconsisten and unusefull Build-Depends/Conflicts definition
On 19 Jun 2006, Wouter Verhelst said:
> On Mon, Jun 19, 2006 at 01:02:42PM -0500, Manoj Srivastava wrote:
>> On 16 Jun 2006, Goswin Brederlow stated:
>>> 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.
>
> 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.
>
> It is in fact not against policy to list build dependencies that
> could technically be put in build-depends-indep in build-depends
> only, and I believe (though I'm not sure, and can't remember offhand
> where) that I have already seen some packages do so in the past.
This is true, I have done so in some of my packages (the
reasons escape me, but it did fix a build failure)
> So, yes, for all practical matters build-depends right now is a
> superset of build-depends-indep.
OK. and this is because the build tools (sbuild,
dpkg-buildpackage) in current stable work that way.
>> 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?
>
> "old sbuild" should not be an issue. Official buildd hosts never run
> sbuild from stable, they run sbuild from a separate repository at
> db.debian.org. If policy is updated to do something new which will
> benefit the buildd hosts, then sbuild will follow suit (provided
> there is code to do that)
There are no known private installations of sbuild? The popcon
rating seems to suggest there are more installations of sbuild out
there than just the official buildd's. Still, not building with old
sbuild perhaps has less impact of the users than not building with
old dpkg.
> Of course, if a package does not build with old dpkg-buildpackage,
> that might be a problem; not sure about that.
dpkg-checkbuildeps might return an insufficient list, which is
bad -- especially for automated build mechanisms like the ones I use
for building my packages in a virtual machine.
Previously, any new feature in dpkg which goes into release
foo gets into policy in release foo + 1. Is there a compelling
reason to diverge from this practice?
manoj
--
Finagle's First Law: If an experiment works, something has gone wrong.
Manoj Srivastava <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: