Re[4]: [gentoo-dev] Decision to remove stage1/2 from installation documentation

[Jakub Moc]

22.11.2005, 21:58:50, Chris Gianelloni wrote:

>> That FAQ section has nothing in common with the original stage1 docs. Sorry,
>> installing stage3 to remove all the use flags cruft subsequently, bootstrap
>> and re-emerge the system and then ponder which packages are not needed any
>> more (again, there's no reliable tool to remove unneeded stuff from system,
>> I've already mentioned this once) - hmmm... :/

> No.  That FAQ section is there to describe how to install from a stage1
> or stage2 tarball and has nothing to do with a stage3 tarball, nor did I
> ever say that it would.  I'm not sure I understand what you're getting
> at here.

Uhm, do I really need to quote it here?

<snip>
"How do I Install Gentoo Using a Stage1 or Stage2 Tarball?

...

However, Gentoo still provides stage1 and stage2 tarballs. This is for
development purposes (the Release Engineering team starts from a stage1 tarball
to obtain a stage3) but shouldn't be used by users: a stage3 tarball can very
well be used to bootstrap the system."
</snip>

Sorry, but that does not answer the original FAQ question at all...
The above does not describe a stage1 install, but a workaround procedure you've
invented because of your strong dislike of stage1 install. However much you
say the result is the same, it's not. E.g. - how exactly I get rid of those
unneeded packages once I've changed the use flags, bootstrapped and rebuilt the
system? Honestly, stage3 is something I don't find useful for a server install
because the default use flags are aimed at desktop systems.

Sure, I can use hardened stage3, compiled for i386 and enjoy the Debian
feeling. ;p

> The whole point here is in what we want to support.

So don't support it, but let it exist!

>> Why exactly is evaporating stage1 an ultimate goal here (as it seems to me?).

> It's usefulness is far outweighed by the problems it causes, and it is
> really no longer necessary, nor has it been for over a year now.

Uhm, I've seen quite a couple of examples in this debate why it is still
necessary and useful.

>> So don't support it, but why it should not exist?

> I'll explain this just once.  If we release it, we are expected to
> support it.  There are *tons* of examples of things we won't do because
> we don't want the headache of supporting it.  Why should this be any
> different?

sigh... You are not required to support it - exactly like you are not expected
or required to support gcc-4 and gcc-4.1 and you can mark any bugs about it as
INVALID (happens every day, quite frankly).


-- 

jakub