Re: [gentoo-dev] BUILDROOT concept (was Re: [gentoo-dev] ROOT variable)

On Mon, Apr 26, 2004 at 12:38:00PM -0400, Paul Smith wrote:
> %% david@×××××××××.com writes:
>
>   d> see catalyst snapshots model.  Specify whatever custom portage tree
>   d> you want to your hearts content.
>
> Catalyst is very interesting, but I feel that the chroot model, which is
> what Catalyst is based on, is fundamentally not the correct choice for
> cross-compilation setups.  As I mentioned in a previous message,
> requiring chroot means that you have to figure out a way to put hosted
> tools into your target image, including a complete host-based base
> operating system with glibc, shells, make, and an entire common command
> set since most makefiles invoke many different UNIX commands, and that's
> not even mentioning the actual cross-compiler itself.
>
> Using a chroot model is probably the most expedient way to handle
> creating an embedded filesystem FOR THE SAME ARCHITECTURE, but it's not
> flexible enough (IMO) to handle creating a completely general embedded
> system.
>

what's wrong with having the cross compiler in the chroot, and using
ROOT=/tmp/mergeroot to create a target embedded image ?

then specifying whatever packages you require in the spec file.  All
the native tools then get installed into /tmp/mergeroot.  That
directory is tar'd up or put into an ext2 or cramfs.

Maybe I'm misunderstanding your goals.... but in reviewing your old
emails.  I see a few basic requirements here(i'm paraphrasing your
emails):

1) produce and store gentoo system images(GSI's from now on ) on an
   already functioning system. Each with it's own unique portage
   tree separate from all others.

2) Each GSI has it's own self contained compilers, linkers, libc,
   system tools, etc.

3) Have the ability to specify a non-native architecture(CPU arch,
   libc, etc) for a GSI(non-native being that the 'functioning system'
   cannot run the binaries for the GSI natively)

4) Have the ability to arbitarily install or update packages on the
   GSI's.

5) Have the ability to create binary packages during the package
   compilation in the GSI's.

And in another email you mentioned you do not like chroot solutions
because they confuse you.  I agree that managing many chroots would
not be an easy task.  However with catalyst, a system for building
system images, the work is done for you.  One merely has to give
catalyst a file telling it what to build.  For example, a catalyst
file for a cross system would be the following:

subarch: ppc
version_stamp: cross-ppc
target: stage2
rel_type: default
rel_version: 2004.0
snapshot: custom-ppc-embedded-portage
source_subpath: default-x86-2004.0/stage1-x86-2004.0

catalyst would then do the following:

*) unpack the native(x86) stage1, chroot into it, and begin building a
 non-native stage1 with a x86->ppc cross enviornment

*) build additionally supplied cross packages(libraries for example)

*) tar up the cross system

then one can easily create a non-native full system:

subarch: ppc
version_stamp: native-ppc
target: stage2
rel_type: default
rel_version: 2004.0
snapshot: custom-ppc-embedded-portage
source_subpath: default-x86-2004.0/stage1-cross-ppc-2004.0

*) catalyst would unpack the cross stage1, chroot into it, and begin
 building ppc native binaries and producing a native system image

*) again, additionally building other libraries and executabesl
 specified in the spec file

*) tar up(or place in fs image) the resulting native GSI

It would seem to me, that a system such as this would satisfy all of
your requirements.

--
gentoo-dev@g.o mailing list