| 1 |
On Wed, 2006-01-25 at 18:02 -0600, MIkey wrote: |
| 2 |
> Jan Kundrát wrote: |
| 3 |
> |
| 4 |
> > "What is most interesting to me about this discussion is the fact than |
| 5 |
> > no one has bothered to offer any facts to back up these assertions." -- |
| 6 |
> > author should read any of the wolf31o2's mails about this subject. |
| 7 |
> |
| 8 |
> I _have_ read his "mails" about it, had several exchanges with him on the |
| 9 |
> topic myself. As a matter of fact if you read the "FUD" you might note |
| 10 |
> some of his quotes are the reasons I ran the tests in the first place. |
| 11 |
> Frankly, I believe he is wrong, and I explained why. |
| 12 |
|
| 13 |
You didn't follow the Handbook. Your comments about compiling GCC 3 |
| 14 |
times are completely unbased, since you ran not only an "emerge -e |
| 15 |
system" (which is recommended) but then immediately, and needlessly, |
| 16 |
followed it up with an "emerge -e world" which pretty much blew any |
| 17 |
results that you had gained out of the water. |
| 18 |
|
| 19 |
> The FUD is that stage3 is a better installation process than a (corrected) |
| 20 |
> stage1. The facts are right there in what I posted. Stage3's take twice |
| 21 |
> as long rebuilding the same number of packages and introduce a plethora of |
| 22 |
> roadblocks in the build process unless you stay on a very narrow path. How |
| 23 |
> any "developer" can claim that this is a quicker, cleaner, or easier |
| 24 |
> process to support is beyond me. Maybe in bizarro world. |
| 25 |
|
| 26 |
There are no "facts" in what you posted. In fact, it looks as if your |
| 27 |
designs were tailored to find a way in which you could get a stage3 to |
| 28 |
be slower. If you're willing, I will work on the scripts to produce |
| 29 |
*accurate* results for stages 1 and 3. Essentially, your data was |
| 30 |
worthless since you didn't follow any prescribed way of using a stage3 |
| 31 |
tarball, nor did you anywhere cite where you came up with your |
| 32 |
procedures. |
| 33 |
|
| 34 |
> I will stick to the facts myself, thank you very much. I invite you to |
| 35 |
> actually read the reports I generated and tell where my conclusions are |
| 36 |
> wrong. If you can't do that, you are fudding yourself. |
| 37 |
|
| 38 |
I just did. You can stick with your "facts" all that you want, but |
| 39 |
they're incorrect. |
| 40 |
|
| 41 |
Here's a simple pseudo-formula to determine just how off you were: |
| 42 |
|
| 43 |
(Yes, this is simplified slightly) |
| 44 |
|
| 45 |
stage1 == tarball + toolchain (bootstrap) + system |
| 46 |
stage3 == tarball + system + depclean |
| 47 |
|
| 48 |
I'm sorry, but I cannot possibly believe that compiling the toolchain + |
| 49 |
the system target takes less time than only compiling system and |
| 50 |
summarily removing unused packages. This, by the way, would have |
| 51 |
avoided the issues that you were having with things like "ls" being |
| 52 |
broken. |
| 53 |
|
| 54 |
-- |
| 55 |
Chris Gianelloni |
| 56 |
Release Engineering - Strategic Lead |
| 57 |
x86 Architecture Team |
| 58 |
Games - Developer |
| 59 |
Gentoo Linux |
Archives