Jyri Virkki wrote: > Prashant Srinivasan wrote: > >> Hello, >> >> Can interested folk please review the ARC case for Rails that Amanda >> and I put together? >> >> http://wikis.sun.com/display/WebStack/Rails_Draft_ARC_Case >> > > > > >> All other objects will be contained within the >> /var/ruby/1.8/gem_home hierarchy, specifically, in the >> below directories: >> >> /var/ruby/1.8/gem_home/ >> cache >> doc >> gems >> specifications >> > > This isn't right.. > > That's exactly where they end up if one runs 'gem install rails' today. > > So package updates and gem install runs will continually stomp on each > other in various ways depending on ordering. System auditing will > also show package-delivered files are corrupted. > > (Also if some binaries like 'rails' are elsewhere, in what interesting > ways can things blow up when they're out of sync with what used to be > there before gem/pkg overwrote whatever pkg/gem previously installed?) > > If Ruby is to support both package-delivered and gem-delivered > content, there needs to be a design that specifies how they can > coexist. This case needs to consider and address that issue. > >
Jyri, these are good points, and this(integrating Rails into Solaris) is a problem with no solution that satisfies all packaging mechanisms/our goals. What we wanted to(and still do) achieve when we set out on this effort was to package Rails + dependencies to present the end user with a pre-configured set of components for Rails + dependencies + some critical components like db connectivity. Installing these components manually doesn't present a difficult proposition to the end user(ie., utterances of "gem install rails", "gem install mysql --with-mysql-dir=/usr/mysql/5.0", and/or "gem install postgres"), on the other hand, if your target is a Ruby end user, [s]he is probably going to have to do this anyway, so why not save them the trouble? Given that rubygems support in Solaris is already present, we have three options to support Rails(and other gems). (1) Use Solaris packaging exclusively(ie., gems not allowed). (2) Get Solaris and Rubygems to co-exist. (3) Use Rubygems exclusively. ie., don't bundle Rails. It's easy to answer #1 - Using Solaris packaging exclusively(ie., a "no gem mandate") wont work here given: (1) The gem format is increasing in popularity. It's now been incorporated into Ruby 1.9. So it seems likely that non gem packagers(like Sun) will begin to face problems in obtaining non gem sources to package into Solaris. (2) Some software packages(like Rails) have very frequent release cycles. Even if #1 above was not true, we would find it impossible to update our packages frequently enough, for them to be useful to end users. (3) If we package software in a non-gem format, then applications that are coded with "require_gem" will break, even if the required functionality is installed. #2(ie., peaceful coexistence), by definition means that an end user should be able to use the package as a gem irrespective of how we package it. The only way to do this is to layout gem files on the file system through a Solaris package. And, if done right, this location will be a GEM_HOME, or will be in the GEM_PATH of a user. Given that we don't want to be unfriendly to gems(ie., #1 above), the user will have to be able to upgrade/remove gems through the gem command as well. And this could mean the removal of files that are installed by Solaris. We're left with the possibility that files packaged by Solaris will be updated by gems if an end user decides to use Rubygems. One apparent way to work around this problem is to install the Rails gems in a different place than the default gem_home. ie., have one home for Solaris Rails gems, and have another for gems installed through Rubygems. But this will necessitate the end user to manually change the the variables where rubygems looks to, for gem path information. By doing this, we're giving up the value-add that we had hoped to achieve by packaging Rails. #3, this is the alternative for us if we want to avoid the problems that packaging Rails brings forth. ie., Expect that our end users will run "gem install rails". Comments welcome from folks on what seems like the most sensible path to take here. > >> Additional Ruby Libraries required to support three of the most >> popular databases for Rails applications are: >> >> mysql >> postgres >> > > Does this create any dependencies to MySQL and/or Postgres packages? > Yes, it does. I'll update the imported interfaces list in the ARC case. > >> sqllite >> > > Does this depend on the SQLite package and if so, is it on the 3.x > that's being worked on currently? (If yes, this case needs to document > a dependency on that case.) > We decided to remove this from the ARC case - this is a typo. I'll remove this in the next rev. > >> The Ruby application components required by Rails and which must >> be integrated at the same time as Rails are: >> >> rake >> > > I see in debian rake is delivered separately. Is it desirable to > require installation of rails for someone who only needs rake (if > that's a reasonably common use case)? > We can easily package this separately if it's felt that non-Rails applications commonly use Rake too. -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
