| 1 |
%% david@×××××××××.com writes: |
| 2 |
|
| 3 |
d> Maybe I'm misunderstanding your goals.... but in reviewing your old |
| 4 |
d> emails. I see a few basic requirements here(i'm paraphrasing your |
| 5 |
d> emails): |
| 6 |
|
| 7 |
d> 1) produce and store gentoo system images(GSI's from now on ) on an |
| 8 |
d> already functioning system. Each with it's own unique portage |
| 9 |
d> tree separate from all others. |
| 10 |
|
| 11 |
d> 2) Each GSI has it's own self contained compilers, linkers, libc, |
| 12 |
d> system tools, etc. |
| 13 |
|
| 14 |
Close... actually most of my images don't have any compilers or linkers. |
| 15 |
I create one image that has all the "cross" stuff in it, then build |
| 16 |
other images from that. The nice thing about that one image is I can |
| 17 |
use "emerge inject" to "fake out" all the applications that I don't care |
| 18 |
about (who cares what version of "ls" or "mkdir" you use?) without |
| 19 |
having to waste time building and installing them. |
| 20 |
|
| 21 |
But, I can use a stage1 image where these things are already built. |
| 22 |
|
| 23 |
The rest is correct. |
| 24 |
|
| 25 |
d> 3) Have the ability to specify a non-native architecture(CPU arch, |
| 26 |
d> libc, etc) for a GSI(non-native being that the 'functioning system' |
| 27 |
d> cannot run the binaries for the GSI natively) |
| 28 |
|
| 29 |
d> 4) Have the ability to arbitarily install or update packages on the |
| 30 |
d> GSI's. |
| 31 |
|
| 32 |
It's not clear to me from the Catalyst Reference Manual how one manages |
| 33 |
packages in a GSI... I guess you'd have to chroot back into the "host" |
| 34 |
GSI, set your ROOT to the non-native GSI, and run your ebuild and emerge |
| 35 |
commands from there? |
| 36 |
|
| 37 |
Also something would need to be done about sharing the distfiles |
| 38 |
directory: it would be a drag to have to have a separate one for each |
| 39 |
"host" GSI. |
| 40 |
|
| 41 |
Catalyst seems directed at creating "end user" product, like CDs, etc. |
| 42 |
I need to be sure that we have something that is just as easy to use |
| 43 |
during normal development of new packages, etc. as the "normal" Gentoo |
| 44 |
command set, insofar as that's possible. |
| 45 |
|
| 46 |
d> 5) Have the ability to create binary packages during the package |
| 47 |
d> compilation in the GSI's. |
| 48 |
|
| 49 |
d> And in another email you mentioned you do not like chroot solutions |
| 50 |
d> because they confuse you. |
| 51 |
|
| 52 |
Heh. It's not me I'm worried about: I've been dealing with building and |
| 53 |
deploying cross-compilers and cross-compiled environments for 15+ |
| 54 |
years... you think building GCC as a cross-compiler is tricky now, you |
| 55 |
should have tried it back in the GCC 1.x days :). |
| 56 |
|
| 57 |
But, I'm not going to be the one making all these images: they need to |
| 58 |
be buildable and customizable by someone without that experience. |
| 59 |
Obviously I'm willing to script an environment to make that |
| 60 |
straightforward, if possible. |
| 61 |
|
| 62 |
And, I'll need to deal with the requirement for root privileges to |
| 63 |
invoke the chroot. |
| 64 |
|
| 65 |
I'll take a look at the configuration you suggest for Catalyst; thanks |
| 66 |
for the info! |
| 67 |
|
| 68 |
-- |
| 69 |
------------------------------------------------------------------------------- |
| 70 |
Paul D. Smith <psmith@××××××××××××××.com> HASMAT--HA Software Mthds & Tools |
| 71 |
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist |
| 72 |
------------------------------------------------------------------------------- |
| 73 |
These are my opinions---Nortel Networks takes no responsibility for them. |
| 74 |
|
| 75 |
-- |
| 76 |
gentoo-dev@g.o mailing list |
Archives