+++ 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 [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
