Re: [gentoo-doc] Suggestion regarding compile order when emerging system

[George Hedfors]

I understand guys and I think you are doing a great job. I've
personally used Linux since the end of 1994, started off with
Slackware but during the later years been using various dists of BSD
instead. However, I recently found the joy in Gentoo and have now been
using it for the last 6 months on a number of servers and other
machines. Just want to give my input and i really appreciate the
response I've been given here. Keep up the good work guys!

On 5/11/06, Chris Gianelloni <wolf31o2@g.o> wrote:
> On Thu, 2006-05-11 at 19:39 +0200, George Hedfors wrote:
> > Well no, but I did this change before doing the actual bootstrap. I
> > followed the quick install guide and made changes to make.conf, then
> > completed bootstrap.sh and started emerging the system. Thats when it
> > happend. As there is a stage-installed perl version, when the library
> > tried to compile, it used the present perl version as it was dependent
> > on it. However, as the stage-installed version did'nt work with my
> > changes, i had to manually upgrade perl before i could emerge the rest
> > of the system. I'm sure other people will have the same problem and to
> > solve this, one way would be to reinstall perl somewhere in the very
> > beguinning of emerge system.
> >
> > I'm just a stupid user trying to make life easier for others :).
>
> While I understand and we truly do appreciate the input, this is
> *exactly* why Release Engineering has dropped support for stage1 and
> stage2 installs and recommend to everyone to use the stage3 tarballs for
> *all* installations.
>
> The stage3 tarball is a known-good minimal working system.
>
> There are simply too many variables possible in doing a stage1 or stage2
> installation that need to be addressed.  I honestly should change the
> end bootstrap.sh message to tell the user that if something breaks, they
> get to pick up the pieces themselves. ;]
>
> Gentoo has, unfortunately, become a victim of its own success.  The more
> flexibility we add to the system, the harder it is to test for multiple
> scenarios that are possible when doing an installation.  For some time
> now, it has been simply impossible for us to test stage1 and stage2
> installations with any degree of certainty that what builds on my
> machine will build on yours.  There's simply too many USE flags
> affecting the "system" target.  Also, most people don't realize that
> "system" is 100% contrived by portage from the profile and its own
> internal dependency calculations.  We simply can't make something appear
> sooner in the dependency tree than it already does, without editing the
> ebuilds, which almost always has unforseen consequences, causing a
> back-out.
>
> Trust me.  This is exactly what takes us so long during releases to get
> going.  It usually takes us a few weeks just to get the stages to build
> properly, due to changes that have happened in the tree since the last
> release.
>
> If you want an installation that actually *works*, use a stage3 tarball.
> If you're familiar with the concepts of bootstrapping and are
> comfortable with cleaning up after portage vomiting all over your system
> because of something that changed in the time since release and you
> doing your installation, feel free to use the lower stages.  Personally,
> I *always* use a stage3 installation now.  Most of the time, I use GRP.
> I hate waiting to get a usable system.  I'd much rather be checking my
> email and letting a compile go on in the background than stare at a
> console of scrolling text and not be able to do much but ssh to another
> box or chat on IRC for days.
>
> --
> Chris Gianelloni
> Release Engineering - Strategic Lead
> x86 Architecture Team
> Games - Developer
> Gentoo Linux
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
>
> iD8DBQBEY6cikT4lNIS36YERAny5AJ4+UusF/DLMqrXE89+weO553GwOAACffEM2
> ys4evBo0BhI1p4xKSq0mH8c=
> =XEFZ
> -----END PGP SIGNATURE-----
>
>
>


-- 
PGP Fingerprint:
4BB9 7A99 3DB5 52AA 8CEF  4DFB 32F2 41AC 0EF2 D595

-- 
gentoo-doc@g.o mailing list