Beso <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Wed, 30 Jan 2008 09:32:57 +0100:
> i'd also advise to use the the --buildpkg feature for some high > compiling time packages like kdebase, gcc, openoffice or mplayer. since > these packages are likely to be the same for quite some time and they > might be pushed into recompilation by some other updates having them > packaged on disk (they'd require disk space when packaged) would mean to > skip all the compilation part and jump directly to the install one (of > course if they would need to be recompiled portage would do it). IMO --buildpkg (or better yet, FEATURES=buildpkg, if you've got 2-4 gigs of room for the packages) is one of the most under-advertised power-user tools Gentoo has. The binaries are just so handy to have around, giving one all the advantages of a binary distribution if you need to remerge or need to fetch a "pristine" config file for some reason, without losing all the benefits and extra control allowed by from-source, since you compile everything initially anyway. Of course, if something big dependency-wise changes, one often ends up rebuilding from-source anyway, so the linking gets updated to the new dependencies, so buildpkg is not a cure-all, but it certainly has its uses, and I'd be hard pressed to try to do without it! > i still think that having the base system on the unstable arch isn't a > very good idea. i've used the same stuff for quite some time, but i > found out that it isn't a very good stuff. or at least 6 months ago > wasn't a good idea. I've never had serious issues in that regard. I'd suggest it's because I /always/ use --update --deep --newuse on my emerge world updates, so stuff tends to be pretty up to date anyway, and due to regular use of revdep-rebuild and emerge --depclean to keep the system hygiene level high. The one hassle there is, is that ~arch may have multiple version updates in the time there's only a single stable version update. It's not uncommon for USE flags to change, thus triggering a --newuse rebuild, and/ or for various bugs and their fixes discovered during the ~ phase to be judged -rX worthy, and stable folks and those that don't routinely use --deep get to skip a lot of that. The cure, of course, is a faster machine! =8^) Gentoo was reasonable with my old dual Opteron 242, but merges for things such as gcc, glibc, and DEFINITELY whole desktop updates like KDE, tended to be a chore. The upgrade to dual dual-core Opteron 290s, combined with 8 gigs memory (tho 4 gig would do) and putting PORTAGE_TMPDIR on tmpfs, made a HUGE difference. Where KDE 3.5 updates, for example, would take ~12 hours back when I had a gig of memory and no tmpfs, and ~8 hours after upgrading the memory, I was running the KDE4-svn ebuilds from the overlay, and could compile all of KDE4 (well, most, I didn't have kdeedu or kdedevel merged) in ~4 hours with the dual dual-cores and PORTAGE_TMPDIR on tmpfs with 8 gigs memory, generally < 2 hours with everything ccached if I did it daily, and often closer to a single hour! Really. Those who've not yet had a chance to try quad cores (however you get them) and a good 4 gigs memory minimum, it really /does/ make running Gentoo pretty trivial. A couple years from now when that's a lower end new system, it's likely Gentoo and other from-source distributions will see a fresh rise in popularity, because the time differences between grabbing a binary update and grabbing a from-source update begin to be pretty trivial, while all the advantages of from source, in particular, greater control of dependencies without bloat, remain. At that level, the admin time, just figuring out what you are going to install, and dealing with the config updates, etc, is as much a factor as the compile time. By the time we reach 8 cores and a full 8 to 16 gig RAM, that admin time will be the MAJOR factor, with the actual compile time almost entirely a non-factor, so the advantages of running binary pretty much disappear while the advantages of running from-source remain as big as they ever were! -- 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
