Robin H. Johnson wrote: > From all of the large Gentoo deployments I've done (one of which > exceeded 200 machines), you're approaching this the wrong way. > ... Thanks for the concise and clear explanation. It's the first time I've read a description of how Gentoo might be used on an entreprise level. As Paul says: > It would be cool if you could write up a howto for others who want to do this. ..although I figure if you know enough about gentoo to take a job administering you should be able to follow that explanation well enough.
Grant Goodyear wrote: >> Yes, I know gentoo is a meta-distro. And that there isn't loads of >> bandwidth. That's easily got round. > > It is? > Yes. I'd be happy to set up the site and I'm sure other users would be happy to contribute. >> The main problem I see is USE flags (devs already >> compile with standard C-flags right?)...We can always tag >> pkgs with USE flags. >> > > I think you'll find that there is little interest (among devs) in Gentoo > maintaining a binary sub-distribution. My view, and for some time it's > been our semi-official view, is that Gentoo can serve as a nice base for > creating a binary distribution, and we encourage people to do so, but > that it shouldn't be a part of Gentoo itself. > I accept that has been the position. As for devs not wanting to do it, I'm thinking it would be part of the standard emerge process (ie binhost/PKGDIR and -b) but you would need to add tagging of USE flags if the binary format ATM does not include which flags were used. So yes, it might add time/ network in terms of uploading but nothing else. > (That said, it's true that there is still a real need for better support > for binaries in portage, especially for handling USE conflicts.) > I think the above would _start_ to handle that. Stuart Herbert wrote: > If the Seeds project proves successful, I'd be interested in providing > binary packages for seeds. Whether that'll be as part of Gentoo, or > whether it'll be better to move downstream (so to speak) to do so is > up for debate. > So you are looking to provide /some/ sort of binary packages as part of an official Gentoo project then. Robin H. Johnson wrote: > My compiles as a dev are of very minimal use to anybody except me. > There are too many things that are specific to my systems. > Sure. Presumably you test packages with standard C-flags as users are advised to before bug-reporting? Other than USE flags what else would make your packages unsuitable for others? If it's only USE flags, then at least the pkg is a start- if others want different settings they can compile their own. Hopefully we could set up a collaborative build process so others could upload their builds. In terms of security though, this would have to be restricted to devs (of the new project). >> If gentoo is still serious about enterprise adoption, it needs a binary >> repo (so we can avoid system breakage) which would of course be a little >> bit behind. I'd be happy to contribute time, as I'm sure many other users >> would. > Stuart Herbert wrote: > I think that's total rot, sorry. A binary distro can break a system > just as much as a source based one. A source-based distro is just as > practical in the enterprise; in fact, for web stuff, it's a lot more > practical, because it gives you the flexibility to build a box to your > exact needs, rather than having to compromise on what binary distro > vendors provide you with. and Grant Goodyear wrote: > As for Gentoo being serious about enterprise adoption, I don't agree > that we need a binary repo. I think we ought to make it easy for our > users to create and use their own, customized, distribution. That's our > strength as a meta-distribution. (We also need to make it easy to > install and replicate custom distributions, but we already have Catalyst > and the Seeds project addressing those issues.) > I accept that for the enterprise compiling from source may well be better, based on Robin Johnson's reply. However this point about system breakage is serious *for users*. Stuart Herbert wrote: > I think what you really need is an alternative package tree, one > that's versioned and tested as a whole, and one that isn't "live". > That's also been discussed on the fora. I think the idea was that if we have the tree in svn (or whatever) there would be better scope for branches to enable exactly that. Regards, Steve. -- [email protected] mailing list
