1 |
On Tue, 2005-11-22 at 22:36 +0100, Jakub Moc wrote: |
2 |
> 22.11.2005, 21:58:50, Chris Gianelloni wrote: |
3 |
> |
4 |
> >> That FAQ section has nothing in common with the original stage1 docs. Sorry, |
5 |
> >> installing stage3 to remove all the use flags cruft subsequently, bootstrap |
6 |
> >> and re-emerge the system and then ponder which packages are not needed any |
7 |
> >> more (again, there's no reliable tool to remove unneeded stuff from system, |
8 |
> >> I've already mentioned this once) - hmmm... :/ |
9 |
> |
10 |
> > No. That FAQ section is there to describe how to install from a stage1 |
11 |
> > or stage2 tarball and has nothing to do with a stage3 tarball, nor did I |
12 |
> > ever say that it would. I'm not sure I understand what you're getting |
13 |
> > at here. |
14 |
> |
15 |
> Uhm, do I really need to quote it here? |
16 |
|
17 |
Not really, but you're going to do it anyway. |
18 |
|
19 |
> <snip> |
20 |
> "How do I Install Gentoo Using a Stage1 or Stage2 Tarball? |
21 |
> |
22 |
> ... |
23 |
> |
24 |
> However, Gentoo still provides stage1 and stage2 tarballs. This is for |
25 |
> development purposes (the Release Engineering team starts from a stage1 tarball |
26 |
> to obtain a stage3) but shouldn't be used by users: a stage3 tarball can very |
27 |
> well be used to bootstrap the system." |
28 |
> </snip> |
29 |
> |
30 |
> Sorry, but that does not answer the original FAQ question at all... |
31 |
|
32 |
Umm... yeah. So you snip it RIGHT BEFORE THE INSTALL INSTRUCTIONS... |
33 |
Good show... *rolleyes* |
34 |
|
35 |
> The above does not describe a stage1 install, but a workaround procedure you've |
36 |
> invented because of your strong dislike of stage1 install. However much you |
37 |
> say the result is the same, it's not. E.g. - how exactly I get rid of those |
38 |
> unneeded packages once I've changed the use flags, bootstrapped and rebuilt the |
39 |
> system? Honestly, stage3 is something I don't find useful for a server install |
40 |
> because the default use flags are aimed at desktop systems. |
41 |
|
42 |
emerge -e world && emerge -e world && emerge depclean |
43 |
|
44 |
This was already answered for you. Your refusal to accept the answer, |
45 |
is not my problem. |
46 |
|
47 |
I'm tired of arguing with you. You refuse to listen to what I am |
48 |
saying. A properly maintained and built system will be identical to one |
49 |
built from a stage1 tarball. You cannot argue this point just because |
50 |
you do not personally know how to do it. I have already said that we |
51 |
are working on documenting the process for the users. This will be done |
52 |
well before we ever remove a stage1 or stage2 tarball from the mirrors. |
53 |
|
54 |
> Sure, I can use hardened stage3, compiled for i386 and enjoy the Debian |
55 |
> feeling. ;p |
56 |
|
57 |
You can do whatever you like. Nobody is forcing you to do anything. |
58 |
|
59 |
That being said, you are not going to force *me* to do anything, either. |
60 |
|
61 |
> > The whole point here is in what we want to support. |
62 |
> |
63 |
> So don't support it, but let it exist! |
64 |
|
65 |
Why? Why would I even bother distributing something that is not worth |
66 |
distributing? We don't want testing on them. We know they are broken. |
67 |
We don't want users using it. We know it is broken. What purpose is |
68 |
served by putting out something that we KNOW is broken and have no |
69 |
intentions on fixing due to it being broken BY DESIGN? |
70 |
|
71 |
> >> Why exactly is evaporating stage1 an ultimate goal here (as it seems to me?). |
72 |
> |
73 |
> > It's usefulness is far outweighed by the problems it causes, and it is |
74 |
> > really no longer necessary, nor has it been for over a year now. |
75 |
> |
76 |
> Uhm, I've seen quite a couple of examples in this debate why it is still |
77 |
> necessary and useful. |
78 |
|
79 |
No. You really haven't. You might think that you have, but you have |
80 |
not. We also are not advocating anything for either Hardened or |
81 |
Embedded. They are their own projects with their own Release Engineers |
82 |
and their own support infrastructure. If they want to support a stage1 |
83 |
tarball until the Sun explodes, I don't care. |
84 |
|
85 |
> >> So don't support it, but why it should not exist? |
86 |
> |
87 |
> > I'll explain this just once. If we release it, we are expected to |
88 |
> > support it. There are *tons* of examples of things we won't do because |
89 |
> > we don't want the headache of supporting it. Why should this be any |
90 |
> > different? |
91 |
> |
92 |
> sigh... You are not required to support it - exactly like you are not expected |
93 |
> or required to support gcc-4 and gcc-4.1 and you can mark any bugs about it as |
94 |
> INVALID (happens every day, quite frankly). |
95 |
|
96 |
Look. I don't care what you think I should do. I really don't. You |
97 |
can argue this point until you're blue in the face, but until I see you |
98 |
volunteering to do THE WORK you really have no say. This really is |
99 |
something that is an internal decision to Release Engineering. We have |
100 |
discussed it and we're in agreement here. Now, the one thing that I've |
101 |
not seen *anyone* here do is step up to help with any of this. Instead, |
102 |
all I see is flames, name calling, and other useless arguments. We |
103 |
decided that we do not want to put out unsupported, known broken, crap. |
104 |
|
105 |
Do you really not understand the fact that we are making an attempt to |
106 |
improve the quality of our distribution. We are trying to improve the |
107 |
end user experience. We have already seen that users are not following |
108 |
the documentation, as it is. The Handbook keeps growing in size and |
109 |
complexity, and there's no end in sight. All the while, the quality is |
110 |
going to shit because we crossed the line where we can feasibly test |
111 |
what we're producing a long, LONG time ago. You're more than welcome to |
112 |
argue this for as long as you want, but I am done. |
113 |
|
114 |
-- |
115 |
Chris Gianelloni |
116 |
Release Engineering - Strategic Lead |
117 |
x86 Architecture Team |
118 |
Games - Developer |
119 |
Gentoo Linux |