RPM and GEMS conflict of interest

Mamoru Tasaka mtasaka at ioa.s.u-tokyo.ac.jp
Wed Jun 23 09:32:21 UTC 2010


(First of all, please don't use top-posting:
  http://fedoraproject.org/wiki/Communicate/MailingListGuidelines#Proper_posting_style )

Gilles Dubreuil wrote, at 06/23/2010 06:05 PM +9:00:
> On Wed, 2010-06-23 at 17:26 +0900, Mamoru Tasaka wrote:
>> Gilles Dubreuil wrote, at 06/23/2010 04:36 PM +9:00:
>>> Hello,
>>>
>>> I've been asking myself why there bother with rubygem packages?
>>>
>>> Gems have a different life cycle and are completely managed through the
>>> gem interface:
>>>
>>
>> This works if you use gem-based packages only.
>> For example let's take alexandria http://alexandria.rubyforge.org/
>>
>> - alexandria itself does not provide gem
>> - but alexandria depends on many rubygem modules
>> - and also depends on ruby modules which are not provided by gem
>>     (mainly ruby-gnome2 related packages)
>>
>> so with making "$ yum install alexandria" just succeed without any
>> trouble, packaging gem packages in rpm style is unavoidable.
>>
>> Also packaging gem rpms means that
>> - we can modify the gems if needed
>> - remove files unneded on runtime, something broken, etc
>> - and also do other things
>> to use them on Fedora. In short, using rpm management has much benefit
>> for us.
>
> Hi Mamoru,
>
> I understand this functionality I didn't know about ;-)
>
> I also guess you're right and as long it doesn't break the gems as we
> can still install multiple gems of different versions.

Honestly saying, I also question about this statement that
"we can still install multiple gems of different versions".

For example rails 2.3.5 (in fact actionpack 2.3.5) can be compatible
with rack ~> 1.0.0. And many people already reported that with
rack 1.1.0 / 1.0.0 parallel installed, rails 2.3.5 no longer
work because rack 1.1.0 is to be loaded first.

So "we can install multiple gem of different versions" does not
mean "they work altogether correctly". If parallel-installed gems
worked, well, it is just lucky. Also I don't think that the upstream
gem module developer actually guarantee that parallel install
works.


> Don't get me wrong I reckon rpms are very powerful and made system
> change management so easy.
>
> At same time I use Ruby more and more as well as ROR and the
> dependencies and I feel it's redundant. As I'm sure it also adds
> overhead of building the rpm specs. So where is the line?
>
> For instance instead of building rpm for apps which are not built as
> gems (like alexandria) into gem wouldn't it be preferable to integrate
> gem dependencies into rpms?
>
> Let's say a ruby app needs gems (like alexandira) so the corresponding
> rpm pack triggers "gem install" which depends initially on ruby and
> rubygems packages but would also depends on other needed rpms?

- This is the same as requesting people to install the dependencies
   not available in Fedora's rpms by themselves (using gem or tarball or
   so) and is against Fedora's policy.

>
> This way multiple ruby-gem rpms versions would be possible.
> Actually can we do multiple rpms version without conflict?

So basically I think installing multiple version is not "supportee".

Regards,
Mamoru


More information about the ruby-sig mailing list