Summary: | Enterprise Portage Server :) | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Joshua Brindle (RETIRED) <method> |
Component: | Core | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED LATER | ||
Severity: | enhancement | CC: | antarus, emiliano.mena, frido.ferdinand, h3y, lordvan, mholzer, pYrania, robbat2, rphillips, stkn, swift, tantive, tools-portage |
Priority: | High | ||
Version: | 2.0 | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 21449 | ||
Bug Blocks: |
Description
Joshua Brindle (RETIRED)
2002-11-03 14:36:46 UTC
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. *** |