Re: Introducing Build-Recommends / Build-Core-Depends?

[Peter Samuelson <peter@p12n.org>]

[Andreas Barth]
> Introducing Build-Recommends / Build-Core-Depends
> 
> We should be able to specify in the package saying "only these
> build-dependencies are needed to get a functionally working package".
> For such an build, the packages which are not needed for building
> working core packages are annoted in an additional header (e.g.
> Build-Recommends), but are still specified in Build-Depends to not
> break the old tools.

I think I really prefer the option of doing per-binary-package
Build-Depends.  The presence of a Build-Depends field for a specific
binary package already implies that if you have those specific
build-deps available, you can build at least that one package.  I guess
the way to bootstrap would be to hold the package until you have enough
build-deps to build at least one binary package from it, then do so,
with some way to tell dpkg-buildpackage to not abort if the source
package level build-deps are not all available.

Why is a separate field needed at the source package level?  It is
implied by the existence of at least one Build-Depends field at the
binary package level.  The only reason you'd need a separate field is
if you're talking about building two different variants of a single
_binary_ package.  Is that really useful?  It is sign at least in many
cases that it may be useful to split the binary packages further.

(And, come to think of it, for build deps like docbook processors,
we already have Build-Depends-Indep.  I wonder if we're using it
everywhere we should be.)

-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/