On Fri, Oct 10, 2014 at 09:45:37PM -0400, Rich Freeman wrote: > 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.
Why bother with multiple layers and per-profile package lists if a straight emerge is all you need? My ideal long-term situation would be to explicitly list all a package's dependencies (no implicit @system dependencies). Then have the stage1 just emerge a self-hosting virtual/toolchain (which can have per-arch dependencies if it needs them) from an arbitrary seed, and stage2 rebuild -e using itself. Everything after that could be user-generated @world stuff, and you might want virtual/release with nano and whatever else you want to put up under releases/$ARCH/autobuilds/gentoo-$ARCH-$DATE.tar.bz. That's less magical, and Catalyst could be a bit simpler, but I don't have the energy to move things there ;). It's also pretty much what we have now, except @system is floating around between virtual/toolchain (our current stage1 packages) and virtual/release (our current stage3 packages). Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
signature.asc
Description: OpenPGP digital signature
