Hi,
During bootstraping a new architecture, there are sometimes ugly build-dependency-loops (usually involving generating documentation for the core build utilities means you need to have the architecture already available; same with graphical tools). During DebConf, Wookey had a talk which lead to us discussing some ideas how to support that. Most packages are not affected at all by that, and current behaviour isn't changing as long as package source files are not changed. Below is my summary of the ideas - names et all are of course just names and up to be changed. Advantage of this schema is that most implementation is just package-local - the maintainer knows which minimal versions his source package could produce, and just annotates them. Coordination between different packages is not needed so much anymore, and we could try to bring the build-dependencies more into a tree-shape. Please see e.g. http://meetings-archive.debian.net/pub/debian-meetings/2011/debconf11/low/745_Bootstrapable_Debian.ogv for the talk. Situation The usual variants of build-dependency-loops mean that the source package could still produce working binary packages, but documentation and/or additional (e.g. -x11) packages are missing. In the few cases where this is not possible, porters need to hand-hold the package anyways. This proposal would like to remove the repetative parts of bootstraping a new architecture, not the parts where the porters really need to port. A typical loop is e.g. cups needs qt, which needs poppler which needs cups to build correctly. The typical core loops only involves changing a small number of packages, however many packages are affected by the loop (e.g. any package using qt or poppler as build-depends). I'd like to have that fixed in a way that we get rid of the build-dependency-loops as far as technically possible. Upstream is usually better than we are by using ./configure and scaning which packages are there, and which not, whereas we usually depend on the full archive being already built. 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. Optionally, we could introduce Build-Core-Depends which only has the minimum set of build-dependencies the package needs. Technically, that's not that large a difference but just a different way of writing it down. Also, the binary packages in the debian/control template could have Build-Depends specified which means that they should only be built if those packages are actually installed (so we could do an automated graph analyis, and also dh and cdbs could just drop them, so that debian/rules doesn't need to reflect the dependencies); however, any package in an binary packages build-depends needs to be part of the source package build-depends-line so that just downloading all build-depends does the right thing (as of now). Packages with no additional Build-Depends specified can be built with the minimum set installed. Building with core Dependencies only If doing an build of the core functionality only, norecommends is added to the environment DEB_BUILD_OPTIONS. This is the signal for dpkg-buildpackage etc to only check for the minimal set of packages, and for the debian/rules to accept if some functionality is missing (i.e. might require changes to usage of ./configure). (Buildds should do it in a way that they first check if however all recommends are available, and only failing that setting the header - makes it more likely we get full packages early; but that's an implementation sidenote). Resulting packages All binary packages built need to be functionally working, and follow the standard for packages on ftp-master. This means they could e.g. miss documentation (as long as they are not RC-buggy, i.e. they need to have changelog and copyright), and that it might be that not all binary packages are built (e.g. via the Build-Dependency-mechanimsn in debian/control above). Often cutting off documentation and graphical packages is enough for a minimal version. To mark such packages and to be able to decide when to re-schedule the build, all binary-packages get the additional header Build-Depends: minmal package_version .... injected, so that one could see later on that this was a partial build and reschedule a new build when newly upcoming packages allow more binary packages to be built, or all build-dependencies are available and we could do a clean full build. Tools This affects dpkg-buildpackage, dpkg-checkbuilddeps, and dpkg-gencontrol. It also (should) affect debhelper and cdbs to ease migration of packages to build-recommends. It would be nice if wanna-build could cope with such packages in a more sensible way, but that's already not so necessary anymore. All of these changes are however rather small, and don't affect packages not using build-recommends headers. Comments? Suggestions? Andi -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110813112836.ga6...@mails.so.argh.org