[gentoo-amd64] Re: Re: Advice Wanted! Setup Instuctions ...

[Duncan]

"Christopher E" <sensory.access@×××××.com> posted
184c54640605200819k795c6e4dma6bf1fc302f66c2e@××××××××××.com, excerpted
below, on  Sat, 20 May 2006 11:19:18 -0400:

> Hello Ducan,
>
>> I've only done the initial stage-1 setup, and now they recommend
>> starting from stage three and just doing an emerge --emptytree, so I
>> don't have much of use to say in that or the other areas.
>
> Do you have any stuff I can read about  using a stage three and doing a
> emerge --emptytree, and why one would do such?

The newer editions of the handbook cover it in some detail, but  I was
lurking on the dev list when it was discussed there, so I can give a bit
more developer side viewpoint.  Boyd SS Jr.  also has some very good
points, so grab them too.  (That's  what's great about lists/groups, often
you get several posts, each from slightly different viewpoints, and get to
pick and choose the explanations and try the solutions first that fit
yourr style. =8^)

Basically what's happened  is that with all the packages and platforms and
all the customization possible with Gentoo now, it's simply no longer
possible to test all the permutations and corner-cases of building from a
stage-1.  Too often, some of those corner cases fail to work, and people
trying to install Gentoo are left frustrated when they run into first one
problem and then another.

The stage-3 approach, which is what the handbook strongly recommends now,
starts with far more of the system initially compiled.  You then do an
emerge --empty-tree system once you've set up your CFLAGS and the like the
way you want them, and portage recompiles everything the way you want it. 
Done right, it's a far easier way to end up with the same customized
system you'd have otherwise, and since the packages in the stage-three are
all tested to work as they exist in the stage-three, it's far harder to
break and there are far fewer corner cases for folks to run into.

There are a few drawbacks, however.  As BSSJ mentions, it's a bit more
difficult to change CHOST, among other things.  However, with amd64 we are
lucky as there's really not much reason for us /to/ change CHOST.   The
other one that's big here, is that I not only started from stage-one, but
due to those  memory issues I mentioned in the reply to BSSJ, I actually
had to take apart bootstrap.sh and execute each step manually, one at a
time.  As a result, I know rather more about what makes a Linux system tick
than I would have otherwise.  Folks that do a stage-three simply aren't
going to be forced to get as up close and personal with their systems as
those choosing a stage-one and persevering thru all the corner-cases to
find solutions.  It'll be far faster and far easier, but they'll not know
as much about their system when they are done, and in some ways, that's a
shame.  It actually took me three months to get the system up and running
(I was dual booting Mandrake at the time, so it wasn't as if the system
was entirely dead for three months), due to the hardware and some software
problems I ran into, back on 2004.0 and 2004.1 when I first installed
Linux, but I'm glad I did it that way, as I know FAR more about Linux and
Gentoo than I would have otherwise. (As well, since it took me that long,
and all the while I was in this group/list, the user group, and lurking in
the devel group, I learned all the stupid mistakes folks  make before I
got to them and was able to steer clear.  Stuff like the guy that just ran
emerge --prune without checking to see what  it was doing, first, etc.)

>> Specific:  Check that those video card USE flags are all USE flags, not
>> VIDEO_CARDS flags (that is, USE_EXPAND, not USE).  sis, for instance,
>> doesn't appear to be a USE flag (euse -i sis doesn't list it for either
>> local or global), altho i8x0 is a local use flag for a couple packages.
>
> I in this case am not using the sis or what not.  I am going to just use
> the video card that I am wanting to have support for under the VIDEO_CARDS
> flags like radeon, vesa etc when I understand more about telling it not to
> install support for others then I will add this then.

BSSJ covered this.  All I was saying is be sure to use --pretend, and get
the right stuff in the right place, USE vs VIDEO_CARDS, or you'll not end
up with the system you wanted.  However, it looks like you got that
covered.

>> General:  Since you are starting over, it's a good time to consider one
>> of my favorite features, FEATURES=buildpkg
> Can you tell me more about this and is this go in the make.conf file? so
> does this mean the system runs from bin files instead of what every the
> other way is?

BSSJ covered this, too.  I'll just add a pointer back to the handbook.  In
particular, this is mentioned (but unfortunately not in the detail I'd
prefer if I wrote it) along with a bunch of other useful info, in the
Working with Portage  and Working with Gentoo sections of the handbook. 
DON'T JUST READ THE INSTALL SECTION AND STOP, OR YOU'LL MISS SOME OF THE
BEST PARTS OF THE HANDBOOK!  Those Working with... parts are extremely
useful for just that... continuing to work with your system as the weeks
and months roll by, long after you finish installing.  Again, since it
took me so long to get a working system up and running, I had plenty of
time to read up on those things, and read thru them several times, and
from what I've seen on the groups, I'm more effective as a Gentoo sysadmin
than most, because  I know the tools and how they work.

Very briefly since BSSJ covered it and it's in the documentation too,
after the compile and install to the fake image in $PORTAGE_TMPDIR are
done, portage normally does a qmerge step, that moves everything from the
fake install image to the live system all in one step.  FEATURES=buildpkg
changes that so portage creates its own binary package archive instead,
then unpacks the archive and installs from it, thereby testing the archive
as it installs.  Again, having this archive can be very handy if an upgrade
goes wrong and you need to remerge an older version again.  Since you had
it merged before, you should have the binpkg still around, and can tell
portage to use it rather than having to go thru and recompile it again, as
you would if you'd removed it to install the upgrade then decided to roll
back, but did NOT have the binpkg hanging around.

I meant to mention the first time but forgot.  The binpkg archive is
normally kept in your portage tree, and will take 2-4 gigs more space than
if you didn't have it.

As for ccache and confcache, ccache is dealt with in the handbook fairly
well, so no need to cover it here.  confcache is newer, new to still ~arch
portage 2.1-rcs, but there's very little to configure there, besides
turning on the feature and emerging confcache. I believe it's covered at
least in make.conf.example and the make.conf manpage, assuming you have
~arch portage of course.  However, I don't think it's in the handbook yet.
The only thing you have to worry about with it is that very occasionally
something might not compile right with it, but if you are running ~arch
portage and gcc, you should be prepared to deal with that anyway.  It's
easy enough to toggle FEATURES=-confcache if you are having trouble with
something, just to ensure it's not confcache.



-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@g.o mailing list