Re: Introducing Build-Recommends / Build-Core-Depends?
On Sat, 13 Aug 2011, Andreas Barth wrote:
> 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.
The resulting packages MUST NOT lack any files or symbols/modules that
would be noticed by packages that depend on it. Otherwise, we might
have unexpected (and untracked!) partial functionality down the
dependecy graph.
Alternatively, we can annotate all packages that depend on this one for
rebuilding. This is entirely doable, but it may require an extremely
large number of rebuilds (entire trees might need to be rebuilt a number
of times) even if you do intelligent partitioning of the rebuild set.
I actually prefer the second alternative, because it is entirely
non-trivial to know that you're missing a symbol or file that could be
used by some other package (especially if such packages do something
weird).
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: