Hi,

In gentoo the portage tree is about 250 meg, which is alot of diskspace esp. on linode.

Since the portage tree is the same for everyone using gentoo, inless they choose to exclude things.

I was thinking it may be a good idea to have a global portage tree per dc that people can then use via nfs, the tree could be updated daily.

Also since one of the biggest impacts on linode is the compiling of stuff from source, ccache makes a big impact on this and I was thinking a global cache per host or dc may aid in removing the some of the load on the hosts esp. for people using gentoo since everything is from source and when an emerge world is done it had a big inpact.

If the files where already in a ccache from the first person that did the compile on the files it would mean that they would not have to be done again and thus save the load on the host.

This could be done by an NFS share that people can write to and use as the ccache.

Any thoughts

Adam

I used to use portage on a NFS share on my local network, and I'd highly recommend against it.

1. Portage isn't really designed for it, and funny glitches happen. Locking issues, and interesting things like when you upgrade baselayout (if /usr/portage/.keep isn't writable, it fails).

2. It would have to be read only to be secure. I don't want someone editing an ebuild and then me unwittingly emerging it.

3. If it's read only it precludes tinkering with ebuilds, which is sometimes necessary.

I think a far better solution would be to provide a local rsync mirror that everyone can rsync their own tree from. I'd be happy to provide that myself for ThePlanet users from my linode, but only if it didn't count against my bandwidth. caker would have to chime in on that. You'd probably want a second rsync mirror at HE as well.

Like I said, I was using NFS for my portage tree on my local lan. It got to be such a pain in the butt that I am now using a local rsync mirror, with portage trees on each machine. It just works better.[/b]

Hi,

From what I read on some sites, nothing is written on the portage tree during emerge operations and that shared NFS trees do work, but if you know different then.

But I would like to see the ccache share.

Adam

During an emerge of an ebuild, downloaded files are written to /usr/portage/distfiles which is a complication. Either on the global rsync NFS share distfiles needs to be replaced with a symlink to somewhere on the local FS after each sync operation, or the tree needs to be read/write.

Even if the tree is read/write, baselayout has a cow when you upgrade it. It not only wants to overwrite /usr/portage/.keep, but it wants to change the ownership and permissions on it. The emerge fails if it can't do that.

Again, there is the general problem of the portage tree being read only and not being able to tinker with it.

As far as ccache, I think I'd have to pass on that as well.. Something about parts of my binaries coming from "untrusted sources" (excuse the terminology, but I think it's a valid concern) doesn't make me feel good. The NFS share would have to r/w to the world, and that would be a heck of a security hole.

Re: tinkering with ebuilds: modern versions of portage allow a local 'portage override' tree to be created. This is the recommended way to tinker with ebuilds locally, and is perfectly compatible with a read-only /usr/portage. The other issues are all valid concerns, but this one really isn't a big deal.

-EtherMage