[gentoo-amd64] Re: 64 newbie

[Duncan]

Thierry de Coulon posted <200601232247.51501.tcoulon@××××××××.ch>,
excerpted below,  on Mon, 23 Jan 2006 22:47:51 +0000:

> I have been a Linux user for over five years - mostly using SuSE first, then
> Debian based distributions, but from time to time "toying" with Gentoo.
>
> Now I'm in the process of building an Opteron based machine and decided it
> would be a good idea to build a Gentoo-amd64 distribution.
>
> I've googled quite a bit but I would still like to ask a few questions, such
> as:
> - are there special points I should pay attention to or can I simply follow
> the amd64 install instruction?

Following the instructions will get you there, sometimes with a detour or
two to the group to ask questions if there's some stickler or another for
your system.

The biggest suggestion I have is DON'T STOP WITH THE INSTALLATION SECTION
IN THE HANDBOOK!  You said you've "toyed" with Gentoo, but I that doesn't
really say how much you know about it.  I'm frequently surprised by the
number of folks who've been running Gentoo for some time, but who don't
know what I consider Gentoo basics -- stuff explained quite well in the
Working with Gentoo and Working with Portage sections of the handbook. 
Seriously, if you've never taken time to read them in your "toyings",
now's a very good time to do so.  Those sections cover some pretty
important basics for being a good Gentoo user == Gentoo system sysadmin,
with all the responsibilities and power that implies.

As one small sample of the tidbits covered, coonsider adding "buildpkg" to
the FEATURES line in make.conf.  This will cause portage to create binary
packages every time it emerges something.  If for some reason you want to
roll-back to a previous version, it's a WHOLE lot simpler to simply emerge
-K =package-version, and let portage unpack your previous version, than it
is to have to rebuild the entire thing from source.

Because binpkgs are regular tar.bz2 tarballs, only with a bit of portage
metainformation tacked onto the end, it's also possible to use the binpkgs
in other ways. If portage dies, for instance, you can simply untar an old
version directly over the broken one on the live filesystem (be sure and
backup your customized make.conf -- any config files -- first, as
untarring directly over the live filesystem will of course replace them
too, so you'll have to restore your customized versions after the untar
operation).  That gives you a working portage again, but of course, the
portage database is now out of since with what's on the system, because
you bypassed portage with the untar, so you'll now want to remerge the
same binary package over the untarred version to get portage's database
back in sync.  Of course, if it's gcc that breaks, you can simply emerge
-K a working gcc.  You can also browse the tarballs with mc or ark or
whatever, comparing the files between versions or to what's on your system
currently, restoring individual files if desired, and the like. 

The space required to store all those binpkgs?  1 gig will probably do it,
but you'll have to remove the extra copies fairly frequently.  2 gig is a
minimum "comfortable" allocation.  I have mine on its own 4-gig partition,
now, and that's quite roomy.  It's well worth the space, IMO!  (The space
requirement isn't mentioned  in the handbook, so that's a bonus you get
from reading my post!)

All-in-all, FEATURES=buildpkg is a VERY handy thing to have enabled, and
something *I* think should be the default.  However, unless you continue
reading in the handbook beyond the install section, or come across it in a
discussion such as this, that's a feature you'll likely entirely miss! 
There are other invaluable hints in those sections as well.  You really
can't afford to miss them, but unfortunately, a lot of people do.

> - As far as I understand there are still lots of programs that won't compile
> in 64 bit. What will happen if I try to emerge such a program?

You already know about keywords, right?  Gentoo packages that are known to
work on amd64 are marked ~amd64 or amd64, just as ~x86 or x86 denotes
those that work on standard 32-bit x86 (with ~arch denoting testing, of
course).  If you are working with portage, it'll manage those just as it
does on x86.  No worries.

If you want to try a package that's not yet keyworded, you can of course
either use package.keywords or copy it to your overlay and make the
necessary mods there, again, just as if you were doing it on x86, only
with amd64 instead.  If it works for you, please file a keyword bug
(instructiions in the Gentoo-amd64 documentation). If it's a package not
in portage, again, the usual procedures that apply to x86 apply here as
well, only with a somewhat lower chance of success, unless you do some
work fixing things up to make it work on amd64, and with 64-bit compiling
instead of 32-bit.  (There's 32-bit compiling also available, see the
gentoo-amd64 docs for more.)

> - it seems most of the multimedia codecs still are 32 bit. Can you use these
> on a 64 bit distro?

Yes and no.  Yes, you can make use of them, but no, not with your regular
64-bit programs, because 32-bit code and 64-bit code in the same execution
space (as with 32-bit shared-object codecs loaded into 64-bit programs)
simply doesn't work.  Gentoo has precomiled 32-bit compatibility versions
of firefox, mplayer, and the like, which can be merged, along with the
32-bit codecs.  The 64-bit regular version and 32-bit compatibility binary
can even both be merged on the same system, without overwriting each other!

You can also do your own 32-bit compiling, using a 32-bit chroot or the
like, but there are some complexities to that, so unless you are
hard-core, the pkg-bin prebuild compatiblity packages are recommended. 
Again, there's documentation available to help with the chroot method, if 
that's what you want to do.

> - other 64 bit distributions (I've downloaded SuSE and Kubuntu) will allready
> have dealt with most compatibility problems. Should I learn more about 64 bit
> specificities before attempting to build a Gentoo-64 system?

As others have said, it's not really necessary.  As a general user, you
just install it, and it generally works.  Developers and advanced users
can do more, of course, but it's possible and recommended to learn as you
go.

-- 
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 in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@g.o mailing list