On Mon, 2005-10-31 at 16:51 -0500, Michael Crute wrote: > On 10/31/05, Chris Gianelloni <[EMAIL PROTECTED]> wrote: > As it stands, I only see a few options, none of which sound > very good: > > 1. Only release stage3 tarballs > > This is the worst of all these options. I for one have never done a > stage3 install and never plan/want to. I am pretty sure there are > others out there like me that would be extremely ticked off to see our > stage1 tarballs disappear.
Honestly, no offense, but I don't care. You are wasting your time and don't even realize how badly you are doing it. Ever since we added full vdb support into the stages (2005.0) it is a complete waste of time to do a stage1 installation. Exactly what do you gain from doing a stage3, editing make.conf, then doing an emerge -e world? Now, think about this. When doing a stage1 installation, you have to bootstrap, which compiles a minimalized version of the toolchain. After this, you run an emerge -e world, which recompiles *all* of the toolchain, along with a ton more packages. So you are compiling the entire toolchain twice, the first time giving you no benefit, whatsoever, other than allowing you to enable a few options which can honestly be turned on at any time, such as nptl. What takes less time, compiling the entire toolchain from scratch, or unpacking a tarball? In either case, you're running an "emerge -e system" to get your customized system. > 2. Inform users that only stage3 will be supported > > This may actually be your best route. Any bugs that come in because > users customized use flags on a non-stage3 install should be closed > RTFM. This is honestly probably going to be the route we're forced into, even though it is not the optimal route for either the developers or the users, simply because of the stubbornness of many of our developers and vocal users that will refuse the dropping of stages 1 and 2 from our mirrors. I used to be one of these developers until I came in and modified the way catalyst worked when producing stages. Now both stages 1 and 2 are completely redundant. > 3. Change the documentation to recommend users not change USE > flags > until after the completion of "emerge -e system" > > You could try this first but if people think they are smart enough to > change the use flags (even if they really aren't) then there isn't > much of a chance you're going to talk them out of it. Except we would probably mark the bugs as INVALID. > I am not sure how the other (non-minimal) cd's are setup but you could > just include stage3's on the cds and make people go out to the mirrors > to get their stage1 or 2 tarballs. Basically make it a little bit more > difficult to get them. We currently only ship the stage3 tarballs on the Universal InstallCD. > Another thought would be an approach similar to the installer irc > channel where you have to read through a really long FAQ before you > are told how to download the stage1 or 2 tarballs. My personal impression is that this will piss off the end user. This works for the installer *channel* but would never work for a CD installation. It's simply asinine to ask the user to jump through hoops to do what they want. Even if we stopped shipping stage1 tarballs, there's nothing stopping some inventive user from grabbing a stage3 tarball and making a stage1 tarball from it using catalyst. It only takes a couple hours on a decent machine. My point is that once again, we're not *really* removing choice even if we were to drop the earlier stages altogether, we're just making the user do the work themselves and removing one more abysmal headache and QA nightmare from our already enormous and growing list of stuff that has been delaying the past few releases well beyond our scheduled release dates. > Just my thoughts as an end user. They're appreciated. Thanks. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux
signature.asc
Description: This is a digitally signed message part
