On Fri, Oct 10, 2014 at 5:31 PM, W. Trevor King <wk...@tremily.us> wrote:
> On Fri, Oct 10, 2014 at 09:22:18PM +0000, Robin H. Johnson wrote:
>> In a similar vein, would releng be open to moving stage1/2/3 package
>> sets to virtual packages or package sets? Presently they are inside
>> catalyst, and I think this would clean things up a lot.
>
> They're already in the Portage tree (the profile's packages.build for
> stage1, scripts/bootstrap.sh for stage2, and the profile's packages
> for stage3) [1].

Obviously this entails work on somebody's part, but would it still
make sense to make the stage build process more generic along the
lines Robin suggested?  That is, instead of having 3 specific places
we use to generate a stage1/2/3, we instead just define a stage as a
virtual of some kind that optionally depends on another stage (not
necessarily using the standard DEPEND mechanism) and then pulls in a
list of packages.  The root stage would not depend on another stage,
and therefore would be built from the host system.

The build system would just iteratively start at the bottom and output
a tarball or whatever as each level is completed, then use that as the
basis for bootstrapping the next.

Such a design would also eliminate the need to have the same list of
packages define the contents of @system and a stage3.  It could also
support any number of stages, with any names we wish.

My intent here isn't to get three cheers for making the releng team do
more work.  I'm actually more interested in feedback as to whether
there are any obvious flaws in an approach like this that I'm missing,
or whether something entirely different would be better.

I would also still have stage builds use a profile of some kind - that
could be useful from a standpoint of setting USE flags and so on.
However, if it made sense to build earlier stages with different flags
they could still be specified as USE dependencies (maybe due to
circular deps you have to build a package with different set of USE
flags before you can build the desired USE flags in a later stage).

--
Rich

Reply via email to