Jyri, Thanks for the lightning quick responses - Jyri J. Virkki wrote: > > 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?
Thanks for spotting this. It's now changed. > > > > /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. Done. > > > > > /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. > I changed the word "latest" to "highest". ie., "The latter link will always point to the highest <version>.<minor-version> of Ruby installed on the system." (Our scripts, before creating the symlinks should look to ensure that it's own version is greater than the binary that /usr/bin/ruby points to, before changing the link) > > > 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. I agree - changed it. > > > (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? It could be either command line options, or API(s) that rubygems provides to ruby programmers. For example, Time::today was decided to be a method that Rubygems provided, which it shouldn't have . . . so it's being deprecated. http://www.artima.com/forums/flat.jsp?forum=123&thread=216541 Also, in the invocation "gem install --include-dependencies", --include-dependencies is being deprecated. Clarified that in the arc case. > > > > 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? Yes. The APIs will stay on unless I consciously remove them by upgrading them by hand. > > > a version-specific subdirectory. The package SUNW18rubyusr, > > and SUNWruby18root, will contain the Ruby and Rubygems > interfaces. > > SUNWruby18usr? What's the question here? > > > 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? Yes - except for readline. Readline is pretty basic(for interactive ruby and the rails console), so we're putting it in even though it's not currently available(in Nevada). > > > > 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. Done. > > > 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" ;-) Removed. > > 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? Yes, index_gem_repository is a public CLI meant to be 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. > Done. Thanks, -ps > > -- Prashant Srinivasan F/OSS Enthusiast Sun Microsystems, Inc. http://blogs.sun.com/prashant GnuPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x82FBDE5A
