[gentoo-amd64] Re: madwifi-ng not compile in amd64

[Duncan]

Beso <givemesugarr@×××××.com> posted
d257c3560801300032m6f6c51adwc9f4bd75da066609@××××××××××.com, 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

-- 
gentoo-amd64@l.g.o mailing list