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 ready. Please lookup the link provided by Andreas to Wookey's talk at DebConf11. > 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 ============= http://www.linux.codehelp.co.uk/
Attachment:
pgppW0kxhUSjn.pgp
Description: PGP signature