[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Introducing Build-Recommends / Build-Core-Depends?



* Colin Watson (cjwatson@debian.org) [110813 15:27]:
> On Sat, Aug 13, 2011 at 01:28:36PM +0200, Andreas Barth wrote:
> > 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.
> 
> Wookey's proposal was to have Build-Depends-Stage1 (etc. - I may have
> misspelled this slightly), and for a bootstrap-aware autobuilder to
> build its way through each of the stages until it reaches the real
> Build-Depends.  I personally prefer this approach because it makes it
> clearer that the final build-depends is what we really want to reach,
> and that binaries uploaded to the real Debian archive still need to have
> all those build-dependencies in place.

Wookeys proposal is less generic and more centric to bootstrapping.
Which has its advantages, and its disadvantages.

I'm not saying that this proposal is better. It is different, and has
a different set of advantages. Plusside is that it's more generic, so
you could do more with debian/control fields, debhelper and cdbs, and
less with specific additions to debian/rules. 

Generic options are usually better IMHO, but well - YMMV.



> I think Wookey indicated that there was at least one case where more
> than one stage is required, in which case Build-Recommends does not
> really seem to solve the full problem.


As long as all stages produces binary packages which are policy
conformant working, it does. 

Consider this case:
Source: A
Build-Depends: b, c
Build-Core-Depends: 
Binary: a1
Binary: a2, build-depends b
Binary: a3, build-depends c

Source: B
Build-Depends: a1
Binary: b

Source: C
Build-Depends: a2
Binary: c


In this case, the first run on A will only produce a1. Then B could be
built, then re-build A with what is available now. This will produce
a1 and a2. Then build C. Then re-build A with all Build-Depends
installed, which will give us a full package set.





Andi


Reply to: