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 |