On Thu, Jan 17, 2013 at 08:33:57AM +0100, Wouter Verhelst wrote: > However, to do that, there's one thing I'm missing in your mail: there > will be cases where packages, when built in a particular profile do not > support some functionality. That is, the package is available and does > most of what the full package does, but because some build-dependency is > missing, it doesn't support some feature or other -- for example, let's > say that a document translation package (which we'll call "foo") which > supports many input formats does not support XML as an input format when > built in the stage1 profile. The output of its stage1 build would not > change the number of binary packages built with the source package, it > would just build a binary package with reduced functionality.
> Now it might be that a package build-depends on our package foo because > it needs to translate documents in that XML format into something else, > With your proposal, there's no way for the build-depending package to > declare that it needs a version of foo that was built at a richer > profile than stage1. The obviously correct solution to this is to strictly order the builds, by considering the stageX package builds as satisfying the build dependencies *only* of those packages that are part of the build loop. All other revdeps should wait until the final version of the package is available. In that case, misbuilds are only possible if there's an error in the bootstrapping metadata itself (or in the bootstrapping code). -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
