On Sat, 2005-01-08 at 13:07 +0000, Ian Leitch wrote: > Gentoo Linux Remote Package Building Service > ============================================ > > The purpose of this system is to make Gentoo an option for those who had > previously rejected Gentoo as a server grade OS. Reasons for rejection > could have been the dislike for the presence of development tools on a > production system, or use of CPU cycles to compile packages which could > have been used to service web/ftp/whatever requests.
I've been wanting something like this for some time. I'm working on getting a server team put together in the next coming months, so hopefully we can organize these kinds of projects better. Let me know of any progress you have you start on it or if you'd like to be part of the gentoo server team. > And for those already using Gentoo on a production server? They'll just > love us even more :) > > In a nutshell, emerge requests made on the production system are sent to > a "build server", which compiles the package(s) and notifies the > production server when the binary package is ready for download. > > The build server would run a daemon which listens for requests, and are > authenticated by client ID. Each client (production server) registers > itself with the build server, at which point the system's CHOST, CFLAGS, > USE etc are sent and stored on the build server. > > When emerge is called on the production server; if 'remote-build' is in > FEATURES then the build server is notified to build package foo and all > its deps for client ID 123. An optional priority can also be set for > security updates etc. > > When the package is ready on the build server, it'll need to notify the > production server somehow. Having a daemon running on the production > server would be the easiest option, but probably the worst. Other > options could be: Monitor an NFS mount (is this possible?), check the > build server every n minutes (with a what's-ready request) then download > from NFS/web server. > > One requirement of this system is that the production server and build > server will need to share the same portage tree. Take a look at GLEP19 (its a work in progress with the implementation still in the air), but hopefully down the road we can just have a locked tree for this box to use. I'm not sure I really like the idea of having a 'compile on demand' box, though there might be uses for that. I think for most production environments you'd want to great a whole set of binaries at once and test them, once you've tested them, then you can distribute them via nfs or binhost. In case that confused you. I'd like to be able to have something that will build a set of packages for a specific sub-arch. It'd create the environment to make sure all the deps are built and such in a chroot. -- Lance Albertson <[EMAIL PROTECTED]> Gentoo Infrastructure --- GPG Public Key: <http://www.ramereth.net/lance.asc> Key fingerprint: 0423 92F3 544A 1282 5AB1 4D07 416F A15D 27F4 B742 ramereth/irc.freenode.net
signature.asc
Description: This is a digitally signed message part
