"Christopher E" <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sat, 20 May 2006 11:19:18 -0400:
> Hello Ducan, > >> 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? The newer editions of the handbook cover it in some detail, but I was lurking on the dev list when it was discussed there, so I can give a bit more developer side viewpoint. Boyd SS Jr. also has some very good points, so grab them too. (That's what's great about lists/groups, often you get several posts, each from slightly different viewpoints, and get to pick and choose the explanations and try the solutions first that fit yourr style. =8^) Basically what's happened is that with all the packages and platforms and all the customization possible with Gentoo now, it's simply no longer possible to test all the permutations and corner-cases of building from a stage-1. Too often, some of those corner cases fail to work, and people trying to install Gentoo are left frustrated when they run into first one problem and then another. The stage-3 approach, which is what the handbook strongly recommends now, starts with far more of the system initially compiled. You then do an emerge --empty-tree system once you've set up your CFLAGS and the like the way you want them, and portage recompiles everything the way you want it. Done right, it's a far easier way to end up with the same customized system you'd have otherwise, and since the packages in the stage-three are all tested to work as they exist in the stage-three, it's far harder to break and there are far fewer corner cases for folks to run into. There are a few drawbacks, however. As BSSJ mentions, it's a bit more difficult to change CHOST, among other things. However, with amd64 we are lucky as there's really not much reason for us /to/ change CHOST. The other one that's big here, is that I not only started from stage-one, but due to those memory issues I mentioned in the reply to BSSJ, I actually had to take apart bootstrap.sh and execute each step manually, one at a time. As a result, I know rather more about what makes a Linux system tick than I would have otherwise. Folks that do a stage-three simply aren't going to be forced to get as up close and personal with their systems as those choosing a stage-one and persevering thru all the corner-cases to find solutions. It'll be far faster and far easier, but they'll not know as much about their system when they are done, and in some ways, that's a shame. It actually took me three months to get the system up and running (I was dual booting Mandrake at the time, so it wasn't as if the system was entirely dead for three months), due to the hardware and some software problems I ran into, back on 2004.0 and 2004.1 when I first installed Linux, but I'm glad I did it that way, as I know FAR more about Linux and Gentoo than I would have otherwise. (As well, since it took me that long, and all the while I was in this group/list, the user group, and lurking in the devel group, I learned all the stupid mistakes folks make before I got to them and was able to steer clear. Stuff like the guy that just ran emerge --prune without checking to see what it was doing, first, etc.) >> 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. > > I in this case am not using the sis or what not. 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 etc when I understand more about telling it not to > install support for others then I will add this then. BSSJ covered this. All I was saying is be sure to use --pretend, and get the right stuff in the right place, USE vs VIDEO_CARDS, or you'll not end up with the system you wanted. However, it looks like you got that covered. >> 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? BSSJ covered this, too. I'll just add a pointer back to the handbook. In particular, this is mentioned (but unfortunately not in the detail I'd prefer if I wrote it) along with a bunch of other useful info, in the Working with Portage and Working with Gentoo sections of the handbook. DON'T JUST READ THE INSTALL SECTION AND STOP, OR YOU'LL MISS SOME OF THE BEST PARTS OF THE HANDBOOK! Those Working with... parts are extremely useful for just that... continuing to work with your system as the weeks and months roll by, long after you finish installing. Again, since it took me so long to get a working system up and running, I had plenty of time to read up on those things, and read thru them several times, and from what I've seen on the groups, I'm more effective as a Gentoo sysadmin than most, because I know the tools and how they work. Very briefly since BSSJ covered it and it's in the documentation too, after the compile and install to the fake image in $PORTAGE_TMPDIR are done, portage normally does a qmerge step, that moves everything from the fake install image to the live system all in one step. FEATURES=buildpkg changes that so portage creates its own binary package archive instead, then unpacks the archive and installs from it, thereby testing the archive as it installs. Again, having this archive can be very handy if an upgrade goes wrong and you need to remerge an older version again. Since you had it merged before, you should have the binpkg still around, and can tell portage to use it rather than having to go thru and recompile it again, as you would if you'd removed it to install the upgrade then decided to roll back, but did NOT have the binpkg hanging around. I meant to mention the first time but forgot. The binpkg archive is normally kept in your portage tree, and will take 2-4 gigs more space than if you didn't have it. As for ccache and confcache, ccache is dealt with in the handbook fairly well, so no need to cover it here. confcache is newer, new to still ~arch portage 2.1-rcs, but there's very little to configure there, besides turning on the feature and emerging confcache. I believe it's covered at least in make.conf.example and the make.conf manpage, assuming you have ~arch portage of course. However, I don't think it's in the handbook yet. The only thing you have to worry about with it is that very occasionally something might not compile right with it, but if you are running ~arch portage and gcc, you should be prepared to deal with that anyway. It's easy enough to toggle FEATURES=-confcache if you are having trouble with something, just to ensure it's not confcache. -- 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 -- [email protected] mailing list
