Prashant Srinivasan wrote: > 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. > I'm a supporter of option 3), I feel that we'll just tie ourselves in knots if we do 2) and 1) is just not going to fly with anyone who's used Rails before. But having said that, an idea would be to have a Solaris package that's built around Gem management, where the package installer uses the Gem command to check for an existing installation of the Gems that the packages bundle, then displays what's installed currently and offers the user the choice to do nothing or to install the Gems. In that case the Solaris package would just be a wrapper package (i.e. Rails Support) and not actually package any files. The package itself could setup a local (and temporary) Gem repository.
It sounds complicated and probably impossible given the packaging restrictions we have. But it's no more complicated than option 2) would be with it's countless scenarios. >> 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. > Rake download stats are hopelessly skewed by it's attachment to Rails. It isn't rev'd as often as the other Rails dependencies and so isn't downloaded as frequently, but it's difficult to determine how often it's downloaded independently of Rails. Rake is a very useful tool, and my instinct is to agree that we should package it separately. Amanda
