[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

On Sun, 14 Aug 2011 17:54:55 -0500
Peter Samuelson <peter@p12n.org> wrote:

> [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. 

That doesn't break build-dependency loops. The whole point is that when
bootstrapping a new architecture, certain packages must be built in a
restricted mode which is *not* uploaded to the main archive but which
provides sufficient support to build the other side of the dependency
loop. Packages are then rebuilt when all it's build-dependencies are

Please lookup the link provided by Andreas to Wookey's talk at

> Why is a separate field needed at the source package level? 

Please read the original post in this thread again. This is not about
how packages are split in the archive. This is not about per-binary.
This is source:binary dependency loops when bootstrapping (or
cross-building) and entire set of packages from scratch.

> 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? 

The variant is installed locally so that the packages which depend on
it can be built. Then the original package can be rebuilt when it's
build dependencies exist, along with packages which were built against
(or using) the "interim" version.

This can all be done but it involves making manual changes in various
packages to allow for the variant build.

> 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.)

It's not just about documentation - that could be handled by
DEB_BUILD_OPTIONS="nodocs" as Build-Depends-Indep is the opposite. It's
not about building just the architecture-independent bits, it's about
building the architecture-dependent stuff when the build-dependencies
have not yet been built. (Often because those build-dependencies
themselves have runtime dependencies on the library which is being built
- and therefore cannot be installed - and the library uses those
binaries to as part of it's build. Classic
dependency:build-dependency loop which makes bootstrapping impossible
without changes in the package(s).)

Source: libfoo
Build-Depends: bar
Package: libfoo3
Package: libfoo-bin

Source: bar
Package: bar
Depends: libfoo-bin

Other examples include poppler:cups:poppler:cups which doesn't involve
documentation at all - see Wookey's talk at DebConf11 for all the gory
detail. (Link in Andreas' original post.)


Neil Williams

Attachment: pgp3DoID6DY0L.pgp
Description: PGP signature

Reply to: