On Tue, 2012-07-10 at 02:17:22 +0100, Wookey wrote:
> +++ 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.
Thanks.
> 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:
Sorry for not being more clear on this, I guess I thought it was more
obvious from the previous context and it being the first option listed,
I was referring to:
* Introducing build profiles (the specific characters '<>' could be
changed, this is just an example):
Build-Depends: huge (>= 1.0) [i386 arm] <!embedded !bootstrap>, tiny
+ Generic, it can solve other problems like bootstrapping.
+ Does not duplicate information.
+ Does not overload existing syntax.
+ Does not have the problem of mixed positive and negative arches.
- This could only be deployed in Debian on etch+1 and started to be used
on etch+2, that does not mean it cannot be used elsewhere beforehand
given different release cycles.
> 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.
It has the serious disadvantage of duplicating build dependencies,
which can be quite error-prone when there are lots of them.
regards,
guillem
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
