Using portage as a system builder instead of system updater?

[BigBaaadBob]

This is touched on in https://forums.gentoo.org/viewtopic.php?t=28559.

I'd like to use portage to build system images for various kinds of systems (where "system" means a Linux-based computer-based thing that needs a complete set of software like the kernel, apps, libraries, etc). This is different from using it to [i]update[/] systems because:

I need to direct the built stuff to different areas depending on what system is being built.
I need to cross compile stuff depending on what system is being built.

Has anone done any work in this area? Presumably I would need to parameterize where stuff gets installed (instead of /) and where the portage configuration comes from (instead of /etc) and things like that. I might want to also redefine the pseudo targets like "system" and "world".

Pointers or tips?

[orb9]

This thread might be helpful:
https://forums.gentoo.org/viewtopic.php?t=58231&highlight=installing+gentoo

I did something similiar when compiling gentoo for my server (=pentium3) on my desktop machine(=athlon xp). Simply said: I just bootstrapped a second gentoo in a temporary directory (on a separate harddisc) and chroot'ed into it. Then is set compiler flags in make.conf of the chroot-environment and compiled. Finally I put the harddisc in the target system and did some final configuration. Worked perfectly for me.
_________________
"Without music, life would be a mistake - I would only believe in a god who knew how to dance." (Nietzsche)

[BigBaaadBob]

Since I'm going to be whacking portage, I'd like to get it directly from CVS so I can update it more easily. Is it accessible via anon CVS? (The portage code, not the porgages, of course!)

[BigBaaadBob]

Starting with portage-2.0.49_pre17, I've added new variable (confdir) and a corresponding environment var (CONFDIR). By default, confdir has the value "/etc/", and it is used to access all of the portage stuff that was previously hardcoded in /etc/, like /etc/make.conf, /etc/make.globals, etc. Doing this and setting some environment variables (PATH, PYTHONPATH, CONFDIR, and ROOT) I can successfully build self-targed stuff completely disconnected from the existing system, without resorting to chroot hacks. (Toolchain stuff like GCC and friends excepted for now.)

There is a little problem with "profiles" (profiledir) because this isn't cleanly handled in portage.py (some places hardcoded, some not) and because it conflicts a little with what I envision the usage model to be in this mode of operation. My use case is that I want to build a number of different products (with differents sets of software and using different architectures), which is somewhat like the "profiles" feature is intended for, but I expect each of these products to be using a different confdir. I'd rather have the option of having profiledir==confdir. It isn't a big deal though. Cleaning up the use of profiledir is more important.

Another problem is that everything in the portages pretty much depends (transitively) on baselayout. I expect each of these products i'm building to have a different baselayout, but baselayout isn't virtual. Maybe it is just as simple as changing the glibc and baselayout ebuilds and adding a baselayout virtual? I doubt it. This will need some thought.

Also, I wonder about the handling of "root". In some places it appears that the code wants to handle multiple roots and in other cases it is hard coded to "/". For example: