1 |
On 26 December 2006 17:56, James wrote: |
2 |
|
3 |
> So I update the test workstation on fridays, use it over the weekend a |
4 |
> nd then update the other systems. Granted, if the devs release something |
5 |
> (broken) over the weekend, I get screwed with this scheme sometimes. |
6 |
> I should update the test system daily (in the mornings) and then |
7 |
> update the other systems on the same day after that. |
8 |
|
9 |
>From my experience, another approach is easier and safer. If your test |
10 |
workstation and your productions workstation are basically equivalent (as far |
11 |
as their world files are concerned, *not* their hardware) you can just NFS |
12 |
mount your test box's portage tree on your production box and update it from |
13 |
there. I will not download new packages but use the ones on your test box |
14 |
tested over the weekend. |
15 |
|
16 |
> |
17 |
> Problems with that scenario is the various methods of proxying the |
18 |
> downloads and syncs are problematic in and of themselvs, not very |
19 |
> often, but still bad enough to make those current schemes, less |
20 |
> than desirable. Futhermore, DistCC is still a 'work in progress' |
21 |
> and I've experience just enough hassle that it has been disabled |
22 |
|
23 |
I disagree here. I have used distcc without any major problem for at least one |
24 |
year by now. |
25 |
|
26 |
> (also due in part to so many different variants of x86). |
27 |
|
28 |
This doesn't affect distcc. The slave compiles a a C or C++ according to the |
29 |
specs of the master. The master runs the source file through its preprocessor |
30 |
and sends the result with all necessary commandline options over to the |
31 |
slave. Those options contain the desired architecture/CPU of your master. The |
32 |
slave compiles the preprocessor output, runs that result through its |
33 |
assembler and transfers the resulting object file back to the master which, |
34 |
eventually, links it. So don't worry about different CPUs within the x86 |
35 |
domain or different libraries. |
36 |
|
37 |
Just have the same compiler version installed on all participating boxes. |
38 |
|
39 |
It's a bit more difficult if a slave has a completely different architecture. |
40 |
In that case, you need to install cross compilations system for the master on |
41 |
that particular slave. |
42 |
|
43 |
> |
44 |
> Long story short: Gentoo is the best distro for our work, as one only |
45 |
> has to installed debian, suse, or redhat for a week or two, to realize |
46 |
> just how spoiled you get with Gentoo. That said, I've learned to be |
47 |
> cautious and patient with key software upgrades on Gentoo. However this |
48 |
> approach burns lots of extra time. My hope is Gentoo will continue to |
49 |
> improve and become more of a 'production' distro, as the other Linux |
50 |
> distros all seem to have unacceptable flaws, for our needs. |
51 |
|
52 |
I full-heartedly agree here. |
53 |
|
54 |
Uwe |
55 |
|
56 |
-- |
57 |
A fast and easy generator of fractals for KDE: |
58 |
http://www.SysEx.com.na/iwy-1.0.tar.bz2 |
59 |
|
60 |
-- |
61 |
gentoo-user@g.o mailing list |