On Fri, 10 Oct 2014, Rich Freeman wrote:
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.
All of the above suggestions would require changes to catalyst.
In any case, given the way we build a stage1 and bootstrap stage2, that
isn't possible. For stage1 and stage2 the *order* we build packages is
relevant. We rely on portage following that list in sequence.
Furthermore, because of the implicit dependencies and issues with circular
dependencies, it would likely be impossible for portage to resolve the
list of packages to build for stage1 and stage2 from a virtual.
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.
That's how catalyst already works.
To address one point in your last sentence in the above quote:
"The root stage would not depend on another stage, and therefore would be
built from the host system."
You almost always don't want to build with the state of a live system, but
of a clean seed - that's why releng tells catalyst to use a stage3 as the
seed for the stage1.
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.
No, not really. You're "over-thinking" this. To be able to "split" the
system set and the stages releng provides, all we need is to fix the bug
that was already mentioned before and have releng provide stages built
from a stage3 (while removing some packages from the system set) and a
list of packages that we want to provide (the ones dropped from system and
a select "few" others).
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).
We build stages using a profile. One of the variables set on stage specs
is "profile" to list the profile to be used in the stage.
--
Rich
Regards,
Jorge Manuel B. S. Vicetto
Gentoo Developer
PS - As I've warned before, I'm not following closely the dev ml. So you
got this reply now, because I just happened to look at the emails in this
ml. If you want me to comment further, your best option is to poke me
about it.
