Re: [gentoo-user] Sync'ing and compiling pkgs for multiple PCs

[Simon]

> Yes, your words about "dependency" and "flexibility" are valid, but this
> is also the most straightforward way to sync multiple machines at once.
> If you do need to emerge a package when the laptop is away from home
> then just --sync and it builds a portage tree at the "missing
> mountpoint" (if that makes sense).

I'll consider that, but seriously, I've tried many ways, including rsyncd, to 
sync portage on my computers and I've settled for unison.  Really, I like it for 
its simplicity of use and maintenance and the fact that my host only has the ssh 
port open.  Sync'ing portage is not a problem, i'll explore different ways along 
the way.  Dont try to convince me of other ways, this one is working (and I 
don't mind whatever downsides).

> Great! I'm glad you're happy with this. You're NFS exporting a
> sub-directory of /usr/portage, then, in order to share the built packages?

As said, no.  I'm using a separate copy on each host, which is sync'ed manually 
between those hosts.  It may sound awful, but it actually syncs my /home 
directory, as well as my /root dir (where I keep important system stuff, like 
dev drivers source).  The sync'ing is not very long and once done, each computer 
is completely independant and contains all my stuff i need.  Which creates 
redundancy.

I had tried NFS before, and failed, but I was not very interested and the first 
few obstacles made me drop it. It was before I tried gentoo and started my own 
personal 'renaissance' and learned so much.  I'll try it again soon, but it's 
not my priority for now.

> I assume compilation errors. My usage is that I can turn distcc off for
> the duration of the compile when I see something like this, and not
> bother investigating it further, but I think the most likely cause is
> that a library is needed for compilation that is not present on the
> distcc server. Portage accepts the compile-time dependency because it is
> filled on the distcc client, the machine on which you've run emerge, but
> when that particular bit is   sent off to the distcc server then that
> machine doesn't have the lib needed.

Well, this is the whole problem.  You were right about the compilation error. 
And if it *may* happen, then a full emerge -e will take days (considering system 
has 143 pkgs and world has 499 pkgs to build).  Turning it off, emerge the 
package, turn it on, resume emerge once in a while is really against my idea of 
automatism!  I might make a script that checks for binpkgs after emerge returns, 
and if no pkg was created, then disable distcc for that one, re-enable 
automatically...  maybe prepare a report to send to the ebuild maintainer, to 
let him know of the issue and all relevant details.

> I would imagine that, assuming the above belief is correct, then the
> workaround would be to `emerge -o` the package on the other machines on
> your LAN (or the fastest machine, if you are using only that to emerge)
> before distcc'ing it. This is slightly inelegant.

Clearly less and less transparent... i'd say cloudy.  Seriously at this point, 
i'd just drop distcc completely.  But I don't think I'll have to go that far.

> If you mostly have the same packages on all machines then hopefully you
> shouldn't encounter this scenario too often, although I'd also think
> that different USE flags could affect it.
>
> I'm also somewhat suspicious of different architectures - you wouldn't
> try compiling for ARM or MIPS on an x86 PC, but I'm not sure how
> compiling on an Athlon for a Pentium 3 or 4 affects things. Finally you
> should make sure all machines are using the same versions of gcc and
> glibc (also binutils? what else?).

Same everything on every machine, i'll double check glibc and binutils too.

Thanks Stroller, I'm really starting to see how I can manage my mini IT lab now!
Simon