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
pgpJVJFKWnV1D.pgp
Description: PGP signature
