Introducing Build-Recommends / Build-Core-Depends?
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
Reply to: