| 1 |
On Thu, 2006-05-11 at 19:39 +0200, George Hedfors wrote: |
| 2 |
> Well no, but I did this change before doing the actual bootstrap. I |
| 3 |
> followed the quick install guide and made changes to make.conf, then |
| 4 |
> completed bootstrap.sh and started emerging the system. Thats when it |
| 5 |
> happend. As there is a stage-installed perl version, when the library |
| 6 |
> tried to compile, it used the present perl version as it was dependent |
| 7 |
> on it. However, as the stage-installed version did'nt work with my |
| 8 |
> changes, i had to manually upgrade perl before i could emerge the rest |
| 9 |
> of the system. I'm sure other people will have the same problem and to |
| 10 |
> solve this, one way would be to reinstall perl somewhere in the very |
| 11 |
> beguinning of emerge system. |
| 12 |
> |
| 13 |
> I'm just a stupid user trying to make life easier for others :). |
| 14 |
|
| 15 |
While I understand and we truly do appreciate the input, this is |
| 16 |
*exactly* why Release Engineering has dropped support for stage1 and |
| 17 |
stage2 installs and recommend to everyone to use the stage3 tarballs for |
| 18 |
*all* installations. |
| 19 |
|
| 20 |
The stage3 tarball is a known-good minimal working system. |
| 21 |
|
| 22 |
There are simply too many variables possible in doing a stage1 or stage2 |
| 23 |
installation that need to be addressed. I honestly should change the |
| 24 |
end bootstrap.sh message to tell the user that if something breaks, they |
| 25 |
get to pick up the pieces themselves. ;] |
| 26 |
|
| 27 |
Gentoo has, unfortunately, become a victim of its own success. The more |
| 28 |
flexibility we add to the system, the harder it is to test for multiple |
| 29 |
scenarios that are possible when doing an installation. For some time |
| 30 |
now, it has been simply impossible for us to test stage1 and stage2 |
| 31 |
installations with any degree of certainty that what builds on my |
| 32 |
machine will build on yours. There's simply too many USE flags |
| 33 |
affecting the "system" target. Also, most people don't realize that |
| 34 |
"system" is 100% contrived by portage from the profile and its own |
| 35 |
internal dependency calculations. We simply can't make something appear |
| 36 |
sooner in the dependency tree than it already does, without editing the |
| 37 |
ebuilds, which almost always has unforseen consequences, causing a |
| 38 |
back-out. |
| 39 |
|
| 40 |
Trust me. This is exactly what takes us so long during releases to get |
| 41 |
going. It usually takes us a few weeks just to get the stages to build |
| 42 |
properly, due to changes that have happened in the tree since the last |
| 43 |
release. |
| 44 |
|
| 45 |
If you want an installation that actually *works*, use a stage3 tarball. |
| 46 |
If you're familiar with the concepts of bootstrapping and are |
| 47 |
comfortable with cleaning up after portage vomiting all over your system |
| 48 |
because of something that changed in the time since release and you |
| 49 |
doing your installation, feel free to use the lower stages. Personally, |
| 50 |
I *always* use a stage3 installation now. Most of the time, I use GRP. |
| 51 |
I hate waiting to get a usable system. I'd much rather be checking my |
| 52 |
email and letting a compile go on in the background than stare at a |
| 53 |
console of scrolling text and not be able to do much but ssh to another |
| 54 |
box or chat on IRC for days. |
| 55 |
|
| 56 |
-- |
| 57 |
Chris Gianelloni |
| 58 |
Release Engineering - Strategic Lead |
| 59 |
x86 Architecture Team |
| 60 |
Games - Developer |
| 61 |
Gentoo Linux |
Archives