1 |
2008/1/30, Duncan <1i5t5.duncan@×××.net>: |
2 |
> |
3 |
> Beso <givemesugarr@×××××.com> posted |
4 |
> d257c3560801300032m6f6c51adwc9f4bd75da066609@××××××××××.com, excerpted |
5 |
> below, on Wed, 30 Jan 2008 09:32:57 +0100: |
6 |
> |
7 |
> > i'd also advise to use the the --buildpkg feature for some high |
8 |
> > compiling time packages like kdebase, gcc, openoffice or mplayer. since |
9 |
> > these packages are likely to be the same for quite some time and they |
10 |
> > might be pushed into recompilation by some other updates having them |
11 |
> > packaged on disk (they'd require disk space when packaged) would mean to |
12 |
> > skip all the compilation part and jump directly to the install one (of |
13 |
> > course if they would need to be recompiled portage would do it). |
14 |
> |
15 |
> IMO --buildpkg (or better yet, FEATURES=buildpkg, if you've got 2-4 gigs |
16 |
> of room for the packages) is one of the most under-advertised power-user |
17 |
> tools Gentoo has. The binaries are just so handy to have around, giving |
18 |
> one all the advantages of a binary distribution if you need to remerge or |
19 |
> need to fetch a "pristine" config file for some reason, without losing |
20 |
> all the benefits and extra control allowed by from-source, since you |
21 |
> compile everything initially anyway. |
22 |
|
23 |
|
24 |
i only use it on system packages like gcc that are mandatory for compiling |
25 |
something (just in case something breaks) and on some big packages that |
26 |
don't update frequently (kdebase, kdelibs). this requires less space than |
27 |
buildpkg for all world packages. of course having this option enabled needs |
28 |
frequent distcleans after updates since there's the risk of having there |
29 |
different versions of the same package that aren't used. |
30 |
|
31 |
Of course, if something big dependency-wise changes, one often ends up |
32 |
> rebuilding from-source anyway, so the linking gets updated to the new |
33 |
> dependencies, so buildpkg is not a cure-all, but it certainly has its |
34 |
> uses, and I'd be hard pressed to try to do without it! |
35 |
|
36 |
|
37 |
it sure helps when a rebuild is triggered after a lib soname update or |
38 |
relinking issues. in that case there's no need to recompile but only to |
39 |
relink and having binary builds helps a lot. |
40 |
|
41 |
> i still think that having the base system on the unstable arch isn't a |
42 |
> > very good idea. i've used the same stuff for quite some time, but i |
43 |
> > found out that it isn't a very good stuff. or at least 6 months ago |
44 |
> > wasn't a good idea. |
45 |
> |
46 |
> I've never had serious issues in that regard. I'd suggest it's because |
47 |
> I /always/ use --update --deep --newuse on my emerge world updates, so |
48 |
> stuff tends to be pretty up to date anyway, and due to regular use of |
49 |
> revdep-rebuild and emerge --depclean to keep the system hygiene level |
50 |
> high. |
51 |
|
52 |
|
53 |
the problem is always there: major or blocking bugs getting into the |
54 |
unstable branch after the update of the package (has happened with dhcpcd |
55 |
for example) that makes gentoo devs mask the package the next day or so. so |
56 |
for people like me that update daily this could be troublesome if it happens |
57 |
on the system packages. |
58 |
|
59 |
The cure, of course, is a faster machine! =8^) Gentoo was reasonable |
60 |
> with my old dual Opteron 242, but merges for things such as gcc, glibc, |
61 |
> and DEFINITELY whole desktop updates like KDE, tended to be a chore. The |
62 |
> upgrade to dual dual-core Opteron 290s, combined with 8 gigs memory (tho |
63 |
> 4 gig would do) and putting PORTAGE_TMPDIR on tmpfs, made a HUGE |
64 |
> difference. Where KDE 3.5 updates, for example, would take ~12 hours |
65 |
> back when I had a gig of memory and no tmpfs, and ~8 hours after |
66 |
> upgrading the memory, I was running the KDE4-svn ebuilds from the |
67 |
> overlay, and could compile all of KDE4 (well, most, I didn't have kdeedu |
68 |
> or kdedevel merged) in ~4 hours with the dual dual-cores and |
69 |
> PORTAGE_TMPDIR on tmpfs with 8 gigs memory, generally < 2 hours with |
70 |
> everything ccached if I did it daily, and often closer to a single hour! |
71 |
|
72 |
|
73 |
this is a high end machine. opteron is better than a normal athlon x2 in |
74 |
terms of compilation and having 8gb on a server mobo, that differs from |
75 |
normal mobos, is not affordable for every user. my system is about the |
76 |
average one (2ghz processor, 1gb ram, 80gb hdd) for notebooks and quite |
77 |
average one for desktops. remember that nuveau devs still work on athlons or |
78 |
pentium 3 hw, and that hw is not dead yet. your system nowadays is a |
79 |
middle-high end one. |
80 |
|
81 |
Really. Those who've not yet had a chance to try quad cores (however you |
82 |
> get them) and a good 4 gigs memory minimum, it really /does/ make running |
83 |
> Gentoo pretty trivial. A couple years from now when that's a lower end |
84 |
> new system, it's likely Gentoo and other from-source distributions will |
85 |
> see a fresh rise in popularity, because the time differences between |
86 |
> grabbing a binary update and grabbing a from-source update begin to be |
87 |
> pretty trivial, while all the advantages of from source, in particular, |
88 |
> greater control of dependencies without bloat, remain. At that level, |
89 |
> the admin time, just figuring out what you are going to install, and |
90 |
> dealing with the config updates, etc, is as much a factor as the compile |
91 |
> time. By the time we reach 8 cores and a full 8 to 16 gig RAM, that |
92 |
> admin time will be the MAJOR factor, with the actual compile time almost |
93 |
> entirely a non-factor, so the advantages of running binary pretty much |
94 |
> disappear while the advantages of running from-source remain as big as |
95 |
> they ever were! |
96 |
|
97 |
|
98 |
well, this is true for minor packages, but kdelibs or kdebase for example |
99 |
are still quite big and if you're not a developer you won't go around |
100 |
compiling it everyday or so. |
101 |
|
102 |
-- |
103 |
> Duncan - List replies preferred. No HTML msgs. |
104 |
> "Every nonfree program has a lord, a master -- |
105 |
> and if you use the program, he is your master." Richard Stallman |
106 |
> |
107 |
> -- |
108 |
> gentoo-amd64@l.g.o mailing list |
109 |
> |
110 |
> |
111 |
|
112 |
|
113 |
-- |
114 |
dott. ing. beso |