Ok, the idea is this (and i'm sure it's already been thought of, but i'll put it here so maybe someone will work on it) emerge portage-server on a single machine in your network, this machine will do these things 1) host the local portage tree 2) host all distfiles 3) host all binary packages 4) get distfiles which it doesn't have, add them locally and then send them to the requesting leaf then, each 'leaf' server will have a single variable in make.conf or whatever that says simple "get everything you need from this server ->" the leaf servers will not have portage tree's, distfiles, or anything even an emerge -p or something that uses the ebuild cache would be redirected to the portage server for enumeration. basically this will need an http rpc-xml setup to request and deliver the information and packages. The leafs will hold the packages long enough to compile and install, but after that it's gone. Each leaf will still maintain it's own install data (/var/db) LordVan expressed interest in helping with this (using Twisted) and I would also like to help, although i don't know much python.. Hope you think this is a good idea :) The whole point to this is that the leaf servers dont' need *anything* on them to run gentoo, only 1 machine needs an up to date portage tree and storage to hold distfiles, this addition will make portage much more 'enterprise' friendly
same idea as #1191
One potential possibility of this is to remove the need of having a compiler on every box on my network. Having a compiler on every production server is a bad idea. Would be really nice to be able to manage all those boxen from a central portage tree/server.
This can be done anyway. Search the forums for tips on how to do this. This bug should be closed as 'invalid' as it's really beyond the scope of portage.
umm no it isn't beyond the scope of portage
My point is that there are ways to acheive all of the requested items without modifying portage. So... really... should portage be modified when it doesn't need to be?
one can compile packages without portage.. one can install packages without portage.. one can do their own dependancy checking and installation, but why do that when portage does it.. I think you get my point. portage acting as a server to slave portages is a natural extention for portage, and you can't do everything without modification.. you can sync and download distfiles from a central server but you can't keep the whole cache in a central place, and dessiminate prebuilt packages easily, pass compile requests to other machines, etc. I'm talking about using a central portage server to manage package versions on all your other servers, this cannot be done with standard utilities and certainly not easily. Please stop arguing with me about this, if you don't want this feature then great, don't use it, I and other do want this feature.
tantive any news on your scripts ?
pyrania is currently preparing a script that provides kind of a distfiles proxy. clients will contact that server when they need disfiles. when the server has the file it will provide it from the local disc. if not it will fetch it, store it and provide it.
pyrania are there any sample scripts or pre releases i could try ?
Slapping this one as later for the time being. To do remote management of portage installations, a sane api is required. Doesn't matter if the transport mechanism is soap/corba/xml-rpc, an api is required *first*. Aside from that, implementation of a client/server body of code to handle talking to each other is outside of portages daemon, although related- the new code should be a seperate package. Portage, ultimately is a library. Responding/talking over the network regarding the installation should be a seperate add-on.
Bah... s:daemon:domain:. Point I was trying to get across is that network 'awareness' is outside of portage's focus- it's a side project, relying on portage, as such should be implemented that way...
*** Bug 18814 has been marked as a duplicate of this bug. ***
*** Bug 25651 has been marked as a duplicate of this bug. ***
*** Bug 69037 has been marked as a duplicate of this bug. ***
*** Bug 90322 has been marked as a duplicate of this bug. ***
