+++ Guillem Jover [2012-05-12 04:46 +0200]: > I've not checked the details of the current proposed patch, as I think > the correct overall design should be agreed on first. > > I think I might have mentioned this before but I pondered about this > in more general terms some time ago in: > > <http://www.hadrons.org/~guillem/debian/docs/embedded.proposal> > > From those, adding something like profiles support is IMO the nicer and > more generic solution, although it implies some infrastructure changes.
OK. I've looked at this again (finally) and I'm inclined to agree that it seems a lot nicer than adding lots of Build-Depends-StageN fields. As there are quite a lot of suggestions in the above doc, this is the one I think Guillem is referring to and that seems good to me: Set a 'profile' for a build. This could cover various needs including the stageN bootstrap builds. I suggest the profile sould be set with DEB_BUILD_OPTIONS=profile=stage1 (rather than making up a new variable DEB_BUILD_PROFILE). Build-Depends: huge, tiny Build-Depends[stage1]: tiny + Does not break current infrastrcture. + Allows alternatives as well as omitting build-deps + Does not overload existing syntax. - Duplicates part of the original field, which has to be kept in sync, although being side to side, it's easier to do than with a complete different whole directory. This has exactly the same functionality as my existing patch but a more versatile syntax/mechanism and should involve much less repetition in the implementation. The only disadvantage I can see is the removal of the explicit ordering of 'stage=1, stage=2' but it's not hard for a bootstraping tool to know that the profiles 'stage1' and 'stage2' are reserved for this usage. We could even put it in policy. I guess I should try implmenting it and see if there are any obvious problems, but I can't see why there should be. > Of course other possible alternatives other people might come up with > might be even nicer, but my point is that we should strive to design > something that's good, ideally future-proof, somewhat generic, etc, > even if might imply more work, instead of trying to shove some > stuff into the system just because it implies minimal overall > infrastructure changes. No argument from me there. We'll discuss this at debconf this week and see if anyone dislikes this idea. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org