Hi Johannes, On Tue, Oct 15, 2013 at 08:34:00AM +0200, Johannes Schauer wrote: > Quoting YunQiang Su (2013-10-15 08:08:52) > > On Tue, Oct 15, 2013 at 2:03 PM, Johannes Schauer <j.scha...@email.de> > > wrote: > > > What is yet to be decided is the concrete format for the Build-Depends > > > syntax extension. The first proposals suggested a syntax which looked like > > > > > > Build-Depends: foo [amd64] <!stage1> > > I'd prefer Build-Depends-Stage1 if possible. > > When bootstrap, dpkg only ask for these build-depends while for normal > > build, > > dpkg should merge Build-Depends-Stage1 and Build-Depends.
> this approach does not work because it does not allow to specify additional > dependencies for when a source package is compiled with a certain profile > activated. > The Build-Depends-Stage1 field name was used in earlier proposals with a > different meaning. Instead of making the final build dependencies the union of > Build-Depends and Build-Depends-Stage1 as you proposed, Build-Depends-Stage1 > contained all dependencies necessary for the build profile "stage1". When > doing > a normal build, only the Build-Depends would be used. When building with the > build profile "stage1" activated only the Build-Depends-Stage1 would be used. > This solves the problem I explained above which your solution has. > This Build-Depends-Stage1 format was abolished in favor of the syntax > additions explained in my last email because of the following reasons: > - it requires variable field names to match all possible profiles > - it requires a near duplication of the Build-Depends field which is highly > prone to bitrot > - it does not work with multiple profiles activated at the same time > For a full history of the development of this see > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661538 My recollection is that the "abolishing" of the Build-Depends-Stage1 field was done by the same dpkg maintainer who you say is now not giving you feedback. It's elegant that a general-purpose syntax has been proposed, but elegance isn't worth anything if it doesn't result in shipping code. Being able to automatically bootstrap the Debian archive is self-evidently useful to the project. The other uses proposed for profiles are all corner cases that should be kept far, far away from the archive. I don't think the implementation of automated bootstrapping should be allowed to block on such pie-in-the-sky plans for profiles. My understanding is that all build-dependency loops in the archive can be broken with a single additional stage (stage1), so only one added profile and one added build-dependency field would be required. Yes, it could bitrot, but it's better than not having any of the data in the source packages at all. And if someone really finds this inelegant and insists that we should extend the syntax of the Build-Depends field, let them step up and make that happen instead of pointing at grandiose plans they're not making any effort to implement. A Build-Depends-Stage1 field requires no support from dpkg in the archive to implement. Cheers, -- 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
