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

[Beso]

2008/1/30, Duncan <1i5t5.duncan@×××.net>:
>
> 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.


i only use it on system packages like gcc that are mandatory for compiling
something (just in case something breaks) and on some big packages that
don't update frequently (kdebase, kdelibs). this requires less space than
buildpkg for all world packages. of course having this option enabled needs
frequent distcleans after updates since there's the risk of having there
different versions of the same package that aren't used.

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!


it sure helps when a rebuild is triggered after a lib soname update or
relinking issues. in that case there's no need to recompile but only to
relink and having binary builds helps a lot.

> 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 problem is always there: major or blocking bugs getting into the
unstable branch after the update  of the package (has happened with dhcpcd
for example) that makes gentoo devs mask the package the next day or so. so
for people like me that update daily this could be troublesome if it happens
on the system packages.

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!


this is a high end machine. opteron is better than a normal athlon x2 in
terms of compilation and having 8gb on a server mobo, that differs from
normal mobos, is not affordable for every user. my system is about the
average one (2ghz processor, 1gb ram, 80gb hdd) for notebooks and quite
average one for desktops. remember that nuveau devs still work on athlons or
pentium 3 hw, and that hw is not dead yet. your system nowadays is a
middle-high end one.

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!


well, this is true for  minor packages, but kdelibs or kdebase for example
are still quite big and if you're not a developer you won't go around
compiling it everyday or so.

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


-- 
dott. ing. beso