| 1 |
On Mon, 2005-10-31 at 16:51 -0500, Michael Crute wrote: |
| 2 |
> On 10/31/05, Chris Gianelloni <wolf31o2@g.o> wrote: |
| 3 |
> As it stands, I only see a few options, none of which sound |
| 4 |
> very good: |
| 5 |
> |
| 6 |
> 1. Only release stage3 tarballs |
| 7 |
> |
| 8 |
> This is the worst of all these options. I for one have never done a |
| 9 |
> stage3 install and never plan/want to. I am pretty sure there are |
| 10 |
> others out there like me that would be extremely ticked off to see our |
| 11 |
> stage1 tarballs disappear. |
| 12 |
|
| 13 |
Honestly, no offense, but I don't care. |
| 14 |
|
| 15 |
You are wasting your time and don't even realize how badly you are doing |
| 16 |
it. Ever since we added full vdb support into the stages (2005.0) it is |
| 17 |
a complete waste of time to do a stage1 installation. Exactly what do |
| 18 |
you gain from doing a stage3, editing make.conf, then doing an emerge -e |
| 19 |
world? |
| 20 |
|
| 21 |
Now, think about this. When doing a stage1 installation, you have to |
| 22 |
bootstrap, which compiles a minimalized version of the toolchain. After |
| 23 |
this, you run an emerge -e world, which recompiles *all* of the |
| 24 |
toolchain, along with a ton more packages. So you are compiling the |
| 25 |
entire toolchain twice, the first time giving you no benefit, |
| 26 |
whatsoever, other than allowing you to enable a few options which can |
| 27 |
honestly be turned on at any time, such as nptl. |
| 28 |
|
| 29 |
What takes less time, compiling the entire toolchain from scratch, or |
| 30 |
unpacking a tarball? In either case, you're running an "emerge -e |
| 31 |
system" to get your customized system. |
| 32 |
|
| 33 |
> 2. Inform users that only stage3 will be supported |
| 34 |
> |
| 35 |
> This may actually be your best route. Any bugs that come in because |
| 36 |
> users customized use flags on a non-stage3 install should be closed |
| 37 |
> RTFM. |
| 38 |
|
| 39 |
This is honestly probably going to be the route we're forced into, even |
| 40 |
though it is not the optimal route for either the developers or the |
| 41 |
users, simply because of the stubbornness of many of our developers and |
| 42 |
vocal users that will refuse the dropping of stages 1 and 2 from our |
| 43 |
mirrors. I used to be one of these developers until I came in and |
| 44 |
modified the way catalyst worked when producing stages. |
| 45 |
|
| 46 |
Now both stages 1 and 2 are completely redundant. |
| 47 |
|
| 48 |
> 3. Change the documentation to recommend users not change USE |
| 49 |
> flags |
| 50 |
> until after the completion of "emerge -e system" |
| 51 |
> |
| 52 |
> You could try this first but if people think they are smart enough to |
| 53 |
> change the use flags (even if they really aren't) then there isn't |
| 54 |
> much of a chance you're going to talk them out of it. |
| 55 |
|
| 56 |
Except we would probably mark the bugs as INVALID. |
| 57 |
|
| 58 |
> I am not sure how the other (non-minimal) cd's are setup but you could |
| 59 |
> just include stage3's on the cds and make people go out to the mirrors |
| 60 |
> to get their stage1 or 2 tarballs. Basically make it a little bit more |
| 61 |
> difficult to get them. |
| 62 |
|
| 63 |
We currently only ship the stage3 tarballs on the Universal InstallCD. |
| 64 |
|
| 65 |
> Another thought would be an approach similar to the installer irc |
| 66 |
> channel where you have to read through a really long FAQ before you |
| 67 |
> are told how to download the stage1 or 2 tarballs. |
| 68 |
|
| 69 |
My personal impression is that this will piss off the end user. This |
| 70 |
works for the installer *channel* but would never work for a CD |
| 71 |
installation. It's simply asinine to ask the user to jump through hoops |
| 72 |
to do what they want. |
| 73 |
|
| 74 |
Even if we stopped shipping stage1 tarballs, there's nothing stopping |
| 75 |
some inventive user from grabbing a stage3 tarball and making a stage1 |
| 76 |
tarball from it using catalyst. It only takes a couple hours on a |
| 77 |
decent machine. |
| 78 |
|
| 79 |
My point is that once again, we're not *really* removing choice even if |
| 80 |
we were to drop the earlier stages altogether, we're just making the |
| 81 |
user do the work themselves and removing one more abysmal headache and |
| 82 |
QA nightmare from our already enormous and growing list of stuff that |
| 83 |
has been delaying the past few releases well beyond our scheduled |
| 84 |
release dates. |
| 85 |
|
| 86 |
> Just my thoughts as an end user. |
| 87 |
|
| 88 |
They're appreciated. |
| 89 |
|
| 90 |
Thanks. |
| 91 |
|
| 92 |
-- |
| 93 |
Chris Gianelloni |
| 94 |
Release Engineering - Strategic Lead |
| 95 |
x86 Architecture Team |
| 96 |
Games - Developer |
| 97 |
Gentoo Linux |
Archives