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