Jyri Virkki wrote: > 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> >> 08 October 2007 >> >> This project delivers Ruby into Solaris. >> Ruby, the scripting language[1], and Rails, the associated web >> > > But it doesn't deliver Rails, right? Just the ability to get it. > That's correct. I can certainly change the wording if it's felt to be misleading.
> >> 2.1. Key objects. >> > > I suggesting merging content of 2.1 and 2.3. It's more maintenance > (and review) work if layout is described in several places instead of > just one. > > >> /usr/ruby/1.8/bin/testrb >> /usr/ruby/rubygems/bin/gem >> > > So unlike ruby, rubygems is not versioned? Always backward compatible? > It can manage packages across rev numbers. There seems to be an exception where it expected a different package layout on disk, this was an alpha version, and even in this case, a patch was created for the installer, to migrate old gem installations when the new version was installed - http://rubyforge.org/pipermail/rubygems-developers/2004-March/000199.html Of course, there is nothing to say that this wont happen again. If it does, I feel that migration paths will be provided by the community. Another reason a versioning scheme for rubygems is not prefered because gems cant be loaded from a Ruby script across different versions of rubygems. A system that uses two rubygems packaging repositories is possible, but seems contrived. > How tight is the relationship between ruby and rubygems? > It's a ruby program that installs itself as the package manager for the ruby instance that invoked it. This version of rubygems requires ruby >= 1.8.0. rubygems will be a part of the ruby codebase starting ruby 1.9. > Does it need a separate rubygems/bin (which I need to add separately to path)? > We initially put it into the versioned directory, and moved it out later so as to remove any implication of connectivity between ruby version and rubygems version. We later found that rubygems "binds" to a specific ruby version. ie., "#!/usr/ruby/1.8/bin/ruby" instead of "#!/usr/bin/env ruby". so there is a connectivity irrespective of whether we acknowledge that in the directory structure. We didn't remove the rubygems directory to keep the gems "stuff" separate from the ruby commands. The /usr/bin linkage should remove the extra link in path problem. Do you feel it makes gems more disconnected from the rest? - the "rubygems" directory was a preference, so, unless Chris or others disagree, we can change that. > > > >> 2.4. Packaging and Delivery >> >> The current proposal allows for the inclusion and coexistence >> of multiple versions of Ruby by keeping each installation under >> a version-specific subdirectory. The package, SUNWruby, >> > > You'll need a usr package (end in 'u') for the /usr content and a root > package (end in 'r') for the things outside /usr (see some of the > existing packages for examples). > > Since the ruby dirs are versions, I think you need versioned pkg names > as well. > > > Thanks for bringing this up. I'll look into this and update accordingly. > >> 3.1. Included Ruby Extensions. >> > > Are the extensions ./configure-time options which get compiled in? > Yes. > It seems now this case doesn't include any gems to make things more > consistent? I suggest adding a paragraph explaining that approach. > Yes, it does not include pre-installed gems. I'll add a paragraph summarizing our current thoughts on the topic. > > >> A symbolic link will be created from the standard Solaris man page >> location(/usr/share/man/man1/ruby.1) to >> /usr/ruby/[<version>.<subversion>.<minor-subversion>]/man1/ruby.1. >> > > It should include stability info (the Uncommitted) as well as a note > about obtaining sources on opensolaris.org. I've seen some components > add the info to the manpage, others have a summary manpage which > describes the component along with Solaris-specific info and pointers > to the individual manpages in /usr/foo/man/*. Look for examples in the > sfw sources with names *.sunman > The former seems more appropriate. I'll make the change. > >> 6.2. Imported Interfaces. >> >> NAME STABILITY NOTES >> >> Curses [CRT screen handling] Stable >> > > Where is the curses it's linking to? There should be an ARC case. > Okay, I was able to find a reference "|ASARC 1992/040| OnePager Internationalized curses library closed approved 1/15/93" http://www.opensolaris.org/os/community/arc/caselog/1992/;jsessionid=66175A41DBAC9C4E953D3029C8B28F8 > >> Readline[functions to edit command lines](statically linked into the >> Ru >> by executable) External >> PSARC 2007/188 >> > > 2007/188 hasn't delivered yet, so I assume you're just getting it from > elsewhere and compiling it in statically, as noted? > Yes. And that, of course, means that we remove it from the list of dependencies. > > >> 6.3. Exported Interfaces. >> There are no advertised programmatic interfaces. >> > > ruby is a language ;-) > Tons of programmatic interfaces there. > Whoops. I meant to say "no interfaces to programmatically embed the Ruby interpretor". > (i.e. the language itself, bundled APIs etc) > > Presumably it's all Uncommitted, but call it out. > > Ok. > >> [7] >> http://wikis.sun.com/display/WebStack/Directory_and_File_Layo >> ut >> > > It seems to deliver much documentation under /var/rubygems/repository/doc/ > Is this "/var" content? It changes during runtime and/or users modify it? > If it's just documentation why isn't it under /usr? > > In general, the doc directory content can be changed during gem administration. The ones that are here are inherent to packages in rubygems it self. In any case, I would prescribe not to attempt to change the location of these directories since they are internal to the software. -ps
