From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.50) id 1Eed0Y-0006rZ-CT for garchives@archives.gentoo.org; Tue, 22 Nov 2005 18:36:46 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jAMIa23M021386; Tue, 22 Nov 2005 18:36:02 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id jAMIY9se014014 for ; Tue, 22 Nov 2005 18:34:09 GMT Received: from [65.115.53.39] (helo=[192.168.10.54]) by smtp.gentoo.org with esmtpa (Exim 4.43) id 1Eecy1-0004gA-Bi for gentoo-dev@lists.gentoo.org; Tue, 22 Nov 2005 18:34:09 +0000 Subject: Re: [gentoo-dev] Decision to remove stage1/2 from installation documentation From: Daniel Ostrow To: gentoo-dev@lists.gentoo.org In-Reply-To: <20051122180349.GC16984@bmb24.uth.tmc.edu> References: <20051122144745.GR12982@mail.lieber.org> <438330E1.2000804@gentoo.org> <1132672527.27288.21.camel@cgianelloni.nuvox.net> <20051122180349.GC16984@bmb24.uth.tmc.edu> Content-Type: text/plain Organization: The Gentoo Foundation Date: Tue, 22 Nov 2005 13:29:40 -0500 Message-Id: <1132684181.7872.27.camel@Memoria.anyarch.net> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-Archives-Salt: 301c8d26-6694-4ff1-9afe-14f34322f199 X-Archives-Hash: 556e8eae31310e0fae6a501e845c8af7 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} dostrow@gentoo.org -- gentoo-dev@gentoo.org mailing list