Thierry de Coulon posted <[EMAIL PROTECTED]>, 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 -- [email protected] mailing list
