| 1 |
On Wednesday 14 December 2005 09:03, Chris Gianelloni spammed: |
| 2 |
|
| 3 |
> Using a seed with only python 2.4 is the proper solution. If you do not |
| 4 |
> have such a seed, build a stage4 tarball with only python in it with |
| 5 |
> your new snapshot. You can use a 2005.1-r1 stage3 as your seed. Have |
| 6 |
> the stage4 run python-updater in your fsscript. You can then use this |
| 7 |
> updated stage4 as your seed for building stage1. |
| 8 |
|
| 9 |
Python will be automatically upgraded at stage3, which means that catalyst |
| 10 |
is creating a stage3 with both versions of python. Actually both versions |
| 11 |
of anything that might be slotted during that build of the stage3 target. |
| 12 |
Call me anal but that seems to be a rather poor state to leave it in. |
| 13 |
Regardless, the functionality provided by the stage4 fsscript is a |
| 14 |
workaround... |
| 15 |
|
| 16 |
Perhaps I am wanting catalyst to do something that it is not intended to |
| 17 |
do, maybe you can clarify for me. |
| 18 |
|
| 19 |
I want to be able to create clean, pristine, generic x86 stage1s with the |
| 20 |
current toolchain to use as my seed for subsequent builds. From mistakes I |
| 21 |
have been making and what you have been telling me, I am going to assume |
| 22 |
the following is the correct way to do this? |
| 23 |
|
| 24 |
Create a stage1 seed to use for future stage2s |
| 25 |
|
| 26 |
1) Use an unaltered stage1-x86-2005.0-r1.tar.bz2 from gentoo with a generic |
| 27 |
spec file, no changes in anything, only specify the source and snapshot, to |
| 28 |
create a stage2. This will create a stage2 with the current gcc, binutils, |
| 29 |
glibc, etc... |
| 30 |
|
| 31 |
2) Use the resulting stage2, with no customizations, to create a stage3. |
| 32 |
|
| 33 |
3) Use the resulting stage3 to create a new stage1, which would now contain |
| 34 |
the updated toolchain. |
| 35 |
|
| 36 |
Use my new stage1 to create my customized stage2/3s |
| 37 |
|
| 38 |
1) Use the stage1 seed created above, create spec file for stage2 with my |
| 39 |
cflags, chost, cxxflags, and (where do use flags fit in)? |
| 40 |
|
| 41 |
2) Use the new stage2 to create a stage3, I am assuming the cflags, chost, |
| 42 |
cxxflags, and use flags will migrate from the stage2 via the |
| 43 |
catalyst-generated make.conf and need no alteration? |
| 44 |
|
| 45 |
I am a little confused about where my USE preferences need to be applied and |
| 46 |
how they migrate from stage2 -> stage3 -> stage4. Would they go in the |
| 47 |
stage2 spec file with stage2/use, or a env script, or would I need to hand |
| 48 |
edit the stage2 make.conf before using it? Afterwards, will I ever need to |
| 49 |
change the USE flags again for that particular release? |
Archives