On Oct 12, 2007, at 22:56, Prashant Srinivasan wrote: > Here it is - http://wikis.sun.com/display/WebStack/RoR_ARC_Case
> Including Ruby with Solaris - ARC Draft > > Prashant Srinivasan <Prashant.Srinivasan at Sun.COM> > 12 October 2007 Hi, Some thoughts on the latest version. > The proposed directory layouts for Ruby are: > /usr/ruby/[<version>.<minor-version>]/ > bin > include > lib > man > share > src nit: These other dirs are not really under bin? Just a formatting glitch? > /var/ruby/<version>.<minor-version>/repository I know from past discussion what this is, but there isn't any coverage in the spec about it. I suggest mentioning it in the section where you cover installing gems. > > /usr/ruby/[<version>.<minor-version>]/bin/<executable> > will be linked symbolically from > /usr/bin/<executable><version>.<minor-version>. and from > /usr/bin/<executable>. The latter link will always point to > the latest <version>.<minor-version> of Ruby installed on > the system. With these non-versioned symlinks, I wonder what happens in a future when ruby 1.9 is available but 1.8 is still also available. % pkg install SUNWruby19usr [...then some user wants 1.8 too so it gets installed later...] % pkg install SUNWruby18usr Does the SUNWruby18usr pkg change the symlink to itself? I'm just brainstorming; having a /usr/bin/ruby has benefits for discovery. > Ruby 1.8.6 patch 110 is being included into Solaris. What if patch 111 comes out next week? I'm thinking it is counterproductive to lock down your case so tightly to a given patch since it might change before you're even done integrating. Others might disagree but I'd even suggest making this case about integrating ruby 1.8 (as opposed to 1.8.6 or 1.8.6 patch 110). Given what you say later about the compatibility, future 1.8.z (z > 6) will be compatible? As long as 1.8.7 ends up being fully compatible, there is no value in going through another ARC case just to upgrade your ruby18 package to include 1.8.7. You could assert that this case covers all compatible 1.8.z's. > (2) Interfaces can be deprecated. In Rubygems deprecation means that > use of > the deprecated interface results in a runtime warning. Deprecate Can you clarify which interfaces? Interfaces of rubygems itself (command line options, etc) or interfaces contained in the external gems which can be downloaded using rubygems? > interfaces will be available for at least 6 months(that is, at le > ast > 2 minor releases) after being marked as such. But I'm not forced to upgrade the gem right? There's nothing in the system that would make the interfaces go away unless I consciously go and upgrade the gem by hand? > a version-specific subdirectory. The package SUNW18rubyusr, > and SUNWruby18root, will contain the Ruby and Rubygems interfaces. SUNWruby18usr? > 3.1. Included Ruby Extensions. > > The initial integration will provide the following, a select subset > of the extant Ruby extensions. I forgot to ask earlier; is this list selected based on which ones can be included given the libraries currently available? > 6.1. Interface Stability. > > Ruby, Ruby Gems, and extensions, as a set of Open Source projects, > are controlled by a group of developers external of, and independent > from, SMI. These projects make no guarantees or promises of feature > compatibility between releases. This conflicts with the info in s.2.2 where the compatibility is explained. More importantly, the external community might not make any guarantee, but this project does, so the above paragraph doesn't fit in. It's Uncommitted so the guarantee is that SUNWruby18 will remain compatible within the lifetime of nevada. (Of course, future ruby19 may well be entirely incompatible but that's a separate pkg.) I suggest removing s.6.1, everything else seems fine and 6.1 just confuses the issue a bit. > 6.3. Exported Interfaces. > There are no advertised interfaces for programmatically invoking > the Ruby runtime. Invoking ruby from a shell script is a way to "programmatically invoke the Ruby runtime" ;-) Nits aside, more than anywhere else in the spec, it's important to be precise in the exported interface table since it tells consumers what they can and can't do. > /usr/ruby/[version]/bin/index_gem_repository.rb Uncommitted Executa Is this one a public CLI users are expected to run directly? > /usr/ruby/[version]/bin/ruby Uncommitted Executa Here it's just a nit, but for CLIs there are many interfaces. There's the name/path itself, the options it takes, return codes, stdout/stderr output. Here, I think it's understood that everything is Uncommitted so I think the entry is fine as is. Also list the symlinks as exported. The non-versioned symlinks (e.g. /usr/bin/ruby) needs to be Volatile so you can change it to point elsewhere whenever.
