[gentoo-amd64] Re: Re: 64 or 32?

[Duncan]

Thierry de Coulon posted <200602100848.26651.tcoulon@××××××××.ch>,
excerpted below,  on Fri, 10 Feb 2006 08:48:25 +0000:

> I sure have to get more understanding of how to run 32bit apps on a 64bit
> distro - I am willing to learn but you'll probably have to suffer a lot of
> questions from me. But this does not seem to be a problem on this list :)

Happily, no.  It's a point of pride for many of us that Gentoo gets high
marks for the friendliness and accessibility of its user community. =8^)

> I'll think it over again, but I think I'll go for a compromise (we swiss are
> well known for this way of doing, aren't we?): I have a working Mepis 32bit
> (the distribution I use on my "old" main machine. SO I'll probably build a
> 64bit Gentoo and I can switch the day I feel it works the way I like.

We'll all be rooting for you! 

Note that I took something like three months to get my Gentoo amd64 system
up and running, in part because  I had some very specific ideas of how I
wanted it to look and work when I was done, and as I result, had to adapt
the installation instructions somewhat.  Some of those adaptations turned
out to be mistakes, or cause something else to break, so I'd have to go
back and "unbreak" things, and actually started over a couple times.  Of
course, the whole time I was learning all the more, because I was breaking
things and learning how they worked and how to fix them in the process,
and the whole time I was keeping up on the user, amd64, and devel lists
(the latter of which I follow in part because I like to have a heads-up on
where Gentoo is headed), so by the time I got a working system, to the
point where I /could/ experience some of the common mistakes of others, I
had not only read all about them and avoided making them myself, but
understood why they could happen and a bit about why the Gentoo devs
hadn't or couldn't simply ensure they didn't happen in the first place!

This was all possible because while I only have a single system going, I
had a fully working Mandrake for AMD64 installation on another set of
partitions, and would routinely have a chroot session going, in which I'd
be setting up something in Gentoo, or trying out some strange alternative
of my own, but it was just a chroot running in a konsole window on my
otherwise normally operating Mandrake system.  Of course, the fact that
my system is a dual Opteron helped with that, keeping all the Mandrake
stuff responsive even as I was emerging something on the Gentoo side for
the Nth time, because I was too stubborn to simply follow instructions. =8^)

Note that this wouldn't have worked if I'd been running a 32-bit OS,
because the 64-bit compilations wouldn't have worked the same way in that
case, but that I had only a single computer to work on, while you can
simply keep running your 32-bit stuff on your current Mepis install, until
as you said, you are comfortable with the 64-bit Gentoo install on your
new machine.

Two hints I like to give to all new users:

1)  Gentoo documentation is considered some of the best in the community. 
Don't be afraid to use it.  In particular, the Gentoo Handbook is *NOT*
just the install section.  To make the best use of your new Gentoo system,
you'll want to read the Working with Gentoo and Working with Portage
sections as well (altho it's OK to skim the chapters dealing with ebuild
details and the like, just getting a bit of how ebuilds work out of them,
as helps in troubleshooting when one /doesn't work for you).  Very often,
it's quite apparent by the questions people ask, that they skipped that
information, and it just makes it harder for them to manage their system,
until the go back and read over it, or pick it up a piece at a time on the
lists and forums.  To me, that's a shame, when they could have avoided
needless pain and mistakes, and be managing their system much more
effectively, had they just read the documentation that's there to read.

2)  Before you get too far along, certainly before your first emerge
--update --deep world and preferrably before you start merging world
packages at all, consider adding "buildpkg" to your FEATURES line in
make.conf. What this does is covered in the handbook, so you'll understand
more about it after reading the sections I recommended above, but the
handbook doesn't quite convey how useful it can be in so many words, and
people often miss it.

What FEATURES=buildpkg does is simple, really.  It tells portage to
create and store a binary package for everything it emerges.  What this
means is that if you upgrade a package and find it isn't working quite
right, it's quite easy to use emerge -K to revert to the earlier version
that portage created a binary package of when it merged it.  Without this
binpkg, you'd have to do the entire remerge from source thing, which on
some packages can take awhile, all to see if it corrected the problem you
discovered with a new version, or if the problem was elsewhere.  If you
find the old version has the problem too, again, it's a very simple
process to remerge the now binpkged new version again.  (For doing the
same thing with already merged packages, there's the quickpkg utility. 
However, you have to know you'll need it to use it, while if portage
automatically creates the binpkgs, they'll be there for you when you need
them, whether you thought you might need them or not.)  There are some
other advantages to buildpkg as well, such as making it easier to recover
if gcc or even portage quits working, because you have a binary package
available, but these are side effects of the primary benefit, that those
binary packages are created and available for you in the first place.

The buildpkg FEATURE typically requires an additional 1-4 gigs of space to
store packages for the entire system.  A gig will usually just barely
cover one version of each package, two gigs gives you room for several
versions of the ones changing the fastest, four gigs gives you plenty
of room for expansion and means you won't have to worry about cleaning out
the oldest stale versions very often. (Newer versions of gentoolkit, a
very useful addition to portage that most folks eventually merge, include
eclean, a tool that helps manage the packages dir, cleaning out the stale
versions of packages.  I think eclean is only in the ~amd64 version,
however, not the stable amd64 version, yet.)  I arrived at the 1-4 gig
figure because I have my packages dir on a separate partition, here.  It's
now 4 gig for expansion, but 2 gig was usable, while a gig was simply
cramped.

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