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
