Stephen Hahn wrote:
> * 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.
>
It's about 1.9MB worth of gems spread out over 7 gems. It's
practically not been a problem, as a client, to install these over the
network.
> 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.
>
>
While this notion of hierarchy is possible, in the context of Solaris
and rubygems delivering content to different repositories, it's feasible
only in cases of gems that don't deliver executables. Any programs that
are delivered by a gem(or by Solaris trying to be gem compatible)
outside the gem repository would again cause ownership problems.
-ps
> - Stephen
>
>
