| 1 |
On Wednesday 25 January 2006 20:40, Sven Köhler wrote: |
| 2 |
|
| 3 |
> Mike is telling me, that the 2006.0 tarballs will contain gcc-3.4. |
| 4 |
> Then he's telling me, that the problem, that Im trying to point out, is |
| 5 |
> going to vanish with the release of the 2006.0 tarballs. Well, yes, |
| 6 |
> until the next gcc-slot becomes stable. So the problem is not fixed, |
| 7 |
> just moved to the future again. |
| 8 |
|
| 9 |
> Actually I'm told, that there's no automatic mechanism to get a "clean" |
| 10 |
> gentoo system. So i'm told, that i have to take a stage3 tarball, and |
| 11 |
> upgrade it to a clean system. |
| 12 |
|
| 13 |
> If i follow that advice, i have to upgrade glibc, gcc, python and |
| 14 |
> perhaps many more, clean the system from packages in old slots, and then |
| 15 |
> run an "emerge -e world" (which compiles glibc, gcc, python again). |
| 16 |
> |
| 17 |
> Pretty much work for a beginnner! |
| 18 |
> And there's pretty much of experience needed. |
| 19 |
|
| 20 |
Wow, a voice of reason. That is exactly what I am saying. Gentoo is unique |
| 21 |
because it it a moving target. The further in time you move away from an |
| 22 |
official stage3, the worst a stage3 installation method gets. In fact it |
| 23 |
turns into a outright nightmare. How long since the last up to date stage |
| 24 |
tarballs? |
| 25 |
|
| 26 |
Solutions? |
| 27 |
|
| 28 |
Release stage tarballs monthly. If that can't be done, make fixing the |
| 29 |
process so it can be done a priority. |
| 30 |
|
| 31 |
For toolchain updates, a slightly modified bootstrap.sh that builds the |
| 32 |
toolchain in the correct order and whatever is needed to bootstrap portage |
| 33 |
afterwards would be a better approach. Fix the STAGE1_USE bug, comment out |
| 34 |
CONFIG_PROTECT="-*" and FEATURES="-collision-protect" and you have a |
| 35 |
perfectly reliable method to update the toolchain that takes half the time, |
| 36 |
even on a running system. This would certainly be more realistic than |
| 37 |
gutting portage so that it installs toolchain packages in the correct order |
| 38 |
so that emerge -e system && emerge -e world is not needed. Get rid of |
| 39 |
circular dependencies in portage so it can be portable. Embed its own |
| 40 |
python version so it does not depend on packages with circular |
| 41 |
dependencies. Do I know absolutely that any of these ideas will work? |
| 42 |
Hell no, but I do know the current installation method sucks depending on |
| 43 |
what time of the year it is, and the answer is not to entrench further in |
| 44 |
an unreliable process. |
| 45 |
|
| 46 |
If nothing else, stop treating users like idiots when they are not, at least |
| 47 |
not all of them, all of the time. |
Archives