[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] BUILDROOT concept (was Re: [gentoo-dev] ROOT variable)
From:       "Paul Smith" <pausmith () nortelnetworks ! com>
Date:       2004-04-26 21:13:42
Message-ID: vpdrisfma1dl.fsf () lemming ! engeast ! baynetworks ! com
[Download RAW message or body]

%% david@futuretel.com writes:

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

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

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

Close... actually most of my images don't have any compilers or linkers.
I create one image that has all the "cross" stuff in it, then build
other images from that.  The nice thing about that one image is I can
use "emerge inject" to "fake out" all the applications that I don't care
about (who cares what version of "ls" or "mkdir" you use?) without
having to waste time building and installing them.

But, I can use a stage1 image where these things are already built.

The rest is correct.

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

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

It's not clear to me from the Catalyst Reference Manual how one manages
packages in a GSI... I guess you'd have to chroot back into the "host"
GSI, set your ROOT to the non-native GSI, and run your ebuild and emerge
commands from there?

Also something would need to be done about sharing the distfiles
directory: it would be a drag to have to have a separate one for each
"host" GSI.

Catalyst seems directed at creating "end user" product, like CDs, etc.
I need to be sure that we have something that is just as easy to use
during normal development of new packages, etc. as the "normal" Gentoo
command set, insofar as that's possible.

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

  d> And in another email you mentioned you do not like chroot solutions
  d> because they confuse you.

Heh.  It's not me I'm worried about: I've been dealing with building and
deploying cross-compilers and cross-compiled environments for 15+
years... you think building GCC as a cross-compiler is tricky now, you
should have tried it back in the GCC 1.x days :).

But, I'm not going to be the one making all these images: they need to
be buildable and customizable by someone without that experience.
Obviously I'm willing to script an environment to make that
straightforward, if possible.

And, I'll need to deal with the requirement for root privileges to
invoke the chroot.

I'll take a look at the configuration you suggest for Catalyst; thanks
for the info!

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <psmith@nortelnetworks.com>   HASMAT--HA Software Mthds & Tools
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.

--
gentoo-dev@gentoo.org mailing list

[prev in list] [next in list] [prev in thread] [next in thread]