David Van Couvering wrote: > > http://wiki.rubyonrails.org/rails/pages/HowToUseMultipleGemRepositories > > This page says that to set this up you need to do the following: [...] > If this really is the way we want to go, then we need to find a way to > automate this. Having to follow this kind of cookbook just to get > started seems like a definite way to prevent people from getting going > with Ruby in Solaris.
A cookbook tailored specifically to OpenSolaris would be a nice first step. Prashant, can your team come up with a short writeup on getting it working as easily as possible using current snv_b79 as the base? Next step would be to provide some automation. Perhaps the ruby package should include a script/tool that sets everything up automatically the user who runs it. > Note that all of these situations deal with machines where there are > multiple users and you either want to control access to the system > repository or manage potential collisions. > > But in the standard developer's laptop, there is only *one* person. But Solaris doesn't only install on personal laptops. It also installs on E25K's and everything else in between, in most of which cases there are many users and meaningful security requirements. There's only one SUNWruby package and it's the same one that gets installed on a personal laptop and on the big iron production server and on the shared ISP server hosting hundreds of untrusted users and .. so forth. That's what makes it challenging. We need to find ways to make the initial developer experience as convenient as possible without making the system unsuitable for other uses. Some web stack components (like apache) deliver RBAC rights profiles which can be assigned to the desired users. Ruby doesn't today do anything special along these lines, though suggestions (or diffs ;-) are always welcome. With IPS and distro constructor coming up, there are some new ways to have more targeted setups for specific audiences, which will be good to explore next year! Even then, it'll be unlikely to have packages that deliver insecure content (such as world writable systems dirs). -- Jyri J. Virkki - jyri.virkki at sun.com - Sun Microsystems
