Bug#374029: Fixing inconsisten and unusefull Build-Depends/Conflicts definition
On Mon, Jun 19, 2006 at 01:02:42PM -0500, Manoj Srivastava wrote:
> On 16 Jun 2006, Goswin Brederlow stated:
> > 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.
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.
So, yes, for all practical matters build-depends right now is a superset
of build-depends-indep.
> > 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?
"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)
Of course, if a package does not build with old dpkg-buildpackage, that
might be a problem; not sure about that.
--
Fun will now commence
-- Seven Of Nine, "Ashes to Ashes", stardate 53679.4
Reply to: