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

[Duncan]

"Christopher E" <sensory.access@×××××.com> posted
184c54640605190933k5bff423m961897d2a4c79403@××××××××××.com, excerpted
below, on  Fri, 19 May 2006 12:33:34 -0400:

> 22. nano -w /mnt/gentoo/etc/make.conf
> 	Add: -march=k8
> 	Add: MAKEOPTS="-j2"
> 	Add: USE="gtk gnome qt kde dvd alsa cdr opengl radeon -sis -rage128
> -matrox -3dfx -gamma -i8x0 "
> 	Add: VIDEO_CARDS="fglrx radeon"
> 	Add: ACCEPT_KEYWORDS="~amd64"

I've been saving this to reply to when I wasn't too tired to make sense of
it.  Seems you may be doing it, so maybe I should hurry it up...

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.  However, two suggestions
come to mind, one general, one specific based on the above.

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.

General:  Since you are starting over, it's a good time to consider one of
my favorite features, FEATURES=buildpkg.  The idea is that portage creates
a binary package of everything it merges with that feature, then instead
of doing qmerge directly, it merges from the binpkg it just created,
thereby testing it to be sure it works.  That way, you build up a backup
of all the packages you have merged, and if a future upgrade goes wrong,
you don't have to spend all that time remerging the old one again, you
just remerge the binpkg (using emerge -K =pkg-version to downgrade if
necessary).  It's also handy if gcc or the like go titsup, as you can
remerge the gcc binpkg directly instead of trying to figure out how to get
a working gcc to emerge gcc!  In fact, since the binpkg is just a bzip2-ed
tarball, (tbz2), with a bit of extra metadata stuck on the end, even if
portage itself dies, it's a fairly simple matter to just backup make.conf
and untar the binpkg directly over /, thus getting a working portage once
again.  (Of course, the database will still think it has the broken
version merged, so you then have to emerge -K the working version you just
untarred, so the database is in sync with what's really there once again.)

Bonus General I just remembered: If you are using ~arch portage as you
mentioned, 2.1-rcX now, you may also wish to investigate
FEATURES=confcache.  For packages like modular KDE, which spend a higher
than normal percentage of merge time in the configure step, it can make a
HUGE difference -- saving you well over an hour (it's over an hour saved
on my dual Opteron with 8 gig of memory and 4-way RAID, so probably several
hours on a single core single socket system with a single hard drive and
a gig or less of memory) running PORTAGE_TMPDIR on a TMPFS, ) on a full
KDE merge.

Of course there's ccache as well, but that can actually take longer if you
aren't doing much recompiling of the same code with the same options on
the same gcc, due to the extra disk activity of managing the ccache, and
there's distcc, if you have several computers that can share the load.



-- 
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