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

[Boyd Stephen Smith Jr.]

On Saturday 20 May 2006 10:19, "Christopher E" <sensory.access@×××××.com> 
wrote about 'Re: [gentoo-amd64] Re: Advice Wanted! Setup Instuctions ...':
> > 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?

Stage 1 has quite a bit of craft that will never get cleaned up, because 
otherwise it wouldn't compile /everything/.  Stage 3 + --emptytree gives 
you all the advantages of starting from Stage 1.

There are still some issues with changing your CHOST when starting from 
Stage 3, AFIAK.

> > Specific:  Check that those video card USE flags are all USE flags,
> > not VIDEO_CARDS flags (that is, USE_EXPAND, not USE).
>
> 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.

Just make use you put the flag(s) in the correct place.  Some are USE 
flags, which go directly into USE, some are handled by the relatively new 
USE_EXPAND feature of portage and go into VIDEO_CARDS.  If you use the 
wrong variable, you won't get the system you desire.

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

Yes, all FEATURES go into the FEATURES variable in make.conf.  (Of course, 
you can put them in portage's environment however you please, but most 
people use make.conf.)

buildpkg changes way emerge works, but only slightly.  The final step is 
normally the merge step where files are copied from the sandbox onto the 
live system.  Instead this done in two phases.  First all the files that 
would have been copied from the sandbox (along with some metadata) are 
added to a tbz2 (compressed archive) file.  Then, this archive is 
extracted over the root filesystem, effectively doing to copy AND testing 
the archive.  Finally the archive is moved to your packages directory.  In 
an *emerge*ncy (like, portage is broken) you can simply extract the 
tarball for the broken package yourself.  Also, computers that will be set 
up similarly (binary-compatible compiler(s) and compiler flags) can use 
those packages (by setting up BINHOST and passing -k to emerge) to avoid 
compilation time when use flags do not differ.

> > 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.
>
> What does this do?  Also does this go in the make.conf file?  Any
> other stuff that would be good to know about this would be great.

Again, all FEATURES go into make.conf read 'man 5 make.conf'.

To understand confcache, you have to know about GNU autoconf.

A number of open-source packages use GNU autoconf.  This does various tests 
on the target system, and write out a file for of C preprocessor 
directives that can be used by the source to determine what features need 
to be activated in the source.

GNU autoconf has a feature that allows it to use an existing cache to avoid 
performing duplicate tests.  This cache is automatically generated by 
autoconf, but is not automatically stored or accessed globally.  (Instead 
it mainly used when 2 [or more] tests depend on the same sub-test.)  This 
is not done because it's critical to know when to expire entries in the 
cache, and autoconf does not do this itself.

Confcache is Gentoo's attempt to share this cache globally, which will 
speed some packages (kde-meta) up significantly (all the individual KDE 
applications perform virtually the same autoconf tests).  It has some 
system for expiring the cache (although, I believe it is currently the 
whole cache and not individual entries), storing the cache globally, and 
copying it into the local position autoconf expects it to be in.

AFAIK, it's still experimental.  I'm currently blaming it for some meta-kde 
emerge failures, but I also was using a number of other experimental 
FEATURES at the same time, so I don't have any hard evidence that it's 
broken.

> > 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.
>
> So it sould like this is some thing that is not needed and does not do
> much for the system in my case at less?

Well, IIRC, ccache is able to match on file /data/ and basically ignores 
the file /name/ which allows it some speed up some autoconf tests.  Many 
autoconf tests are just attempts to compile simple, but specially 
constructed, C files.

Also, ccache can speed up restarting packages that fail to emerge the first 
time through.

-- 
"If there's one thing we've established over the years,
it's that the vast majority of our users don't have the slightest
clue what's best for them in terms of package stability."
-- Gentoo Developer Ciaran McCreesh