Re: [gentoo-dev] Re: bootstrapping since gcc 3.4 is stable

[Mikey <mikey@badpenguins.com>]

[-- Attachment #1: Type: text/plain, Size: 2429 bytes --]

On Wednesday 25 January 2006 20:40, Sven Köhler wrote:

> Mike is telling me, that the 2006.0 tarballs will contain gcc-3.4.
> Then he's telling me, that the problem, that Im trying to point out, is
> going to vanish with the release of the 2006.0 tarballs. Well, yes,
> until the next gcc-slot becomes stable. So the problem is not fixed,
> just moved to the future again.

> Actually I'm told, that there's no automatic mechanism to get a "clean"
> gentoo system. So i'm told, that i have to take a stage3 tarball, and
> upgrade it to a clean system.

> If i follow that advice, i have to upgrade glibc, gcc, python and
> perhaps many more, clean the system from packages in old slots, and then
> run an "emerge -e world" (which compiles glibc, gcc, python again).
>
> Pretty much work for a beginnner!
> And there's pretty much of experience needed.

Wow, a voice of reason.  That is exactly what I am saying.  Gentoo is unique 
because it it a moving target.  The further in time you move away from an 
official stage3, the worst a stage3 installation method gets.  In fact it 
turns into a outright nightmare.  How long since the last up to date stage 
tarballs?

Solutions?

Release stage tarballs monthly.  If that can't be done, make fixing the 
process so it can be done a priority.

For toolchain updates, a slightly modified bootstrap.sh that builds the 
toolchain in the correct order and whatever is needed to bootstrap portage 
afterwards would be a better approach.  Fix the STAGE1_USE bug, comment out 
CONFIG_PROTECT="-*" and FEATURES="-collision-protect" and you have a 
perfectly reliable method to update the toolchain that takes half the time, 
even on a running system.  This would certainly be more realistic than 
gutting portage so that it installs toolchain packages in the correct order 
so that emerge -e system && emerge -e world is not needed.  Get rid of 
circular dependencies in portage so it can be portable.  Embed its own 
python version so it does not depend on packages with circular 
dependencies.  Do I know absolutely that any of these ideas will work?  
Hell no, but I do know the current installation method sucks depending on 
what time of the year it is, and the answer is not to entrench further in 
an unreliable process.

If nothing else, stop treating users like idiots when they are not, at least 
not all of them, all of the time.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]