1 |
On Tue, 2005-11-22 at 12:03 -0600, Grant Goodyear wrote: |
2 |
> Chris Gianelloni wrote: [Tue Nov 22 2005, 09:15:27AM CST] |
3 |
> > > Well, if we could educate the users that stage2 tarballs are totally |
4 |
> > > pointless, and that running bootstrap.sh followed by emerge -e system |
5 |
> > > from a stage3 is pretty much *exactly* the same as starting a stage1 |
6 |
> > > from scratch... |
7 |
> > |
8 |
> > It isn't pretty much anymore. It *is* exactly the same. |
9 |
> |
10 |
> I keep hearing this, isn't there a real difference between a stage 1 and |
11 |
> a stage 3 install inasmuch as somebody who needs (or wants) to |
12 |
> dramatically tailor what's in the system profile can choose to do so |
13 |
> from a stage 1 or 2, but would have to remove packages after the fact if |
14 |
> starting from a stage 3? I wouldn't have a problem with that, as long |
15 |
> as we document it, but it just seems that the claim that the old and new |
16 |
> methods produce _exactly_ the same results seems to be stretching things |
17 |
> a bit. |
18 |
> |
19 |
> -g2boojum- |
20 |
|
21 |
There are 3 purposes to a stage1/stage2 install (note all 3 can be |
22 |
achieved with either a stage3 or a custom rolled stage though catalyst): |
23 |
|
24 |
1). Modify the bootstrap.sh script to change what the "stage2" target |
25 |
produces. |
26 |
2). Modify the system target to change what the "stage3" target |
27 |
produces. |
28 |
3). Modify the CHOST/CFLAGS/USE et. al. early on to create a customized |
29 |
and largely unsupported (things like hardened, uclibc, and embedded are |
30 |
exceptions to the unsupported rule) "stage3" target. |
31 |
|
32 |
#3 is where the vast majority of user created bugs occur. The purpose of |
33 |
highly encouraging users to start with a stage3, by making the handbook |
34 |
only refer to it, is to make sure that users have a known working |
35 |
configuration to start their customization from. There are many many |
36 |
ways to mess up going from a stage1 to a stage3, there are fewer ways to |
37 |
mess up customizing and recompiling a system that has already been |
38 |
configured to boot on it's own. |
39 |
|
40 |
By and large most users will never want to do any of the above for the |
41 |
reasons that they are really valid for, and any user or developer that |
42 |
does will have access to both the stages (with relocated documentation) |
43 |
and catalyst itself to make their own. We are not removing choice |
44 |
here...just *potentially* making someones initial download time longer. |
45 |
|
46 |
Personally I wouldn't be at all opposed to moving the stage1 and stage2 |
47 |
tarballs to another directory on the mirrors (documented of course), |
48 |
just to make it that much clearer that if you start from a stage1 or a |
49 |
stage2 RelEng won't support you if any errors occur during system build. |
50 |
|
51 |
If RelEng ever does get to the point of removing stage's 1 & 2 from the |
52 |
mirrors (something that has been discussed but isn't on the table at all |
53 |
right now) end users and developers alike will still be able to generate |
54 |
them on their own using catalyst and the provided spec files...sure it |
55 |
is an extra step and all but it's not all that huge... |
56 |
|
57 |
-- |
58 |
Daniel Ostrow |
59 |
Gentoo Foundation Board of Trustees |
60 |
Gentoo/{PPC,PPC64,DevRel} |
61 |
dostrow@g.o |
62 |
|
63 |
-- |
64 |
gentoo-dev@g.o mailing list |