* Prashant Srinivasan <Prashant.Srinivasan at sun.com> [2008-02-21 19:07]:
>
> >> (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.
>
> Yeah, this will need us to introduce scripting into the packages . . .
> and Indiana will not be able to use it.
You don't want two software delivery systems tracking the same
files/directories/etc. in any case. (3) sounds like your best bet,
but then you have to evaluate how many gems (how many bytes worth of
gems) you have to deliver by default.
Is it possible to deliver gems to two locations, so that packaging
delivers to a vendor directory and gems to a site directory (with site
preceding vendor in any dynamic module lookup)? Perl has this
("vendor-perl" versus "site-perl"); I believe we added a similar
location to Python.
- Stephen
--
sch at sun.com http://blogs.sun.com/sch/
