I use NFS to deploy Portage throughout my network here. I export /usr/portage, /etc/portage, and /export/var/cache/edb/dep. The only real draw back I've experienced over the year is the fact all entries within /etc/portage cannot be designated to a certain host. (A second plan follows.) For example: For hosts that can't handle the much newer nvidia-drivers packages: /etc/portage/package.mask >x11-drivers/nvidia-drivers-100.0.0@localhost1 >x11-drivers/nvidia-drivers-100.0.0@localhost2 For a host with a newer nvidia card and can handle the newer driver releases: /etc/portage/package.unmask x11-drivers/nvidia-drivers@localhost3 Reproducible: Always A good example of a package having problems among my x86 boxes is the package nvidia-drivers. Two of my boxes have legacy nvidia-drivers and cannot use the later released nvidia-driver packages. Another solution to this situation is to split the nvidia-driver package into two or three separate packages. For which, I think should have done. At least two titled, "nvidia-driver" and "nvidia-driver-legacy". (Per Nvidia docs, there's actually two series of legacy drivers/cards.) In other words, ensure ebuilds are not hacked to provide an all-for-one solution! I'm not sure how many others experience this short coming, but I do know I'm not the only one who uses NFS with Portage and it's also advisable as it reduces network bandwidth use, as well as being able to block internal boxes for accessing the outside network.
Adding hostnames to the config format is not worth the added complexity for us to maintain. As an alternative, you might use the "package.mask as directory" approach, which will allow you to separate the host-specific configurations into separate files. You could organize it like this: /etc/portage/package.mask/shared <- shared settings /etc/portage/package.mask/localhost1 <- settings specific to localhost1 Then you'd just have to make sure that each host gets only the host-specific settings that apply to it. This could be accomplished by making /etc/portage/package.mask/localhost1 a symlink to a file that only exists on localhost1, and having it exist as a broken symlink (which is ignored) on the other hosts.
Alternatively you can have: /exports/etc/portage/$host/* and then use a mapping to mount the correct export on each host. HostA would mount mount -t nfs NFSHOST:/exports/etc/portage/Hosta /etc/portage -o ... LDAP and automount were built to serve purposes like this; although it may be more complicated than one would like ;) -Alec
(Ah! Mid-Air Collision with ALec! ... I'm reiterating pretty much the same below, but with a gripe about nvidia-driver.ebuild ;-) Or, within the exports file on the NFS server, export all folders of the /etc/portage folder. For the clients, only mount the NFS shared folder which equals /etc/portage/*($HOSTNAME)*. I was just looking into the /etc/portage man files prior to posting this & noticed something about subfolders, but didn't think I could make it work until now. This should probably be noted on the Gentoo NFS shared Portage wiki page... will document when I finish getting things to work here... might take awhile as I'm quite busy now. Might be a few months, but if it works, I'll definitely document the wiki (if not before somebody else does). Has been a long standing issue here, and am glad per folder naming *should* work. Still think driver packages with legacy drivers should be split into legacy & current driver. Users should simply have to emerge the driver and not have to manually edit the package.mask. <shrugs> .. think it's dumb they haven't done this yet. Can just imagine the nvidia-driver.ebuild being bloated to handle two or three different software packages. Cheers!
Cr*p. Just tried this: FILE:/etc/fstab localhost2:/etc/portage/localhost3 /etc/portage nfs4 rw 0 0 (Note: nfs4 allows mounting subfolders of the folders listed within /etc/exports.) Realized I still need to hand synchronize each file (ie. package.keywords) whenever I make a modification or new entry on the server. This defeats the purpose of also exporting /etc/portage via NFS. Every scenario or hack I try to think of to work around this, I might as well just go back to using rsync to duplicate entries of the /etc/portage/package.* file across my local network here. And then somehow creating a rule to either omit package.mask & package.unmask. But cr*p. I don't think any of this is going to work... I'll sleep on it... for a couple of nights. Just wish I could pick up axe and split the @#$@ nvidia-drivers package back into nvidia-legacy-drivers & nvidia-drivers!!! It's the only package that's creating this problem!!!
